Firewall auf V-Server, NTP Konfiguration

X

xblax

0
Halllo :)

Ich habe mir für meinen V-Server einige Grundlegende Firewallregeln erstellt und würde mal gernde von Leuten mit mehr Erfahrung hören ob das so ok ist.

Code: 
#!/bin/sh
echo "Initialisiere Firewall ..."

# Firewall Regeln löschen
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -Z

# Loopback Kommunikation
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Stateful Inspection
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -m state --state INVALID -j LOG --log-prefix "FW-INVALID-DROP:"
iptables -A INPUT -m state --state INVALID -j DROP

# SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

# ICMP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

# DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

# WWW
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# NTP
iptables -A INPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT

# Ausgehender Traffic der gedropt wird soll geloggt werden
iptables -A OUTPUT -j LOG --log-prefix "FW-OUT-DROP:"

echo "Firewall ist konfiguriert und aktiv ..."
Ist das soweit ok oder sollte ich noch irgendwas ergänzen? In manchen Beispielen wird am Ende jeglicher Traffic der gedroppt wird geloggt, aber das spammt mir nur das ganze Logfile zu hab ich das Gefühl, weil ich eine Menge "Hintergrundrauschen" mitlogge.

Meine 2. Frage ist zum NTP Daemon. Der Läuft momentan so ziemlich in der Standart Konfiguration aber ich würde ihn gerne so einstellen, dass er nur die Zeit Synchronisiert und selber keine Dienste nach außen hin anbietet. Könnte ihn zwar einfach in der Firewall blocken, aber das ist keine so saubere Art denke ich. Die Manpage finde ich ziemlich undurchsichtig, deshalb hoffe ich, dass jemand bescheid weiß ;)

xblax
 
Das Logging von verworfenenen Paketen solltest du besser rausnehmen, sonst müllst du dir bei einem Rechner mit statischer IP ganz schnell die Logs zu. Lasse ungültige Anfragen lieber durch ein IDS loggen. Ausserdem gehören zu einer guten Firewall auch noch ein paar procfs-Tunings (SYN/ACK runterschrauben, IP-Spoofing unterbinden, nicht jedes ICMP beantworten usw.). Die OUTPUT-Regeln für deine Services sind übrigens total unsinnig. Ausgehende Ports werden dynamisch zugewiesen. Also machst du dir entweder eine entsprechend dynamische Firewall oder du lässt ausgehenden Traffic einfach zu, wie es üblich ist.

Als Beispiel mal meine (etwas vereinfachte und gekürzte) Firewall:

Code: 
#!/bin/bash

IPTABLES=/sbin/iptables

case "$1" in
start)
        # alle alten Regeln entfernen
        echo "Loesche alte Regeln"
        $IPTABLES -F
        $IPTABLES -X
        $IPTABLES -t nat -F

        ### PROC MANIPULATION ###
        echo "Setze ProcFS-Werte"
        # auf Broadcast-Pings nicht antworten
        echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
        # halt die Klappe bei komischen ICMP Nachrichten
        echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
        # Kicke den ganzen IP Spoofing Shit
        # (Source-Validierung anschalten)
        echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
        # Setze Default-TTL auf 61 (Default fuer Linux ist 64)
        echo 61 > /proc/sys/net/ipv4/ip_default_ttl
        # sende RST-Pakete wenn der Buffer voll ist
        echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
        # warte max. 30 secs auf ein FIN/ACK
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
        # unterbreche Verbindungsaufbau nach 3 SYN-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
        # unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

        ### MAIN PART ###
        echo "Firewall wird initialisiert..."
        $IPTABLES -P INPUT DROP
        $IPTABLES -P FORWARD DROP
        $IPTABLES -P OUTPUT ACCEPT
        $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
        # im Loopback koennen wir jedem trauen 
        $IPTABLES -A INPUT -i lo -j ACCEPT
        # erlaube Pings
        $IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
        # erlaube SSH
        $IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT
        # SMTP 
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 465 -j ACCEPT
        # POP3
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 110 -j ACCEPT
        # IMAP
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
        # IMAPS
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 993 -j ACCEPT
        # Webserver
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
        $IPTABLES -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
        # MYSQL-Zugriff für Application Server zulassen
        $IPTABLES -A INPUT -m state --state NEW,ESTABLISHED,RELATED --source 123.123.123.124 -p tcp --dport 3306 -j ACCEPT
        $IPTABLES -A INPUT -m state --state NEW,ESTABLISHED,RELATED --source 123.123.123.125 -p tcp --dport 3306 -j ACCEPT
        ;;
*)
        echo "Usage: `basename $0` {start}" >&2
        exit 64
        ;;
esac

exit 0

Edit: Zum NTP-Server... Wirf den einfach runter und mach dir folgende Zeile in die /etc/crontab:

Code: 
5 * * * * root ntpdate ptbtime1.ptb.de > /dev/null 2>&1

Erspart unnötige Service-Überwachung für den ntpd. ;)
 
Gut ich hab das jetzt nochmal etwas angepasst. Ein paar ProcFS Einstellungen hab ich auch noch vom Debian Security Manual übernommen.
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.de.html#s-network-secure

Code: 
#!/bin/bash

IPTABLES=/sbin/iptables

case "$1" in
start)

	### Proc Werte ###
	echo "Setze ProcFS-Werte."

	# Keine Antwort auf Broadcast Pings
	echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
	# Ignoriere komische ICMP Nachrichten
	echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
	# Source Validierung (gegen IP-Spoofing)
	echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
	# Kein IP-Forwarding (kein Router)
	echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
	echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
	# TCP syn cookie protection
	echo 1 > /proc/sys/net/ipv4/tcp_syncookies
	# Keine ICMP Redirects
	echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
    	echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
        # Setze Default-TTL auf 61 (Default fuer Linux ist 64)
        echo 61 > /proc/sys/net/ipv4/ip_default_ttl
        # sende RST-Pakete wenn der Buffer voll ist
        echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
        # warte max. 30 secs auf ein FIN/ACK
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
        # unterbreche Verbindungsaufbau nach 3 SYN-Paketen (default 6)
        echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
        # unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen (default 6)
        echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

	### IPTABLES ###
	echo "Firewall wird initialisiert ..."

	# Firewall Regeln löschen
	$IPTABLES -F
	$IPTABLES -X
	$IPTABLES -P INPUT DROP
	$IPTABLES -P OUTPUT DROP
	$IPTABLES -P FORWARD DROP
	$IPTABLES -Z

	# Loopback Kommunikation
	$IPTABLES -A INPUT -i lo -j ACCEPT
	$IPTABLES -A OUTPUT -o lo -j ACCEPT

	# Stateful Inspection
	$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
	$IPTABLES -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

	# ICMP
	# erlaube nur Pings von außen
	$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
	# von innen ist alles erlaubt
	$IPTABLES -A OUTPUT -p icmp -j ACCEPT

	# SSH
	$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
	$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT

	# DNS
	$IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
	$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT

	# WWW
	$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
	$IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT

	# NTP
	$IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 123 -j ACCEPT

	# Ausgehender Traffic der gedropt wird soll geloggt werden
	$IPTABLES -A OUTPUT -j LOG --log-prefix "FW-OUT-DROP:"
	;;
*)
	echo "Usage: `basename $0` {start}" >&2
	exit 64
	;;
esac

exit 0

Die OUTPUT-Regeln brauche ich damit der Server auch von sich aus eine Verbindung Initialisieren kann.
Gedropte Pakete werden nur ausgehend geloggt, dann kann ich sehen ob irgendwas nach draußen will, was eigentlich nicht da sein sollte.

Der ntpd wird abgeschaltet, geht so in der Tat einfacher.

Kannst du mir noch erklären warum du für SSH
Code: 
# erlaube SSH
$IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT
statt
Code: 
$IPTABLES -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
hast?
 
Zuletzt bearbeitet:
Meine Firewall hat jetzt folgendes von innen abgefangen:

Code: 
syslog.3:Jan 10 00:26:33 vadmin497 kernel: [368928.850950] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=79.48.82.14 LEN=259 TOS=0x00 PREC=0x00 TTL=61 ID=51537 DF PROTO=TCP SPT=80 DPT=39956 WINDOW=215 RES=0x00 ACK PSH FIN URGP=0
syslog.3:Jan 10 00:27:06 vadmin497 kernel: [368962.642916] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=79.48.82.14 LEN=259 TOS=0x00 PREC=0x00 TTL=61 ID=51538 DF PROTO=TCP SPT=80 DPT=39956 WINDOW=215 RES=0x00 ACK PSH FIN URGP=0
syslog.3:Jan 10 01:35:40 vadmin497 kernel: [373076.248510] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=88.49.16.234 LEN=836 TOS=0x00 PREC=0x00 TTL=61 ID=55468 DF PROTO=TCP SPT=22 DPT=39455 WINDOW=181 RES=0x00 ACK PSH URGP=0
syslog.3:Jan 10 01:36:09 vadmin497 kernel: [373105.209127] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=88.49.16.234 LEN=836 TOS=0x00 PREC=0x00 TTL=61 ID=55469 DF PROTO=TCP SPT=22 DPT=39455 WINDOW=181 RES=0x00 ACK PSH URGP=0
syslog.3:Jan 10 01:37:07 vadmin497 kernel: [373163.129788] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=88.49.16.234 LEN=836 TOS=0x00 PREC=0x00 TTL=61 ID=55470 DF PROTO=TCP SPT=22 DPT=39455 WINDOW=181 RES=0x00 ACK PSH URGP=0
syslog.3:Jan 10 01:39:03 vadmin497 kernel: [373278.971205] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=88.49.16.234 LEN=836 TOS=0x00 PREC=0x00 TTL=61 ID=55471 DF PROTO=TCP SPT=22 DPT=39455 WINDOW=181 RES=0x00 ACK PSH URGP=0

Ich weiß aber nicht genau, wie ich das interpretieren soll, schließlich kann ich nicht sehen, was genau bewirkt hat das von innen eine Verbindung aufgebaut werden sollte.
Ist das ein Grund sich sorgen zu machen?
 
Du solltest dir eher Sorgen darum machen, dass du keinen Plan hast was auf deinem Server abgeht und dir offenbar das Wissen fehlt Logdaten richtig auszuwerten. - http://www.root-und-kein-plan.ath.cx - Ich hoffe du hast einen guten Anwalt und eine Rechtsschutzversicherung. Als Betreiber des Servers bist du für diesen haftbar.
 
xblax hat gesagt.:
Ist das ein Grund sich sorgen zu machen?
Zum Vergrößern anklicken....

Was läuft eigentlich alles auf dem Server?
Und wie sind die einzelnen Dienste so konfiguriert? (Beschränkung der Zugriffs-Berechtigung auf die Verzeichnisse, auf die sie unbedingt müssen, etc.)

wieviele Domains liegen da drauf und wieviele Leute haben da offiziell Zugriff?
(und da ich mal davon ausgehe, dass ein Apache da drauf läuft: was wiederrum liegt auf den einzelnen Domains z.B. an Web-Applikationen - Foren/Blogs/... und sind diese wirklich aktuell?)

beobachtest du regelmäßig, was an Prozessen gestartet ist (und was davon auch wirklich laufen darf)? (z.B. mit top oder htop)

Scannst du deinen Server regelmäßig auf RootKits? (z.B. mit rkhunter)

Schaust du in den Verzeichnissen von z.B. Web- und FTP-Server regelmäßig, ob plötzlich unbekannte Dateien auftauchen?

Und schaust du auch mal in die auth.log, wer so alles auf deinen Server will?

Bei mir war's z.B. so, dass über Monate nur einzelne SSH-Login-Versuche mit Username="root" stattgefunden haben - immer nur wenige Minuten (und da "root" in meiner SSH-Config eh ausgeschlossen ist, hab ich die halt machen lassen... war ja nicht dolle...)
Kaum lief unsere Fachbereichs-Community 'ne Woche mit auf dem Server, wurde der Server regelrecht mit SSH-Login-Attempts überflutet...
Aber dank fail2ban werden die jetzt mittels iptables ausgesperrt.

Soll heißen: nach jeder größeren Änderung erstrecht bewusst und intensiv schauen, was der Server so macht.


Der Verbindungs-Aufbau nach Italien wurde ja von der Firewall blockiert...
Aber woher kommt der Verbindungsversuch überhaupt?

Schau z.B. in der access.log des Apachen, ob irgendwelche auffälligen Anfragen drin sind (RemoteFileInclusion / SQL-Injection / etc.)
 
bitmuncher hat gesagt.:
Du solltest dir eher Sorgen darum machen, dass du keinen Plan hast was auf deinem Server abgeht und dir offenbar das Wissen fehlt Logdaten richtig auszuwerten. - http://www.root-und-kein-plan.ath.cx - Ich hoffe du hast einen guten Anwalt und eine Rechtsschutzversicherung. Als Betreiber des Servers bist du für diesen haftbar.
Zum Vergrößern anklicken....

Ich glaube schon, dass ich genug wissen habe, um den Server guten Gewissens ins Netz stellen zu können. Über mögliche Konsequenzen bin ich mir durchaus im klaren.
Allerdings finde ich es sehr schwachsinnig immer nur auf diese supertolle Seite zu verweisen anstatt mal was zu erklären. Nicht jeder ist schließlich ein Admin mit vielen Jahren Erfahrung.

Wie kann ich das denn nun interpretieren?
Anhand von SPT=22 oder SPT=80 sehe ich, dass es sich wohl in irgendeiner Weise um den SSH oder HTTP Daemon handelt. Inwiefern ist SPT ein zuverlässiger Indikator dafür dass die Pakete von diesem Dienst stammen?

Warum sendet der Server ein ACK Paket müsste da nicht schon vorher ein SYN Paket gesendet worden sein? Was hat das FIN da zu suchen, schließlich müsste dafür ja schon vorher eine Verbindung aktiv gewesen sein, die eigentlich auch von der Firewall geloggt sein müsste.

Wenn ich auf der Shell eine Verbindung
Code: 
ssh -p 1337 google.de
versuche aufzubauen bekomme ich
Code: 
Jan 12 19:26:06 vadmin497 kernel: [610102.019019] FW-OUT-DROP:IN= OUT=eth0 SRC=84.19.167.80 DST=74.125.77.104 LEN=60 TOS=0x00 PREC=0x00 TTL=61 ID=46880 DF PROTO=TCP SPT=36443 DPT=1337 WINDOW=5840 RES=0x00 SYN URGP=0
so wie ich das von der Filterregel erwarte.

//Noch die Antwort auf beavisbees Beitrag:
beavisbee hat gesagt.:
Was läuft eigentlich alles auf dem Server?
Und wie sind die einzelnen Dienste so konfiguriert? (Beschränkung der Zugriffs-Berechtigung auf die Verzeichnisse, auf die sie unbedingt müssen, etc.)
Zum Vergrößern anklicken....
Nur nginx und ssh bisher.

wieviele Domains liegen da drauf und wieviele Leute haben da offiziell Zugriff?
(und da ich mal davon ausgehe, dass ein Apache da drauf läuft: was wiederrum liegt auf den einzelnen Domains z.B. an Web-Applikationen - Foren/Blogs/... und sind diese wirklich aktuell?)
Zum Vergrößern anklicken....
Eine Domain und da ist noch nix installiert. Zugriff hab nur ich.

beobachtest du regelmäßig, was an Prozessen gestartet ist (und was davon auch wirklich laufen darf)? (z.B. mit top oder htop)
Zum Vergrößern anklicken....
Ja mach ich abundzu. Keine Auffälligkeiten.

Scannst du deinen Server regelmäßig auf RootKits? (z.B. mit rkhunter)
Zum Vergrößern anklicken....
Nein hab ich bisher noch nicht gemacht. Müsste ich mich erst weiter mit auseinandersetzen.

Schaust du in den Verzeichnissen von z.B. Web- und FTP-Server regelmäßig, ob plötzlich unbekannte Dateien auftauchen?
Zum Vergrößern anklicken....
Ja auch da ist nix auffällig.

Und schaust du auch mal in die auth.log, wer so alles auf deinen Server will?
Zum Vergrößern anklicken....
Ja jede Menge Versuche für alles Möglich Usernamen. Aber da die Passwörter sicher sind mach ich mir da eigentlich weniger Sorgen. Fail2Ban werde ich auch bei gelegenheit mal installieren.

Der Verbindungs-Aufbau nach Italien wurde ja von der Firewall blockiert...
Aber woher kommt der Verbindungsversuch überhaupt?

Schau z.B. in der access.log des Apachen, ob irgendwelche auffälligen Anfragen drin sind (RemoteFileInclusion / SQL-Injection / etc.)
Zum Vergrößern anklicken....
Ja klar im access.log sind jede Menge Anfragen nach Phpmyadmin und so, aber nichts was sorgen macht. Gibt eh nur immer Error 404.

Also eigentlich sehe ich momentan nur eine sehr geringe Angriffsfläche.
 
Zuletzt bearbeitet:
xblax hat gesagt.:
Ich glaube schon, dass ich genug wissen habe, um den Server guten Gewissens ins Netz stellen zu können.
...

Nein hab ich bisher noch nicht gemacht. Müsste ich mich erst weiter mit auseinandersetzen.
Zum Vergrößern anklicken....

Was zu beweisen war. ;)

Allerdings finde ich es sehr schwachsinnig immer nur auf diese supertolle Seite zu verweisen anstatt mal was zu erklären. Nicht jeder ist schließlich ein Admin mit vielen Jahren Erfahrung.
Zum Vergrößern anklicken....
Ich finde es sehr notwendig, solange Leute ohne ausreichende Erfahrung Server verwalten. Admin sollten _immer Erfahrung_ mit der Software haben, die sie einsetzen, sei es nun das System selbst oder irgendeine Server-Applikation. Jeder Admin, der was auf sich (oder die von ihm erwartete Systemsicherheit) hält, wird eine Server-Software immer erst in einem LAN testen und kennenlernen, bevor er sie im Internet einsetzt. Was denkst du wohl, warum ich bisher nie OpenSolaris auf meinen Servern eingesetzt habe? Weil ich mir selbst sage, dass mein Kenntnisstand zu diesem System dazu noch nicht reicht und mir z.B. noch diverse typische Log-Einträge nicht vertraut sind, im Kernel Prozesse ablaufen, die essentiell sind, die ich aber nicht ausreichend kenne usw.

Vielleicht liest du die verlinkte Seite einfach nochmal durch, ohne dich gleich in deinem sichtlich großen Ego beleidigt zu fühlen und denkst einfach mal ganz objektiv über deinen Kenntnisstand und das dort geschriebene nach. Folgendes Schema und ein wenig Selbstehrlichkeit könnte dir dabei helfen. Es zeigt einfach nur mal auf welche Bereiche ein Admin mit "seinem" System beherrschen sollte, bevor er sich an Servern vergreift. Einige wenige wie das Hardware-Monitoring sind natürlich bei einem VServer nicht oder nur bedingt notwendig.

Anhang anzeigen 3089

Im übrigen helfe ich dir gern weiter, wenn du bereit bist deinen Lerntrieb auf einem Rechner in deinem heimischen LAN auszulassen und nicht auf einem 100MBitler, der in Sekunden Megabyteweise Spam verschleudern kann, was vor allem dann schlimm wird, wenn der zuständige Admin nicht mitbekommt, wenn auf seiner Kiste was falsch läuft. Selbiges unterstelle ich jedem Admin, der ohne ersichtlichen Grund auf der Output-Chain nur bestimmte Dienste zulässt. ;) Das zeugt im Normalfall davon, dass sie Angst haben der Server könnte etwas senden, von dem sie nichts wissen, und das wiederum ist ein Zeichen für schlechtes Monitoring des Systemzustands.

Inwiefern ist SPT ein zuverlässiger Indikator dafür dass die Pakete von diesem Dienst stammen?
Zum Vergrößern anklicken....
Garnicht, solange du nicht überwachst, dass der Dienst ununterbrochen gelaufen ist. Es gibt mittlerweile einige Trojaner, die einen Dienst nur kurzzeitig beenden um seinen Port zum Senden von Passwörtern u.ä. zu verwenden, da dieser in vorgeschalteten Firewalls ja frei ist. Auch solche Dinge sollte ein Admin ganz von sich aus bedenken, weswegen du durch Sperren der Output-Chain eben nicht immer mibekommen würdest, wenn auf deinem Server was abgeht, was du nicht willst.
 
bitmuncher hat gesagt.:
Was zu beweisen war. ;)
Im übrigen helfe ich dir gern weiter, wenn du bereit bist deinen Lerntrieb auf einem Rechner in deinem heimischen LAN auszulassen und nicht auf einem 100MBitler, der in Sekunden Megabyteweise Spam verschleudern kann, was vor allem dann schlimm wird, wenn der zuständige Admin nicht mitbekommt, wenn auf seiner Kiste was falsch läuft. Selbiges unterstelle ich jedem Admin, der ohne ersichtlichen Grund auf der Output-Chain nur bestimmte Dienste zulässt. ;) Das zeugt im Normalfall davon, dass sie Angst haben der Server könnte etwas senden, von dem sie nichts wissen, und das wiederum ist ein Zeichen für schlechtes Monitoring des Systemzustands.


Garnicht, solange du nicht überwachst, dass der Dienst ununterbrochen gelaufen ist. Es gibt mittlerweile einige Trojaner, die einen Dienst nur kurzzeitig beenden um seinen Port zum Senden von Passwörtern u.ä. zu verwenden, da dieser in vorgeschalteten Firewalls ja frei ist. Auch solche Dinge sollte ein Admin ganz von sich aus bedenken, weswegen du durch Sperren der Output-Chain eben nicht immer mibekommen würdest, wenn auf deinem Server was abgeht, was du nicht willst.
Zum Vergrößern anklicken....

Naja ich denke erstmal, dass die "Angst das irgendetwas nicht stimmt" sowieso Grundvorraussetzung ist, denn sonst würde ja kein Grund dazu bestehen beispielsweise mit rkhunter nach irgendwelchen Auffälligkeiten zu Scannen.
Ich gehe ja auch nicht davon aus, dass ich dadurch zu 100% alles mitbekommen würde, aber es ist immerhin ein weiterer Indikator. Auf jedem noch so gut abgesichertem System gibt es immer ein Restrisiko und dann ist man doch froh wenn man Auffäligkeiten wenigstens im Nachhinein bemerkt.
Es gibt einfach keinen Grund warum irgendetwas nach draußen kommen sollte, was ich nicht zugelassen habe.

Die Pakte die ich da mitgeloggt habe wurden wohl nur gedroppt weil Iptables die Verbindung aus irgendeinem Grund schon als beendet gesehen hat. Siehe zum Beispiel hier:
http://lists.netfilter.org/pipermail/netfilter/2005-August/062059.html
Loggen für die OUTPUT Chain ist also wohl im Endeffekt nur interessant für Sourceports die nicht von einem Dienst belegt sind.
Seit ich fail2ban drauf habe fange ich logischer Weise noch viel mehr von diesen Paketen ab.

Ich hab mir die Seite übrigens durchaus mal angeschaut, kannte sie sogar vorher schon :P und ich bin mir ziemlich Sicher, dass mein V-Server in der jetztigen Konfiguration kein Sicherheitsrisiko darstellt. Dienste über die ich keinen Überblick habe installiere ich nicht.
Es ist auch nicht das Erste mal, dass ich mit Linux zu tun habe und hab auch schon einiges im LAN ausprobiert. Nur Solche Pakete fängt man da eben eher selten auf.
 
xblax hat gesagt.:
Es ist auch nicht das Erste mal, dass ich mit Linux zu tun habe und hab auch schon einiges im LAN ausprobiert. Nur Solche Pakete fängt man da eben eher selten auf.
Zum Vergrößern anklicken....

Was doch nur zeigt, dass du noch nie einen clientseitigen Verbindungsabbruch im LAN simuliert hast und daher nicht weisst, wie der Server darauf reagiert. Ein Server-Admin, der nicht weiss, was passiert, wenn ein Client die Verbindung abbricht, der Tools wie rkhunter, chkrootkit u.ä. noch nicht benutzt hat, der vermutlich auch Tripwire, AIDE o.ä. nicht einsetzt oder kennt usw. ... aber klar, das ist bestimmt ausreichend Wissen um einen Server zu betreiben. :rolleyes:
 
Wie bereitet man sich eigentlich darauf vor Severadmin zu werden?
Gibts dafür Standardliteratur oder wie fängt man da an?
Sever im eigenen LAN aufzusetzen und zu betreiben ist ja kein Problem die werden auch nicht angegriffen.

MfG
 
LPIC-Schulungen sind schonmal ein guter Anfang um das Grundlagenwissen eines Linux-Admins zu bekommen. Selbst wenn man die Prüfungen nicht ablegt, sollte man das dafür notwendige Wissen drin haben.
Server im LAN kann man auch selbst angreifen. Dadurch vertieft man auch gleich das Wissen um verschiedene Angriffstechniken. Alternativ bindet man eine DynDNS-Adresse an seinen Homeserver und verteilt die Adresse in Mailinglisten, wo sich Leute rumtreiben, die sich gern mal austoben. Allzuviel Schaden kann ein Rechner mit so stark begrenztem Upload, wie es bei ADSL-Leitungen der Fall ist, nicht anrichten, vor allem wenn man das Verhalten des Systems dabei im Auge behält und es nach einem erfolgreichen Angriff vom Netz nimmt um den Angriff zu analysieren. Bei Servern in Rechenzentren liegt aber zumeist eine synchrone 100MBit-Leitung an, über die entsprechend schnell viel Spam, Malware, gecrackte Software usw. verteilt werden kann, wenn die Kiste einmal erfolgreich angegriffen wurde. Das kann im Falle einer Anzeige eines Geschädigten daher recht schnell sehr teuer werden.
Und natürlich gibt es auch ausreichend Kurse die sich speziell mit Server-Sicherheit beschäftigen. Aber nicht zuletzt sollte man sich einfach auch mit der eingesetzten Server-Software vertraut machen, Security-Newsletter verfolgen usw.. Gerade die Doku von Server-Software geht zumeist auch auf Sicherheitsaspekte ein. Zu Standard-Software wie iptables gibt es ganze Bücher, weil gerade eine Firewall-Konfiguration immer eine recht komplexe Sache ist. Solche Bücher zu lesen kann durchaus auch hilfreich sein.
 
Z.B. dies
http://www.amazon.de/Linux-Server-u...=sr_1_1?ie=UTF8&s=books&qid=1263505884&sr=8-1

Geht natürlich auf eine große Bandbreite von Themen ein und daher nicht immer soweit ins Detail wie man gerne hätte, aber es kann einem einen guten Überblick verschaffen. Details kann man dann im Internet nachlesen

Ansonsten gibts natürlich auch jede Menge Literatur, die einen speziellen Teilbereich abdeckt, aber wenn man da nicht eine gute Biblitohekt in der Nähe hat wirds schnell sehr teuer.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben