Firewall ?

Hat man auf Linux (Ubuntu) auch eine Firewall ? so wie bei z.b.. Vista und falls nein brauche ich das ?

Gruss Pedro
 
moing , ich habe guarddog als firewall tool unter linux installiert. ist in meinen augen sehr einfach zu konfiguieren, es gibt natürlich andere firewall für linux. gruss whoopy84

hier link Guarddog

;)
 
Hi,

letzten Endes benutzen die doch eh alle nur iptables / netfilter. Kannst dir auch das mal anschauen.

ciao
serow
 
Ich würde Dir, genau wie Serow, dazu raten Dich einfach mal ein bisschen mit Iptables zu beschäftigen. Eine ganz brauchbare (wenn auch schon ältere) Einführung auf Deutsch gibt es z. B. hier, auf Englisch gibt's natürlich noch wesentlich mehr - einfach mal googeln...;)
 
Hallo zusammen,

die Frage ist, inwiefern einfache Paketfilter Sinn machen (oder nicht).
Ich persönlich nutze sowohl auf meinen Desktop- als auch Serversystemen keine Paketfilter, eine "Firewall" steht in Form einer Astaro-Box vorm Netz:)

Gruß
barnim

@p3i)20: Vielleicht ist auch Shoreline Firewall für dich interessant.
 
Ein Paketfilter macht bei Servern immer Sinn. Auf Desktops eher weniger, da dort üblicherweise keine Programme laufen, die von aussen erreichbar sind bzw. diese einfach an localhost gebunden werden können, so dass man auch nur über den gleichen Rechner drauf zugreifen kann.

Aber... und nun kommt das grosse ABER... auch Linux-Desktops werden immer mal wieder Opfer von Angriffen, wobei Bots eingeschleust werden. Will man verhindern, dass der Owner direkt Kontakt mit seinem Bot/Trojaner aufnehmen kann, sollte man dennoch einen Paketfilter einsetzen. Damit kann man sicherstellen, dass ein vom Bot geöffneter Port nicht von aussen erreichbar ist. Das hilft natürlich nur bedingt, da viele Bots via IRC gesteuert werden.

Wenn man allerdings einen Router mit Firewall vor der Kiste hat, reicht im Normalfall auch dessen Firewall aus, die in den meisten Fällen eh ein Paketfilter ist. Man sollte dann halt darauf achten, dass keine Portforwardings aktiv sind und das ggf. auch monitoren oder regelmässig überprüfen, denn häufig genug werden auch Router gehackt. Dabei wird dann auf dem Desktop-Rechner ein Bot eingeschleust, der sich selbst im Router ein Port-Forwarding einrichtet.

Ein simple Linux-Desktop-Firewall, die man einfach über das Init-System starten kann, könnte z.B. so aussehen:

Code:
#!/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
 
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) und baut eine Remote-Shell auf (Punkt 2 wo der Paketfilter greift), über die der Angreifer direkt auf deinen Server kommt. Spätestens dann wirst du dich ärgern, dass du keinen Paketfilter hattest.

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.

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.
 
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)

Wie verhindert dein Paketfilter das Nachladen von $Schadsoftware durch kaputte Webanwendungen?

und baut eine Remote-Shell auf (Punkt 2 wo der Paketfilter greift), über die der Angreifer direkt auf deinen Server kommt.
In deinem Scenario initiiert er die Verbindung eben von meinem Server aus. Hat also auch nicht wirklich geholfen...

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.
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. ;-)

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.
Genau darum geht es mir. Ein Paketfilter sollte eben nicht dazu dienen, kaputte Software oder kaputte Konfigurationen zu kaschieren.

Micha
 
Zuletzt bearbeitet:
Wie verhindert dein Paketfilter das Nachladen von $Schadsoftware durch kaputte Webanwendungen?
Man blockt ausgehende Verbindungen mit Zielport 80 und 443 ggf. noch 21 und 22 und lässt diese nur für den Paketmanager zu.

In deinem Scenario initiiert er die Verbindung eben von meinem Server aus. Hat also auch nicht wirklich geholfen...
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.

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. ;-)
Da muss ich dir allerdings Recht geben. Aber den Check auf SYN-Flags funktioniert meist. ;)

Genau darum geht es mir. Ein Paketfilter sollte eben nicht dazu dienen, kaputte Software oder kaputte Konfigurationen zu kaschieren.

Er kann aber oft das Schlimmste bei 0-Day-Exploits verhindern.
 
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
 
Moin zusammen,

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.

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.

Gruß
barnim
 
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

Erfahrungsgemäss finden über 90% der Angriffe auf Webapplikationen durch automatisierte Tools statt. Passende Exploits werden in Bots eingebaut und diese scannen das Web nach angreifbaren Webapps. Ist erstmal ein Bot eingeschleust, tut dieser seine Arbeit fast vollständig automatisiert. 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.

Und ich sage ja auch nicht, dass man alle Angriffe mit einem Paketfilter verhindern kann, sondern dass sie 1. in vielen Fällen helfen kann schlimmeres zu verhindern und 2. gegen bestimmte Angriffsformen hilft.

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. ;)

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.

Bei den zentralen Lösungen steckt auch zumeist ein Paketfilter dahinter. Schau dir einfach mal die üblichen Appliance-Lösungen an. Das sind in den meisten Fällen Boxen mit einem embedded BSD, wo die Firewall über PF gelöst ist. Da kann man sich auch einfach eine Linux-Kiste davor stellen, APF und Deflate draufpacken noch ein NIDS dazu und schon hat man die gleiche Funktionalität zum halben Preis. Ob die Firewall nun vor die Server geschaltet ist oder auf den Servern läuft (z.B. weil es sich um Rootserver handelt, wo man nicht einfach mal einen Firewall-Gateway vorschalten kann) ist dabei imo ziemlich unerheblich. Tatsache ist nunmal, dass man Server besser durch eine Firewall schützen sollte.
 
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.

Mit viel magischen Kenntnissen soll es - gerüchteweise - sogar möglich sein, Webserver auf anderen Ports als 80/443 lauschen zu lassen. ;)

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.

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. ;)
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.

Tatsache ist nunmal, dass man Server besser durch eine Firewall schützen sollte.
In vielen Fällen gibt es dafür überhaupt keinen Grund.

Micha
 
Bei den zentralen Lösungen steckt auch zumeist ein Paketfilter dahinter.

Das ist so nicht ganz richtig, ich nutze z.B. das Astaro Security Gateway als Software Appliance auf eigener Hardware und das ist weitaus mehr als "nur" ein Paketfilter (IDS/IPS, Layer7-Firewall, Web App Firewall etc.)

Der Paketfilter ist ein Grundbaustein, da hast du Recht, aber solch eine Lösung ist eben ein Zusammenspiel verschiedener, komplexer Software-Teile.
Sowas selbst zu bauen, ginge wahrscheinlich auch, da auch bei Astaro viel Open Source Software eingesetzt wird, aber das würde ich mir nicht zutrauen.

Rootserver, ok, da weiß man nicht, was der Betreiber für den Schutz tut oder nicht, aber bei meinem privaten Root habe ich bisher auch nie einen Paketfilter genutzt und bin stets gut gefahren (wobei ich wahrscheinlich auch kein potenzielles Opfer für Attacken wäre :p).
Wenn man sich ein wenig Mühe bei der Config der Dienste gibt, die das Teil bereitstellen soll, reicht das völlig aus.

Gruß
barnim
 
Mit viel magischen Kenntnissen soll es - gerüchteweise - sogar möglich sein, Webserver auf anderen Ports als 80/443 lauschen zu lassen. ;)
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.

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.
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.

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.
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:

Code:
$IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT

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

In vielen Fällen gibt es dafür überhaupt keinen Grund.

In vielen Fällen rennen Linuxer auch allzu gern Dogmen hinterher, die besagen, dass es reicht nur die Services an's Netzwerk-Device zu binden, die nach aussen erreichbar sein sollen und den Rest auf's Loopback zu packen. Meiner Erfahrung hat mir aber gezeigt, dass dieses Dogma so unsinnig ist wie die Behauptung, dass eine monolithische Kernelstruktur noch immer zeitgemäss sei. ;)
 
Es ist ein Beispiel. Ich habe gerade nicht alle ICMP-Type-Codes im Kopf und keine Lust für eine so unsinnige Diskussion auch noch Manpages zu wälzen.

Allgemein droppe ich aber nicht erlaubte Verbindungen/Pakete , da im Fall eines DDoS-Angriffs, ICMP-Floods u.ä. der ausgehende Traffic recht teuer werden kann und total unnötig ist.
 
IPTables als "Mittel zum Zweck"

Um unerwünschte Besucher elegant zu blocken.
Akt. Beispiel:
http://www.hackerboard.de/virenschu...ftware/43954-ubuntu-rechner-vnc-gehacked.html

Hatte genau den gleichen Angriff abzuwehren. Mit Hilfe von IPTables und blockhosts ist der gleiche Angreifer bei mir aber nicht so weit gekommen wie beim Opfer, welches diesen thread eröffnete.
Mein System ist übrigens ein echter root-server auf dem web, und da muß man sich schon etwas einfallen lassen. Insbesonders, weil es u.a. auch ein (fast) offener Proxy ist.
 
Ein Paketfilter ist kein Fallback für kaputte Software/Konfigurationen.

Deswegen wird dem Administrator ein gesundes Maß an Fachkenntnis anempfohlen :)

Die Gemeinde baut nicht jahrelang an Software wie OpenSSH (was, wie alle hier sicher wissen, ein Projekt der OpenBSD Entwickler ist), welches von allen freien Systemen verwendet wird, damit dann unkundige Möchtegernadmins VNC auf ihrem Webserver im Netz betreiben. Mag sein das OpenSSH für viele Freizeitadmins "Altbacken" ist, wo man doch auf dem Zielsystem andere Möglichkeiten hätte. Tatsache ist aber: Es ist das BESTE was wir haben.

Paketfilter sind zunächst dazu da Traffice zu reglementieren. Sicherheit in der einen oder anderen Sache, ist ein Effekt, der sich ergeben kann.

Wer bei Hostsystemen auf Paketfilter angewiesen ist, sollte ggf. die Wahl seiner eingesetzten Software überdenken.


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.

IDS/IPS ist bei Autos toll. Das kommt auch wunderbar bei BWLern mit IT Halbwissen an. Was IT angeht ist das einzige Ziel die sichere Basis (OS) und sichere Applikationen. Nahezu all diese Systeme sind Signaturbasierend und helfen nicht bei ausgeklüegelteren Angriffen. Hersteller zahlreicher IPS/IDS Appliances würden dem natürlich dringend widersprechen, aber letztendlich machen die Kohle mit unausgegorenen Konzepten, wenn es um Hostsysteme geht.
 
Zuletzt bearbeitet:
Zurück
Oben