Debian Root Server & alle Ports dicht nach Reboot

[lipton]

Hallo, ich hoffe irgendjemand kann mir ein bissel helfen, auch wenn ich nicht so der Fachmann in punkto Server & Linux bin. Ich hab einen Debian Rootserver mit installiertem Plesk, gemietet bei S4Y. Lief bis jetzt alles prima eigentlich.
Gestern ist dann ein paar mal der Webserver gecrasht und ich hab den dann auch im Plesk wieder neugestartet, weil auf meiner Webseite gestern abend auch von ein paar mehr Leuten was runtergeladen wurde, dachte ich nur das das evtl. für den Webserver zu viel war.
Nachdem das heute vormittag dann auch noch nicht besser war, hab ich den Server halt auf der Konsole mit reboot dann neustarten wollen. Ich wunderte mich warum nach ner Weile immer noch nix wieder kam, keine Verbindung mit SSH etc. dahin möglich.
Also hab ich nen Support Ticket geschrieben und die gebeten mal nachzuschauen was da los ist.
Gerade bekam ich folgendes als Antwort:

Sehr geehrter Kunde,

ihr System ist online jedoch sind bis auf den http und https Port alle geschlossen. Bitte starten Sie das System im Recoverymodus und überprüfen Siedie Konfiguration Ihres Systems. (Netzwerk, Firewall, etc.)



NMAP:
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-09-30 15:16 CEST
Interesting ports on xxx.server4you.de (xx.xx.xx.xx):
(The 1661 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
80/tcp open http
443/tcp open https

Nmap finished: 1 IP address (1 host up) scanned in 2.106 seconds

Nun bin ich mir sicher das ich auf keinen Fall all die Ports geschlossen hab, sicherlich nicht. Speziell weil es vor dem Reboot ja noch ging. Was kann passiert sein ? Gehackt ? Ich geb ja zu, ich bin net so der Fachmann für den Kram, das was ich bisher damit gemacht hab, Webseiten und Game Server, lief alles prima und ich kam gut zurecht. Aber nun. Ich geb zu, ich hab noch nie ne Recoveryconsole benutzen müssen, also wirklich keinen Plan.

Ich weiss das Ports in der Firewall von PLESK drin einzustellen waren, aber wie komm ich da jetzt dran auf der Recovery Console ? Doch eigentlich nicht. Also wo kann ich schauen wo die ports auf der Console zu finden sind ?

Klingt n00b, aber ich hoffe jemand kann mir nen Tip geben. Bitte keine Tips wie "Erst wissen, dann Server haben...", die helfen net wirklich. Für ernsthafte Hilfe oder Tips wäre ich echt dankbar.

Gruss & danke im Vorraus

Lipton

[sledge0303]

Mach was der Support geschrieben hat!!! Recovery starten und in den Logs nachsehen was passiert sein könnte. Du wirst dann sehen ob entweder dein Server gehackt wurde oder wasauchimmer geschehen ist.
Dafür ist die Recoverykonsole doch da!
Schau neben den Logs noch in das /tmp Verzeichnis, ob dort was nettes abgelegt wurde.

[timeless2]

oder du hast irgendwann mal die Einstellungen geändert und sie wurden erst jetzt bei Neustart aktiv.

[lipton]

oder du hast irgendwann mal die Einstellungen geändert und sie wurden erst jetzt bei Neustart aktiv.

Nicht das ich wüsste, bei solchen Einstellungen war ich eher vorsichtig wenn ichs nicht brauche. Werde mir morgen mal die Zeit nehmen das durchzuschauen. Aber wie ich schon sagte, wenn man als nicht-Fachmann sich so Logs anschaut weiss man nicht immer wonach man schauen soll. Natürlich weiss ich was das übliche bedeutet da drin, aber da ist auch mehr manchmal drin.

Und mit der Recovery Konsole, wie ich da die Ports wieder öffnen soll, da geb ich zu, hab ich noch keine Ahnung.

Danke für eure Hilfe bisher.

[lipton]

So, nun hab ich mich mal auf der Recoverykonsole eingeloggt, kann aber in den Logs net viel finden. Ich glaub die werden per CRON immer automatisch geleert nach ner Zeit, scheiss S4Y.

Wenns die Ports wären die zu sind, dann müsste das doch an den iptables liegen, nur scheint der Befehl nicht im Recoverymodus zu funzen. Oh mann, ist das richtig, kann ich die im Recoverymodus net auflisten oder einstellen ?

Toll, und nu ?

[daemotron]

Dir ist schon bewusst dass das Recovery-System ein Minimal-Linux ist, dass über Netzwerk auf Deiner Kiste gebootet wird und in einer Ramdisk läuft? Sprich: den Verzeichnisbaum, den Du im RS unter / findest, hat erst mal nichts mit deinem Rootie zu tun. Deine Festplatten musst Du schon selbst mounten :roll: (zumindest lassen Deine Aussagen zu Logfiles vermuten, dass Du das noch nicht getan hast).

EDIT

Oh mann, ist das richtig, kann ich die im Recoverymodus net auflisten oder einstellen ?

Das hängt davon ab, ob iptables-Support im Kernel des RS aktiviert ist oder nicht. Andererseits macht es wenig Sinn, das Recoverysystem mit einem Paketfilter dichtzumachen... Einziger Ansatzpunkt: Schau Dir mal an, welche Skripte in den einzelnen Runleveln ausgeführt werden - wenn da keins dabei ist, dass wirre iptables-Regeln setzt, hast Du vielleicht auch schlicht und ergreifend den sshd nicht im Runlevel 3 dabei...

[lipton]

Hab die platten gemounted, aber wo kann ich die Iptables sehen ? Weil wenn der Befehl in der Recoveryconsole net geht, dann kann ich da auch net versuchen die Ports, die denke ich mal darin verschlossen sind, wieder aufzumachen.

Noch ne Frage, kann man irgendwie die MySQL Datenbanken, wo auch immer die auf der Platte sind, manuell backupen oder nur wenn MySQL auch läuft ? Würd die ungerne dann löschen mit ner neuinstallation wenn ich die ports net mehr hinbekomme, sondern dann ggf. wieder importieren in ne neue Installation, wenn es sein muss. Dateinbackup mach ich gerade.

[mattiass]

Noch ne Frage, kann man irgendwie die MySQL Datenbanken, wo auch immer die auf der Platte sind, manuell backupen oder nur wenn MySQL auch läuft ?

Du solltest das ganze System backuppen. Die Datenbanken kommen automatisch mit. Einfach im Rettungssystem jede Partition mounten, Du hast dann Mountpoints wie /mnt/hda1, /mnt/hda3 usw. Zuhause legst Du ein Verzeichnis /usr/local/serverbackup an, das die Ordner hda1, hda3 usw. enthält. Das System vom Rootie ziehst Du von zuhause aus mit

Code: Select all

rsync -avzHP root@rootie.domain.xyz:/mnt/hda1/ /usr/local/serverbackup/hda1/

Natürlich diesen Befehl für jede existierende Partition (außer Swap) wiederholen. Mit so einem Vollbackup kann man auch wieder ein bootfähiges System zusammenzimmern.

[os-t]

Hab die platten gemounted, aber wo kann ich die Iptables sehen ? Weil wenn der Befehl in der Recoveryconsole net geht, dann kann ich da auch net versuchen die Ports, die denke ich mal darin verschlossen sind, wieder aufzumachen.

Wenn es iptables ist, dann muss das (wie schon angemerkt) irgendein Skript sein, dass beim Start in irgendeinem Runlevel gestartet wird - du brauchst also kein iptables-Befehl (der Dir eh nichts bringt, da keine Auflistung kommen wird: Du bist in einem eigenen System!)

S4Y hat meines Wissens doch noch ne eigene Firewall-Geschichte (keine Ahnung wie das realisiert ist) bist Du Dir sicher, dass Du damit nicht rumgespielt hast?

[lipton]

S4Y hat meines Wissens doch noch ne eigene Firewall-Geschichte (keine Ahnung wie das realisiert ist) bist Du Dir sicher, dass Du damit nicht rumgespielt hast?

Ja, denn die einzige Firewall von der ich weiss, ist die in PLESK und die hatte ich letztlich nicht verstellt, und von alleine passiert sowas nicht.

Und an die Einstellungen komm ich ja jetzt auch net dran, wenns das wäre.

[os-t]

Und an die Einstellungen komm ich ja jetzt auch net dran, wenns das wäre.

Nochmal langsam zum mitdenken:
Alles was mit iptables auf dem System umgesetzt ist (meines Wissens ist auch die PLESK-Firewall nur ein iptables-Skript) muss in Deinem System gestartet werden beim Boot. Du hast ein Rescue-System und kannst per mount die Platte einbinden. Jetzt muss also irgendwo das Skript auch auf der Platte stehen -> es muss irgendwo in einem Runlevel gestartet werden (und dort verlinkt sein)...

[lipton]

Und für jeden Tip wo das sein könnte und wie das heissen könnte, wäre ich mehr als dankbar. Sorry, aber sowas hatte ich noch nie gehabt, ich weiss es schlichtweg nicht.

[mattiass]

Und für jeden Tip wo das sein könnte und wie das heissen könnte, wäre ich mehr als dankbar. Sorry, aber sowas hatte ich noch nie gehabt, ich weiss es schlichtweg nicht.

Kannst Du bitte mal in das gemountete System chrooten, den SSH-Port umstellen (damit er nicht mit dem SSH-Port des Rettungssystems kollidiert) und mit "/usr/sbin/sshd" mal versuchen, den Daemon zu starten? Vielleicht hast Du Dir beim Crash die OpenSSL gesemmelt oder ähnliches?

[os-t]

Und für jeden Tip wo das sein könnte und wie das heissen könnte, wäre ich mehr als dankbar. Sorry, aber sowas hatte ich noch nie gehabt, ich weiss es schlichtweg nicht.

Unter Debian:

Code: Select all

/etc/rc?.d/

Dort mal suchen was so gestartet wird (S-Skripte) und dann checken was das so ist...

Gruß

PS: Achja, so langsam steigt in mir das Gefühl auf, dass Du keinen Server administrieren solltest... (auch wenn Du das nicht hören willst)

[lipton]

PS: Achja, so langsam steigt in mir das Gefühl auf, dass Du keinen Server administrieren solltest... (auch wenn Du das nicht hören willst)

Hab mich schon gefragt weil dieser Standard Satz kommt. Aber anstatt jetz auf dem Thema weiter rumzureiten, ich hab folgendes gefunden.

#!/bin/sh
#
# Automatically generated by Plesk netconf
#

set -e

echo 0 > /proc/sys/net/ipv4/ip_forward
([ -f /var/lock/subsys/ipchains ] && /etc/init.d/ipchains stop) >/dev/null 2>&1 || true
(rmmod ipchains) >/dev/null 2>&1 || true
/sbin/iptables -F
/sbin/iptables -X
/sbin/iptables -Z
/sbin/iptables -P INPUT DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset
/sbin/iptables -A INPUT -m state --state INVALID -j DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A OUTPUT -p tcp ! --syn -j REJECT --reject-with tcp-reset
/sbin/iptables -A OUTPUT -m state --state INVALID -j DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -p tcp ! --syn -j REJECT --reject-with tcp-reset
/sbin/iptables -A FORWARD -m state --state INVALID -j DROP
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A FORWARD -i lo -o lo -j ACCEPT
/sbin/iptables -t mangle -F
/sbin/iptables -t mangle -X
/sbin/iptables -t mangle -Z
/sbin/iptables -t mangle -P PREROUTING ACCEPT
/sbin/iptables -t mangle -P OUTPUT ACCEPT
/sbin/iptables -t mangle -P INPUT ACCEPT
/sbin/iptables -t mangle -P FORWARD ACCEPT
/sbin/iptables -t mangle -P POSTROUTING ACCEPT
/sbin/iptables -t nat -F
/sbin/iptables -t nat -X
/sbin/iptables -t nat -Z
/sbin/iptables -t nat -P PREROUTING ACCEPT
/sbin/iptables -t nat -P OUTPUT ACCEPT
/sbin/iptables -t nat -P POSTROUTING ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 6667 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 6667 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 9999 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 465 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 995 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 143 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 993 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 106 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 3306 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 5432 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 9008 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 9080 -j ACCEPT

/sbin/iptables -A INPUT -p udp --dport 137 -j DROP
/sbin/iptables -A INPUT -p udp --dport 138 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 139 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 445 -j DROP

/sbin/iptables -A INPUT -p udp --dport 1194 -j DROP

/sbin/iptables -A INPUT -p udp --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 53 -j ACCEPT

/sbin/iptables -A INPUT -p icmp --icmp-type 8/0 -j DROP

/sbin/iptables -A INPUT -j ACCEPT

/sbin/iptables -A OUTPUT -p tcp --dport 9999 -j DROP

/sbin/iptables -A OUTPUT -j ACCEPT

/sbin/iptables -A FORWARD -j DROP

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /opt/psa/var/modules/firewall/ip_forward.active
chmod 644 /opt/psa/var/modules/firewall/ip_forward.active
#
# End of script
#

Die meisten wichtigen Ports scheinen aber doch frei zu sein, aber warum sind die laut der Aussage von S4Y und Nmap alle zu und unerreichbar ?

[mattiass]

Die meisten wichtigen Ports scheinen aber doch frei zu sein, aber warum sind die laut der Aussage von S4Y und Nmap alle zu und unerreichbar ?

Vielleicht, weil ein Dienst nicht gestartet werden konnte? Siehe meinen Beitrag von 11:01 Uhr.

[buddaaa]

Die meisten wichtigen Ports scheinen aber doch frei zu sein, aber warum sind die laut der Aussage von S4Y und Nmap alle zu und unerreichbar ?

also ich zieh meinen hut vor jedem, der es schafft Dir bei diesen ungenauen informationen zu helfen :)

welche ports "scheinen den noch frei zu sein" und was bedeutet "frei" in dem zusammenhang ?
wie sind denn die aussagen von S$Y und nmap?
was sagt "netstat -tulpen" ?

[lipton]

was sagt "netstat -tulpen" ?

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 67740 2336/sshd

welche ports "scheinen den noch frei zu sein" und was bedeutet "frei" in dem zusammenhang ?

Naja, siehst doch hier. So waren ja auch die Einstellungen die ich im PLESK in der Firewall da eingestellt hatte.

/sbin/iptables -A INPUT -p tcp --dport 6667 -j ACCEPT
/sbin/iptables -A INPUT -p udp --dport 6667 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 9999 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 8443 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 21 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 25 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 465 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 110 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 995 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 143 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 993 -j DROP

/sbin/iptables -A INPUT -p tcp --dport 106 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 3306 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 5432 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --dport 9008 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 9080 -j ACCEPT

/sbin/iptables -A INPUT -p udp --dport 137 -j DROP
/sbin/iptables -A INPUT -p udp --dport 138 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 139 -j DROP
/sbin/iptables -A INPUT -p tcp --dport 445 -j DROP

/sbin/iptables -A INPUT -p udp --dport 1194 -j DROP

/sbin/iptables -A INPUT -p udp --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 53 -j ACCEPT

/sbin/iptables -A INPUT -p icmp --icmp-type 8/0 -j DROP

/sbin/iptables -A INPUT -j ACCEPT

/sbin/iptables -A OUTPUT -p tcp --dport 9999 -j DROP

/sbin/iptables -A OUTPUT -j ACCEPT

/sbin/iptables -A FORWARD -j DROP

Sorry das euch das nicht fachmännisch genug ist.

[buddaaa]

was sagt "netstat -tulpen" ?

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 67740 2336/sshd

dann ist auch nur SSH offen.

Du kriegst aber von nmap trotzdem noch menge meldungen weil iptables die pakete ja wegwirft bevor da ueberhaupt ein dienst antowrten koennte.

/sbin/iptables -A INPUT -p udp --dport 138 -j DROP

das duerfte Dir nmap als "open/filtered" anzeigen weil es sich genauso verhaelt wie ein geschlossener UDP-port, naemlich keine antowrt liefert.

/sbin/iptables -A INPUT -p tcp --dport 139 -j DROP

das duerfte Dir nmap als "filtered" anzeigen weil geschlossene TCP-ports normalerweile ein TCP-RST zurueckschicken, hier die pakete aber gedropt werden.

[mattiass]

dann ist auch nur SSH offen.

Klar er ist ja auch im Rettungssystem. Wie sonst soll er sich einloggen, wenn der Server bei einem Provider steht, der weder seriell, noch LARA oder ERIC bereitstellt?