Beiträge von bebbo

Zitat von dominusnoctae;12241

Welche Backliste setzt ihr ein? ich aheb vor einiger Zeit Spamhouse verbannt und bin auch recht gut ohne klargekommen (Greylisting und Policyd-weight) aber nun kommen doch ab und an ein paar Spammails durch.

Habt Ihr nen guten Tipp für mich?

Heute Mittag were ich erst mal selbst etwas Blacklisten, aber das kann denk ich schnell in Arbeit ausarten

Ich verwende lediglich SPF und falls eine Domain kein SPF besitzt, wird ein SPF ausgerechnet oder notfalls manuell korrigiert(<5 mal pro Jahr).

"Blacklists" lehne ich aus Prinzip ab, da dies nur ein anderer Name für Zensur ist.

Bebbo

Ja, ist etwas teuer - vermutlich weil da halt Leistungen (Backup) drinnen sind, die ich (man?) nicht brauche.

Mein Backup ist derzeit DOWNLOAD nach Hause. Da inkrementell, ist das gar nicht so viel und kostet EUR 0,00.

Bebbo

Hallo Leute,

mein Server ist vermutlich zu groß dimensioniert, derzeit laufen folgende Dienste unter CentOS
- SSH, HTTP, HTTPS, SMTP, POP3, IMAP, SSMTP, SPOP3, SIMAP
mit sehr wenig Traffic
- < 10000 HTTP Requests/Tag
- < 20 Domains
- < 5000 E-Mails/Tag
- < 500 E-Mail Benutzer

top - 11:37:34 up 64 days,  8:36,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  14 total,   1 running,  13 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8%us,  1.1%sy,  0.0%ni, 96.9%id,  0.0%wa,  0.1%hi,  0.1%si,  0.0%st
Mem:   1024000k total,   129244k used,   894756k free,        0k buffers
Swap:  3072000k total,        0k used,  3072000k free,        0k cached




  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28005 mysql     20   0  123m  10m 3048 S  0.0  1.1 715:22.30 mysqld
20344 xxxxxx    20   0  256m  31m 8312 S  0.0  3.1  23:04.71 java
14474 bejy      20   0  695m  54m 2916 S  0.0  5.5  13:01.74 java
    1 root      20   0 10312  464  432 S  0.0  0.0   2:20.37 init
 1572 clamav    20   0  108m  19m  788 S  0.0  1.9   0:55.55 clamd
31810 root      20   0 11268  744  552 S  0.0  0.1   0:12.04 rsyslogd
11719 root      20   0  3236  380  320 S  0.0  0.0   0:04.26 crond
19371 root      20   0  7076  976  588 S  0.0  0.1   0:01.82 sshd
11601 root      20   0  7076  508  404 S  0.0  0.0   0:00.24 sshd
30239 root      20   0  9912 2784 2244 S  0.0  0.3   0:00.04 sshd
30264 xxxxxx    20   0  2584 1428 1148 S  0.0  0.1   0:00.02 bash
 1016 xxxxxx    20   0  2192 1016  824 R  0.0  0.1   0:00.01 top
30262 xxxxxx    20   0 10044 1724 1144 S  0.0  0.2   0:00.01 sshd
27955 root      20   0  2448  308  304 S  0.0  0.0   0:00.00 mysqld_safe

Wie sieht das bei Euch so aus? Ist meine Konfiguration beeindrucken Resourcen-schonend oder geht es anders viel besser?

Würde es ein ALU-vServer auch tun? Es wird ja recht viel virtueller Speicher allokiert, der aber nie benutzt wird. Und 4.3GB sind wohl zu wenig...

Oder eher ein BRONZE-vServer?

Bebbo

HNY 2010

Mein Wunschliste:

1. VPN-tauglicher vServer.
2. garantierte Bandbreite
3. (S)FTP Space um Backups zu lagern
4. Varianten zu CPU/RAM/Storage

Backup ist für mich kein Thema, das erledigt ein Script (stoppt nur das, was sonst inkonsistent wäre) und das incrementelle Archiv wird heruntergeladen. Das Hochladen wird dann sicher mal dauern... (deswegen wäre 3. prima).

Bebbo

Zitat von Artimis;11444

Mal ne Frage dazu:
Ich bin ehrlich gesagt zu faul, meine Zertifikate zu jedem Rechner mitzuschleppen, von dem ich mal eben auf meinen Server will (Freundin, Vater (geschieden), Kumpels, Uni-Rechner...).
Daher habe ich mich für folgene "Sicherheiten" entschieden:
(1) SSH auf 5-Stelligem Port (für dumme Scan-Bots mit BruteForce)
(2) DenyHosts, damit BruteForce nicht möglich ist
(3) Die genaue Anzahl sag' ich jetzt nicht, aber es sind deutlich mehr als 20 Zeichen (Buchstaben, Zahlen, Sonderzeichen) im Passwort.

Das sollte doch reichen, oder?
Ich weiß, dass alle auf Zertifikate schwören - zu recht.
Aber meine Lösung sollte doch praktisch auch unangreifbar sein, oder?

Alles anzeigen

zu 1) Der Port ist im nu gefunden (außer er ist 6 stellig - kleiner Scherz).
zu 2) Außer ein BotNetz macht sich an die Arbeit
zu 3) Solange Du der einzige Benutzer bist

Und hoffentlich ist auf keinem der vielen Rechner ein KeyLogger installiert.

Dann lieber ein eigenes Laptop (Netbook) und 'ne UMTS Karte.

Bebbo

Zitat von orpheus;11334

Ich benutze den VNC nur weil ich einige Anwendungen habe die eben nur über ne grafische Oberfläche bedienbar sind bzw. wo es keine Konsolen-Programme gibt die den nötigen Funktionsumfang haben, administriert wird er ganz normal über Putty/SSH. Das mit dem nur 8-stelligen Passwort hab ich allerdings auch beim einrichten festgestellt, da werde ich wohl besser noch was drüber stülpen.

Wenn Du eh PuTTY nutzt, dann schalte das X-Forwarding ein und verwende einen X-Server. Unter CentOs tut es

yum install xterm xorg-x11-xauth yumex libgnome liberation-fonts

Mit apt-get sollte das ähnlich sein.

Falls Du Windows verwendest: http://sourceforge.net/projects/xming/ funktioniert prima. Schon kannst Du alle X-Anwendungen laufen lassen. Also auch synaptic oder yumex.

Hast Du beides am Laufen, startest Du ganz normal PuTTY und kannst X-Anwendungen starten, die den Screen bei Dir nutzen. Und abgesichert ist es auch.

Gleichzeitig solltest Du auch FTP abklemmen und stattdessen SFTP verwenden. Dafür gibt es Tools wie SFTP4TC + TotalCommander, WinSCP, ...

Und als letztes: Passwort durch public key ersetzen (puttygen) - und pageant (Zwischenspeicher für den private key) laufen lassen. Schon brauchst Du nie mehr das Kennwort zu verwenden. Und wenn alle Benutzer einen key verwenden, kannst Du in der SSHD_CONFIG mit

PasswordAuthentication no

Kennwort abschalten, schon interessieren Dich irgendwelche Möchtegern-Kennwort-Ausprobier-Angreifer nicht mehr.

Sicher ist sicher.

Bebbo

Frag doch mal bei zenmap nach, die werden wohl nicht alle Ports scannen.

mit

nmap -p1-65535  domain.foo

werden wirklich alle gescannt

Bebbo

Zitat von stachi;11048

Diese Annahme ist falsch. Wenn es ein Problem mit den Verbindungen geben würde würde der MySQL Server nicht neu starten sondern einfach nur neue Verbindungen ablehnen. Anhand der Uptime des MySQL-Server und der Log-Dateien ist eindeutig ein Neustart des MySQL-Servers zu erkennen.

Und der Neustart kommt von ganz alleine? Kein CRON, kein anderes Programm, was diesen verursacht?

EDIT:
Wie sieht es mit einem Full Query Log aus?
Ist vielleicht die Platte voll?
...

Zitat von ramstein;10977

jap, nu hab ichs auch wieder trotz der DB-Umstellung, also hat das damit wohl nix zu tun

Nachtrag:
Obwohl ich nix am System geändert habe taucht das Problem nun beihnahe täglich auf.
Den finalen Geistesblitz bezüglich der Ursache hat keiner mehr oder ?

Meine Meinung weiterhin: Das System ist falsch konfiguriert.

Mögliches Szenario:

1. Die Anwendungen die MySQL nutzen, wollen in der Summe mehr Verbindungen, als in MySQL konfiguriert ist.
2. Irgendwann sind die Verbindungen alle und jemand kriegt keine neue mehr
3. MySQL wird hart gekillt - das macht dann ggf. die DB kaputt.

Zu Prüfen:

1. N = Anzahl der Verbindungen, die MySQL erlaubt
2. X = Summe der Anzahl der Verbindungen zu MySQL aller Anwendungen
3. Sicherstellen dass X <= N ist.

Ausprobieren:

1. Wenn die Verbindungen alle sind: NICHT MySQL neu starten, sondern nur die Anwendungen neu starten. Geht dann wieder alles, liegt es NICHT an MySQL.

2. ...

Bebbo

Die sicherste Variante ist Schlüssel zu verwenden und das Login mit Kennwort komplett abzuklemmen.

Dann kommt auch keiner mehr auf die Idee das SSH Kennwort auch noch woanders zu verwenden, weil es kein SSH Kennwort mehr gibt! (Manch einer verwendet womöglich noch FTP... )

Bebbo

Ich verwende für Umzuge stets TAR Archiv:
- Da ist dann nur eine Datei (oder wenige) zu kopieren.
- Das TAR kann komprimiert sein - spart Platz und Zeit.
- Automatisiert man die Archiv Erstellung, hat man außerdem ein prima Backup System.
- Im TAR sind UID, GID und Links sowie die Rechte enthalten

Bebbo

Zitat von Bogdan;10014

Hallo,
seit einigen Tagen hab ich auch die gleichen Probleme mit meinem vServer!!!
Ständig stürzt mysql datenbank ab und meine website ist nur nach sehr sehr langer Zeit selbst mit 16000er Leitung erreichbar und funkt auch nicht so richtig!

Wie es sich hier herausgestellt hat, stürzt nicht MySQL ab, sondern ein fehlkonfiguriertes postfix blockiert MySQL.

Richtig helfen kann man Dir nur, wenn Du Dein Problem etwas ausführlicher darstellst.

Bebbo

Zitat

Also "(nahezu?) jeder" kann nicht sein. Hab es gerade mit drei Clients versucht, bei denen mein Account eingerichtet ist, und bei allen schlägt das Versenden fehl.

Dann ist es prima für Dich.
Und ich bleibe bei SSL/TLS von Anfang an

Und die Nachrichten selbst verschlüsselt man eh, wenn's wichtig ist.

Bebbo

EDIT: was macht postfix mittlerweile?

Zitat

Warum nicht?

Weil bei TLS der Client entscheidet, ob er TLS verwendet oder nicht.
Bei einem Man-in-the-middle Angriff, filtert dieser einfach heraus, dass TLS unterstützt wird, und (nahezu?) jeder Client macht dann halt ohne TLS weiter.

Mit SSL kann das nicht passieren.

Bebbo

PS:
mit TLS meine ich STARTTLS innerhalb der Protokolle (port 25, 110, 443)
mit SSL meine ich SSL/TLS außerhalb (port 465, 995, 993)

TLS innerhalb SMTP/POP3 sollte man nicht verwenden!!!

Stattdessen bietet man dedizierte Services mit SSL auf den entrpechenden Ports (465/995 bzw 993 für simap) an.

Bebbo

PS: wozu E-Mails von denyhost? Kriegst Du nicht genug SPAM?
PPS: der Titel des Threads sollte nun wohl eher "seit 3 Tagen mache ich mein MySQL kaputt" lauten

Zitat

Auch das Neustarten von postfix korrigierte ebenso wie das Neustarten von MySQL den Fehler.

Dann liegt die Ursache zu 100% bei postfix!

Und wie ich bereits zu den netstat.txt Attachments sagte: Die Verbindungen die alle noch offen sind, kamen (fast?) alle über TLS rein.

Was würde ich tun (falls ich jemals postfix verwenden würde)?

- Die Grundkonfiguration von postfix verwenden.
- Alle eigenen Änderungen zur Grundkonfiguration durchgehen
- Alle Meldungen von postifx (und seinen Freunden) durchgehen
- Hilfe zur Konfiguration von postfix suchen
- ...
und falls nichts davon hilft
- etwas anderes als postfix verwenden

Bbebo

Statt MySQL solltet Ihr mal postfix unter die Lupe nehmen:

Postfix will offensichtlich mehr Verbindungen von MySQL als da sind, weil postfix selbst die alten Verbindungen noch benutzt/nicht freigibt/warum auch immer.

Ob es an Postfix liegt kann man prüfen:

Statt einem Restart von MySQL müsste demnach auch ein Stoppen aller Postfix Prozesse und ein Neustart von Postfix dazu führen, dass es für eine gewisse Zeit wieder funktioniert.

Bebbo

centOs 5.3 ist doch auch eine gute Wahl!

Bebbo

die Ursache ist aus den geposteten Logs jedenfalls nicht ersichtlich:

Zitat

Nov 20 01:45:03 v230211191 mysqld_safe[353]: Number of processes running now: 0
Nov 20 01:45:03 v230211191 mysqld_safe[355]: restarted

Die Frage ist doch:
Warum sind alle MySql processe weg?

Üblicherweise läuft doch MySql jahrelang durch. (Automatische Updates? AUS!)

Bebbo

ramstein: was machst Du/der Server denn alle 15-20 Tage, was Konni jede Nacht macht?