Follow along with the video below to see how to install our site as a web app on your home screen.
Anmerkung: This feature may not be available in some browsers.
#!/bin/bash
echo "Starting firewall"
LOGLIMIT=20
IPTABLES=/sbin/iptables
case "$1" in
start)
# alle alten Regeln entfernen
echo "Loesche alte Regeln"
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
### ERSTELLE NEUE KETTE ZUM LOGGEN ###
# die Kette loggt den Zugriff und sendet ein ICMP Destination host unreachable
$IPTABLES -N LOGREJECT
$IPTABLES -A LOGREJECT -m limit --limit $LOGLIMIT/minute -j LOG \
--log-prefix "FIREWALL REJECT " --log-level notice --log-ip-options --log-tcp-options
$IPTABLES -A LOGREJECT -j REJECT --reject-with icmp-port-unreachable
### PROC MANIPULATION ###
# 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 ###
# wir erlauben nichts auf der INPUT-Kette
$IPTABLES -P INPUT DROP
# da die Kiste nicht routet, braucht sie auch keine Forwardings
$IPTABLES -P FORWARD DROP
# ausgehende Verbindungen werden akzeptiert
$IPTABLES -P OUTPUT ACCEPT
# zugehörige und bestehende Verbindungen werden akzeptiert, so
# dass zum OUTPUT gehörende Conns durchgehen
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# unnötig, aber manchmal will man auch mal ein Forwarding machen, das
# durch eine ausgehende Verbindung initiiert wurde, daher ACCEPT für
# bestehende und zugehörige Conns
$IPTABLES -A FORWARD -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
# Alle TCP Packete, die bis hier hin kommen, werden
# geloggt und rejected
# Der Rest wird eh per Default Policy gedroppt...
$IPTABLES -A INPUT -p tcp -j LOGREJECT
$IPTABLES -A FORWARD -p tcp -j LOGREJECT
;;
*)
echo "Usage: `basename $0` {start}" >&2
exit 64
;;
esac
exit 0
Ein Paketfilter macht bei Servern immer Sinn.
Ich habe einen Server, der hat 'nen sshd einen MTA und einen Apache laufen. Da gibt es in der Regel nichts zu filtern. Wozu bräuchte ich da einen Paketfilter? Schlussendlich würde ich damit nur ein weiteres potenzielles Risiko schaffen. Mir ist deine Aussage also zu pauschal.
Micha
Nehmen wir an, jemand schleust über eine Sicherheitslücke in einer Websoftware, die auf deinem Apache läuft, ein Skript ein. Dieses lädt sich Komponenten nach (Punkt 1 wo der Paketfilter helfen würde)
In deinem Scenario initiiert er die Verbindung eben von meinem Server aus. Hat also auch nicht wirklich geholfen...und baut eine Remote-Shell auf (Punkt 2 wo der Paketfilter greift), über die der Angreifer direkt auf deinen Server kommt.
Die Frage ist doch, wem man eher Probleme mit "kaputten" Flags zutraut. Dem sshd Code oder dem Netfilter Code. Wenn ich in den Linux Flame Thread schaue, scheint mir diese Frage längst ausreichend Beantwortet. ;-)Nehmen wir weiterhin an im SSH-Server wird eine Sicherheitslücke entdeckt, die z.B. durch falsch interpretierte TCP-Flags ausgelöst wird. Auch hier könnte ein Paketfilter das schlimmste verhindern.
Genau darum geht es mir. Ein Paketfilter sollte eben nicht dazu dienen, kaputte Software oder kaputte Konfigurationen zu kaschieren.Die Aussage ist also zwar pauschal, aber das soll sie auch sein, denn pauschal sollte man einen Paketfilter auf Servern einsetzen um beim Auftreten von bestimmten Sicherheitslücken noch ein Fangnetz zu haben.
Man blockt ausgehende Verbindungen mit Zielport 80 und 443 ggf. noch 21 und 22 und lässt diese nur für den Paketmanager zu.Wie verhindert dein Paketfilter das Nachladen von $Schadsoftware durch kaputte Webanwendungen?
Wenn der Paketfilter auch die Output-Chain überwacht hilft er halt doch und beim Server ist der ausgehende Traffic entweder auf den Ports, auf denen Dienste laufen oder durch den Admin initiiert.In deinem Scenario initiiert er die Verbindung eben von meinem Server aus. Hat also auch nicht wirklich geholfen...
Da muss ich dir allerdings Recht geben. Aber den Check auf SYN-Flags funktioniert meist.Die Frage ist doch, wem man eher Probleme mit "kaputten" Flags zutraut. Dem sshd Code oder dem Netfilter Code. Wenn ich in den Linux Flame Thread schaue, scheint mir diese Frage längst ausreichend Beantwortet. ;-)
Genau darum geht es mir. Ein Paketfilter sollte eben nicht dazu dienen, kaputte Software oder kaputte Konfigurationen zu kaschieren.
Man blockt ausgehende Verbindungen mit Zielport 80 und 443 ggf. noch 21 und 22 und lässt diese nur für den Paketmanager zu.
Bleiben noch mehr als 65000 Ports für ausgehende Verbindungen übrig. Was ist mit denen? Du magst damit den einen oder anderen besoffenen Vollidioten für ein paar Sekunden behindern, mehr aber auch nicht.
Micha
barnim hat gesagt.:Im Heimbereich wirkt sich sowas eher nicht aus, aber wenn ich überlege, dass ich auf jedem meiner Server einen Paketfilter pflegen müsste, wird mir schon ganz anders zumute.
Da habe ich lieber eine zentrale Lösung im Netz stehen.
In meinen Honeypots ist jedenfalls bisher noch kein Bot gelandet, der seine "Erweiterungen" nicht ganz normal über wget, lynx oder LWP von Web- oder FTP-Servern geholt hat.
Hey...ich habe nicht gesagt, dass Paketfilter nie Sinn machen (das wäre ja auch totaler Unsinn). Du hast gesagt das "ein Paketfilter bei Servern immer Sinn macht". Das sehe ich nicht so.Bei einem Webserver kommt z.B. auch noch der DDoS-Schutz hinzu, der ohne Paketfilter kaum umsetzbar ist. Spätestens wenn du mal ein grösseres Webcluster zu verwalten hast, das häufig unter DDoS-Angriffen steht, wirst du dir ganz sicher überlegen, ob du wirklich ohne Paketfilter auskommst.
In vielen Fällen gibt es dafür überhaupt keinen Grund.Tatsache ist nunmal, dass man Server besser durch eine Firewall schützen sollte.
Bei den zentralen Lösungen steckt auch zumeist ein Paketfilter dahinter.
Tun die meisten Angreifer aber nicht, wenn sie automatisierte Tools nutzen. Und wie bereits gesagt: >90% aller Angriffe auf Server laufen über genau solche Tools. Und das sind keineswegs immer nur "Kinderattacken", sondern oft genug Botnetze, die sehr gut gepflegt werden und Lücken nutzen, die bisher nicht publiziert wurden.Mit viel magischen Kenntnissen soll es - gerüchteweise - sogar möglich sein, Webserver auf anderen Ports als 80/443 lauschen zu lassen.
Hab ich auch nie behauptet. Er ist aber oft genug ein Fangnetz, wie mir die letzten fast 15 Jahre als Sysadmin gezeigt haben. Da statistisch auf 10.000 Zeilen Code ein Bug kommt und auf 120.000 Zeilen eine Sicherheitslücke, sollte man durchaus auch mit "kaputter" Software rechnen, wenn man Server betreibt.Du magst dadurch, dass du ein paar Ports für outgoing traffic sperrst, Kinderattacken erschweren, einen echten Schutz bietet das nicht. Wenn du dich darauf verlässt, dass dein Paketfilter das schon irgendwie macht, hast du schon verloren. Ein Paketfilter ist kein Fallback für kaputte Software/Konfigurationen.
Welches Server-Programm ist nicht anfällig für DDoS-Angriffe? Oder anders gefragt: Für welches Server-Programm braucht man keinen Paketfilter zur Abwehr von DDoS? Selbst beim SSH-Server wird empfohlen die TCP-Flags immer zu prüfen und das geht am einfachsten über einen Paketfilter wie iptables:Hey...ich habe nicht gesagt, dass Paketfilter nie Sinn machen (das wäre ja auch totaler Unsinn). Du hast gesagt das "ein Paketfilter bei Servern immer Sinn macht". Das sehe ich nicht so.
$IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT
# Beispiel: Pings unterbinden
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -j DROP
In vielen Fällen gibt es dafür überhaupt keinen Grund.
Und schon zum simplen Blockieren oder steuern von ICMP-Requests braucht man einen Paketfilter.
Code:# Beispiel: Pings unterbinden $IPTABLES -A INPUT -p icmp --icmp-type echo-request -j DROP
Ein Paketfilter ist kein Fallback für kaputte Software/Konfigurationen.
Letztendlich muss das jeder selbst wissen, ich sehs ähnlich wie mime. Wenn ein Angreifer seinen Schadcode durch meinen offenen Port 80 reinjagt, hilft mir ein Paketfilter nicht viel, imho macht z.B. ein IDS/IPS da mehr Sinn.