Hackerboard Wiki HaboBlog
Hackerboard bei Facebook Hackerboard bei Google+ Hackerboard bei Twitter

[HaBo]

 
Linux/UNIX Linuxverfechter finden hier Weggefährten.

Firewall ?

Diskussion: Firewall ? im Forum Linux/UNIX, in der Kategorie Operating Systems; Anzeige Hat man auf Linux (Ubuntu) auch eine Firewall ? so wie bei z.b.. Vista und falls nein brauche ich ...

Like Tree5Likes

Antwort
Alt 23.04.11, 03:26   #1 (permalink)
Banned
 
Registriert seit: 02.04.11
p3i)20 Leistung: Abacus
Likes: 0
Standard Firewall ?

Anzeige

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

Gruss Pedro

p3i)20 ist offline   Mit Zitat antworten
Alt 23.04.11, 05:25   #2 (permalink)
 
Benutzerbild von whoopy84
 
Registriert seit: 01.06.09
whoopy84 Leistung: Z3
Likes: 7
Standard

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

whoopy84 ist offline   Mit Zitat antworten
   
HaBOT
 
- Anzeige -

Werbung ist gerade online    
Alt 23.04.11, 09:53   #3 (permalink)
Senior Member
 
Registriert seit: 26.03.06
Serow Leistung: 8086
Likes: 16
Standard

Hi,

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

ciao
serow
Tarantoga and bitmuncher like this.
Serow ist offline   Mit Zitat antworten
Alt 24.04.11, 00:57   #4 (permalink)
Moderator
 
Benutzerbild von Tarantoga
 
Registriert seit: 11.02.06
Tarantoga QuadcoreTarantoga QuadcoreTarantoga QuadcoreTarantoga QuadcoreTarantoga QuadcoreTarantoga Quadcore
Likes: 229
Standard

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...
p3i)20 likes this.
Tarantoga ist gerade online   Mit Zitat antworten
Alt 03.06.11, 14:38   #5 (permalink)
 
Registriert seit: 03.06.11
barnim Leistung: Facit NTK
Likes: 0
Standard

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.
barnim ist offline   Mit Zitat antworten
Alt 03.06.11, 15:34   #6 (permalink)
Moderator
 
Benutzerbild von bitmuncher
 
Registriert seit: 30.09.06
bitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcore
Likes: 442
Standard

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
Tarantoga likes this.
__________________
Mein Blog - Mein Job - Diaspora

Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund.

Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+
bitmuncher ist gerade online   Mit Zitat antworten
Alt 03.06.11, 17:50   #7 (permalink)
 
Registriert seit: 12.08.10
mime Leistung: Pentium Imime Leistung: Pentium I
Likes: 30
Standard

Zitat:
Zitat von bitmuncher Beitrag anzeigen
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
__________________
http://www.openvas.org
mime ist offline   Mit Zitat antworten
Alt 03.06.11, 17:56   #8 (permalink)
Moderator
 
Benutzerbild von bitmuncher
 
Registriert seit: 30.09.06
bitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcore
Likes: 442
Standard

Zitat:
Zitat von mime Beitrag anzeigen
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.
__________________
Mein Blog - Mein Job - Diaspora

Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund.

Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+
bitmuncher ist gerade online   Mit Zitat antworten
Alt 03.06.11, 18:29   #9 (permalink)
 
Registriert seit: 12.08.10
mime Leistung: Pentium Imime Leistung: Pentium I
Likes: 30
Standard

Zitat:
Zitat von bitmuncher Beitrag anzeigen
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?

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

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

Zitat:
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
Chromatin likes this.
__________________
http://www.openvas.org

Geändert von mime (03.06.11 um 18:42 Uhr)
mime ist offline   Mit Zitat antworten
Alt 03.06.11, 19:23   #10 (permalink)
Moderator
 
Benutzerbild von bitmuncher
 
Registriert seit: 30.09.06
bitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcore
Likes: 442
Standard

Zitat:
Zitat von mime Beitrag anzeigen
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.

Zitat:
Zitat von mime Beitrag anzeigen
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.

Zitat:
Zitat von mime Beitrag anzeigen
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.

Zitat:
Zitat von mime Beitrag anzeigen
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.
__________________
Mein Blog - Mein Job - Diaspora

Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund.

Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+
bitmuncher ist gerade online   Mit Zitat antworten
Alt 04.06.11, 10:35   #11 (permalink)
 
Registriert seit: 12.08.10
mime Leistung: Pentium Imime Leistung: Pentium I
Likes: 30
Standard

Zitat:
Zitat von bitmuncher Beitrag anzeigen
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
__________________
http://www.openvas.org
mime ist offline   Mit Zitat antworten
Alt 04.06.11, 10:37   #12 (permalink)
 
Registriert seit: 03.06.11
barnim Leistung: Facit NTK
Likes: 0
Standard

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
barnim ist offline   Mit Zitat antworten
Alt 04.06.11, 11:59   #13 (permalink)
Moderator
 
Benutzerbild von bitmuncher
 
Registriert seit: 30.09.06
bitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcorebitmuncher Quadcore
Likes: 442
Standard

Zitat:
Zitat von mime Beitrag anzeigen
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.

Zitat:
Zitat von barnim
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.
__________________
Mein Blog - Mein Job - Diaspora

Der Ring uns zu knechten besteht aus 12 Sternen auf blauem Grund.

Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+
bitmuncher ist gerade online   Mit Zitat antworten
Alt 04.06.11, 12:28   #14 (permalink)
 
Registriert seit: 12.08.10
mime Leistung: Pentium Imime Leistung: Pentium I
Likes: 30
Standard

Zitat:
Zitat von bitmuncher Beitrag anzeigen
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.

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

Zitat:
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
__________________
http://www.openvas.org
mime ist offline   Mit Zitat antworten
Alt 04.06.11, 13:00   #15 (permalink)
 
Registriert seit: 03.06.11
barnim Leistung: Facit NTK
Likes: 0
Standard

Zitat:
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 ).
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
barnim ist offline   Mit Zitat antworten
Antwort
   
- Anzeige -

Werbung ist gerade online    

[HaBo] » Operating Systems » Linux/UNIX » Firewall ?
Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks sind aus
Pingbacks sind aus
Refbacks sind aus



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61