Firewall für Linux
Hi zusammen,
ich habe seit kurzen einen Suse Server. Hatte bis dahin noch nie was mit Linux zu tun. Kann mir jemand eine Firewall für Linux empfehlen??? Ich konfiguriere alles über ssh.
Danke für eure Tipps
ich habe seit kurzen einen Suse Server. Hatte bis dahin noch nie was mit Linux zu tun. Kann mir jemand eine Firewall für Linux empfehlen??? Ich konfiguriere alles über ssh.
Danke für eure Tipps
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 24285
Url: https://administrator.de/forum/firewall-fuer-linux-24285.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
21 Kommentare
Neuester Kommentar
ein gibt nur einer unter Linux und das ist iptables. Das gehört zu jeder Linux Ausgabe. Nur die Konfiguration ist überall anders. Da must denn mal in der Suse Doku lesen. Da ich nur Fedora und Redhat nutze, kann ich dir nicht sagen, wo du bei Suse das machen musst. An der Konsole kannste mit iptables direkt Regeln aufstellen. Nur wie die den gespeichert werden das ist überall anders.
hi,
kommt wirkloch drauf an, wozu du diese Firewall brauchst. Suse hat eine eigne Firewall. Die Susefirewall2. Die würd ich dir nicht wirklich für den Einsatz im Server empfehlen, nur da du schriebst, du hättest vorher noch nie was mit Linux zu tun, dann denk ich mal, dass es sich auch nicht um einen Produktiv Server handelt. Ansonst hat Linux im Kern eine eigne Firewall. Anzusprechen ist diese mittels iptables. Die Befehle dafür stehen im Netz. Alle hab ich auch nicht im Kopf, aber einfach googlen.
kommt wirkloch drauf an, wozu du diese Firewall brauchst. Suse hat eine eigne Firewall. Die Susefirewall2. Die würd ich dir nicht wirklich für den Einsatz im Server empfehlen, nur da du schriebst, du hättest vorher noch nie was mit Linux zu tun, dann denk ich mal, dass es sich auch nicht um einen Produktiv Server handelt. Ansonst hat Linux im Kern eine eigne Firewall. Anzusprechen ist diese mittels iptables. Die Befehle dafür stehen im Netz. Alle hab ich auch nicht im Kopf, aber einfach googlen.
Schau dir mal "firehol" an, das setzt auf iptables auf. Ist viel einfacher und benutzerfreundlicher zu konfigurieren als "iptables", trotzdem absolut sicher. Auf http://firehol.sourceforge.net/ findest du auch einige Bsp.-Konfigurationen.
Gruss
Gruss
iptables kann ich dir eigentlich schon empfehlen.
ist auch in deutsch gut dokumentier (falls du des englisch - wie ich ^^ - nicht allzu mächtig
sein solltest). ein tip zur konfiguration:
schreibe alle regeln in eine datei und mache diese nur für root ausführbar (chmod 700).
dann das ganze im runlevel verlinken (sollte unter suse mit yast zu machen sein).
mehr macht die suse-firewall auch nicht. nur macht diese das ser undurchsichtig.
ein sehrshersehr gutes deutsches howto findest du hier:
http://iptables.org/documentation/index.html#documentation-howto
gruss, pseudo
-bei fragen - fragen-
ist auch in deutsch gut dokumentier (falls du des englisch - wie ich ^^ - nicht allzu mächtig
sein solltest). ein tip zur konfiguration:
schreibe alle regeln in eine datei und mache diese nur für root ausführbar (chmod 700).
dann das ganze im runlevel verlinken (sollte unter suse mit yast zu machen sein).
mehr macht die suse-firewall auch nicht. nur macht diese das ser undurchsichtig.
ein sehrshersehr gutes deutsches howto findest du hier:
http://iptables.org/documentation/index.html#documentation-howto
gruss, pseudo
-bei fragen - fragen-
welche z.B.?
dienste, die nur intern erreichbar sein sollen, bindet man bei der config auch so an!
und was nicht erreichbar ist, kann auch nicht "gehackt" werden.
von daher ist es - meiner meinung nach - bei nem web-server in der regel vollkommen überflüssig.
was anderes ist es, wenn ich z.B. merke, dass mich ne bestimmt ip gezielt versucht mit z.B. irgendwelchen floodings zu attackieren, aber den traffic hab ich so oder so - da hilft also auch keine firewall...
ich brauche diese lediglich z.B. bei einem gateway etc. aber bei nem webserver...?
wenn du deinen so konfigurierst, dass du dienste für extern über ne firewall dicht machen musst, finde ich, haste unsauber gearbeitet :o)
comments dazu sind aber herzlich willkommen, kann ja auch sein, dass ich mit meiner ansicht völlig falsch liege...
gruss, pseudo
dienste, die nur intern erreichbar sein sollen, bindet man bei der config auch so an!
und was nicht erreichbar ist, kann auch nicht "gehackt" werden.
von daher ist es - meiner meinung nach - bei nem web-server in der regel vollkommen überflüssig.
was anderes ist es, wenn ich z.B. merke, dass mich ne bestimmt ip gezielt versucht mit z.B. irgendwelchen floodings zu attackieren, aber den traffic hab ich so oder so - da hilft also auch keine firewall...
ich brauche diese lediglich z.B. bei einem gateway etc. aber bei nem webserver...?
wenn du deinen so konfigurierst, dass du dienste für extern über ne firewall dicht machen musst, finde ich, haste unsauber gearbeitet :o)
comments dazu sind aber herzlich willkommen, kann ja auch sein, dass ich mit meiner ansicht völlig falsch liege...
gruss, pseudo
Hi,
ich schließe mich mal dieser interessanten Diskussion an die hier entstanden ist
Also:
@artus_excalibur
Ich würde auf jeden Fall eine Firewall nutzen und evtl. noch ein IDS(Intrusion Detection System) da für empfehle ich Snort, sowie Virenscanner da könnte man Antivir oder Sophos nutzen oder clamav und natürlich auch etwas was rootkids entdeckt(chkrootkit).
Dann als Firewall-Lösung würde ich iptables verwenden aber mich nicht allein darauf verlassen da dieser nur ein Paketfilter ist, d.h. er arbeitet in den unteren Schichten des OSI-Referenzmodells, im speziellen auf Schicht zwei(Sicherrungsschicht) und drei (Vermittlungsschicht).
Deshalb sollte man noch ein paar Kernel-Funktionen aktivieren und die oben genannten Dienste hinzuziehen.
Bei weiteren Fragen zu iptables einfach sagen ich hätte da auch schon ein paar Scripte mit denen ich das löse.
@xypseudo
Ich halten deine Philisophie für sehr wagemutig, aber jedem das seine oder?
Außerdem kannst du mit iptables den gesammten Asia IP-Block blocken, da in
Japan etc die meisten DDoS Bot Netzwerke liegen. Weiterhin ist es möglich auch einige DDOs Attacken mit Kernel funktionen die Wirkung zu nehmen (ping flood).
Zusätzlich kann man mittles Port-Knocking nur bestimmten Personen erlauben eine Verbindung aufzubauen(z.B. bei ssh sinnvoll).
Außerdem wenn sich mal Trojaner eingenisstet haben kann eine Firewall verhindern das diese eine Verbindung zum Angreifer aufbauen können oder dieser zum Trojaner.
mfg duddits
ich schließe mich mal dieser interessanten Diskussion an die hier entstanden ist
Also:
@artus_excalibur
Ich würde auf jeden Fall eine Firewall nutzen und evtl. noch ein IDS(Intrusion Detection System) da für empfehle ich Snort, sowie Virenscanner da könnte man Antivir oder Sophos nutzen oder clamav und natürlich auch etwas was rootkids entdeckt(chkrootkit).
Dann als Firewall-Lösung würde ich iptables verwenden aber mich nicht allein darauf verlassen da dieser nur ein Paketfilter ist, d.h. er arbeitet in den unteren Schichten des OSI-Referenzmodells, im speziellen auf Schicht zwei(Sicherrungsschicht) und drei (Vermittlungsschicht).
Deshalb sollte man noch ein paar Kernel-Funktionen aktivieren und die oben genannten Dienste hinzuziehen.
Bei weiteren Fragen zu iptables einfach sagen ich hätte da auch schon ein paar Scripte mit denen ich das löse.
@xypseudo
Ich halten deine Philisophie für sehr wagemutig, aber jedem das seine oder?
Außerdem kannst du mit iptables den gesammten Asia IP-Block blocken, da in
Japan etc die meisten DDoS Bot Netzwerke liegen. Weiterhin ist es möglich auch einige DDOs Attacken mit Kernel funktionen die Wirkung zu nehmen (ping flood).
Zusätzlich kann man mittles Port-Knocking nur bestimmten Personen erlauben eine Verbindung aufzubauen(z.B. bei ssh sinnvoll).
Außerdem wenn sich mal Trojaner eingenisstet haben kann eine Firewall verhindern das diese eine Verbindung zum Angreifer aufbauen können oder dieser zum Trojaner.
mfg duddits
@duddits
Ein DDos kannste ja schonmal garnich blocken, da es sich dabei ggf. um zig verschiedenen IP's handelt... Wie willst du herrausfinden, ob die IP ne "normale" Anfrage auf Port 80 stellt, oder einfach nur deinen Port 80 "flutet"(TCP-Flood)? Da bei einem DDoS ja meistens komprommiteirte Kisten von nem Bot-Net gesteuert werden, ist es ausserdem eher unwahrscheinlich, dass das viele/nur IP's aus Asien sind... Auch ein DoS Kannst du evtl. blocken, aber wenn er genuch "wumms" hat, ist deine Kiste nur noch mit filtern beschäftigt - Sprich du hast vielleicht deine Kiste vorm Netzwerkkollaps geschützt, aber die Leitung ist trotzdem dicht. Und bei 100Mbit Anbindung - da geht was :o).
Ich habe damit öfters zu tun, deswegen bin ich mir da auch relativ sicher, dass es so ist ;o) Betreue auf meiner Arbeit einige Server und wenn da einer ge(D)DoSt wird, haste eigentlich nur die Möglichkeit, dein Netz mittels blackholen(nullrouten) der ge(D)DoSten IP zu schützen.
Dann ist die Kiste aber nimmer erreichbar...
Lege dazu SSH auf nen anderen Port, chroote SSH und lass auf localhost (auch auf nem anderen Port) nen 2. SSH-Daemon laufen, der nur auf loopback lauscht(lo-Interface). Bei beiden musste natürlich den root-login abschalten. Somit ist ein rootlogin nur möglich, indem du dich als user über einen bestimmten port auf der kiste von extern einloggst und dann mit einem ssh user@127.0.0.1 -p*irgendwas* auf deinen ssh ohne chroot connectest und dann mittels su...
Aber nun mal ernsthaft: Wie willste das denn bitte bei nem "Public"-Server realisieren? Ne Kiste, auf der du hostest? Soll ich es dir verraten: Garnicht. Da kannste nur zunageln und hoffen, dass deine Kunden gute PW's haben. Also: Installiere ich die cracklib und entziehe den Usern jegliche Rechte. Was anderes kannste da nunma einfach nich machen. Denn dann können Script-Kiddies nur dem einen User schaden, aber nicht deinem Server. Versuch es dochmal, logge dich als "Kunde" auf deiner Kiste ein und probier mal aus, was du alles machen kannst. Meistens ist es viel zu viel.
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptbales -F
sich den weg freischiessen. sind 3 Zeilen Programmcode mehr. Also kein wirklicher Schutz finde ich. Aber wenn du dadurch (durch den Gedanken) besser schläfst...
Wie war das? Jedem das seine ;o)
@BartSimpson
Sprich, was blockst du genau? *neugierigsei*
netten gruss und gespannt auf weitere comments,
pseudo
Ich halten deine Philisophie für sehr wagemutig, aber jedem das seine oder?
Außerdem kannst du mit iptables den gesammten Asia IP-Block blocken, da in
Japan etc die meisten DDoS Bot Netzwerke liegen. Weiterhin ist es möglich auch einige DDOs
Attacken mit Kernel funktionen die Wirkung zu nehmen (ping flood).
Sicher, nur was hab ich davon, ein (D)DoS an meiner Firewall zu blocken?Außerdem kannst du mit iptables den gesammten Asia IP-Block blocken, da in
Japan etc die meisten DDoS Bot Netzwerke liegen. Weiterhin ist es möglich auch einige DDOs
Attacken mit Kernel funktionen die Wirkung zu nehmen (ping flood).
Ein DDos kannste ja schonmal garnich blocken, da es sich dabei ggf. um zig verschiedenen IP's handelt... Wie willst du herrausfinden, ob die IP ne "normale" Anfrage auf Port 80 stellt, oder einfach nur deinen Port 80 "flutet"(TCP-Flood)? Da bei einem DDoS ja meistens komprommiteirte Kisten von nem Bot-Net gesteuert werden, ist es ausserdem eher unwahrscheinlich, dass das viele/nur IP's aus Asien sind... Auch ein DoS Kannst du evtl. blocken, aber wenn er genuch "wumms" hat, ist deine Kiste nur noch mit filtern beschäftigt - Sprich du hast vielleicht deine Kiste vorm Netzwerkkollaps geschützt, aber die Leitung ist trotzdem dicht. Und bei 100Mbit Anbindung - da geht was :o).
Ich habe damit öfters zu tun, deswegen bin ich mir da auch relativ sicher, dass es so ist ;o) Betreue auf meiner Arbeit einige Server und wenn da einer ge(D)DoSt wird, haste eigentlich nur die Möglichkeit, dein Netz mittels blackholen(nullrouten) der ge(D)DoSten IP zu schützen.
Dann ist die Kiste aber nimmer erreichbar...
Zusätzlich kann man mittles Port-Knocking nur bestimmten Personen erlauben eine
Verbindung aufzubauen(z.B. bei ssh sinnvoll).
Port-Knocking, klar. Bei deinem eigenen privaten Server sicher, den kannste vernageln bis zum umfallen...Verbindung aufzubauen(z.B. bei ssh sinnvoll).
Lege dazu SSH auf nen anderen Port, chroote SSH und lass auf localhost (auch auf nem anderen Port) nen 2. SSH-Daemon laufen, der nur auf loopback lauscht(lo-Interface). Bei beiden musste natürlich den root-login abschalten. Somit ist ein rootlogin nur möglich, indem du dich als user über einen bestimmten port auf der kiste von extern einloggst und dann mit einem ssh user@127.0.0.1 -p*irgendwas* auf deinen ssh ohne chroot connectest und dann mittels su...
Aber nun mal ernsthaft: Wie willste das denn bitte bei nem "Public"-Server realisieren? Ne Kiste, auf der du hostest? Soll ich es dir verraten: Garnicht. Da kannste nur zunageln und hoffen, dass deine Kunden gute PW's haben. Also: Installiere ich die cracklib und entziehe den Usern jegliche Rechte. Was anderes kannste da nunma einfach nich machen. Denn dann können Script-Kiddies nur dem einen User schaden, aber nicht deinem Server. Versuch es dochmal, logge dich als "Kunde" auf deiner Kiste ein und probier mal aus, was du alles machen kannst. Meistens ist es viel zu viel.
Außerdem wenn sich mal Trojaner eingenisstet haben kann eine Firewall verhindern das
diese eine Verbindung zum Angreifer aufbauen können oder dieser zum Trojaner.
Wenn es mal dazu kommt, dann iss es eh zu spät, denn wenn irgend n tool sich rootrechte ergaunern kann, dann kann der Angreifer auch mittelsdiese eine Verbindung zum Angreifer aufbauen können oder dieser zum Trojaner.
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptbales -F
sich den weg freischiessen. sind 3 Zeilen Programmcode mehr. Also kein wirklicher Schutz finde ich. Aber wenn du dadurch (durch den Gedanken) besser schläfst...
Wie war das? Jedem das seine ;o)
@BartSimpson
Eine firewall kann verhindern, das ungültige IP Pakete an deine Programme geschcikt >werden, was diese denn aus dem Tritt nringhen könnte.
Ich muss zugeben, dass das einer der wenigen Gründe wäre, eine Überlegung zu starten um eine Firewall aufzusetzen. Wie hast du das Realisiert?Sprich, was blockst du genau? *neugierigsei*
netten gruss und gespannt auf weitere comments,
pseudo
nette Diskussion ums Thema Firewall. Ich selber halte auch nicht soo viel von Zunageln, und vor allem nicht bei public Servern. Aber ich hab die trotzdem laufen. Man merkt bei der Performance nahezu überhaupt nichts, und fühlt sich irgendwie sicherer. Hast du deinen Server mal testweise einem Portscan unterzogen? Als ich den laufen hatte, bin ich erschrocken, und hab die Firewall gemacht. Ich dachte auch immer, dass da ja nur ports auf sind, wo auch entsprechende Programme laufen, aber da lag ich falsch. Es war nach Installation fast alles auf, und man konte sich nahezu überall hin Hacken. Naja, jetzt sind nach Außen nur noch die Ports auf, die von außen erreichbar sind. Aber nach Intern hab ich auch keinen Schutz laufen.
joa, hab ich.
und es ist auch nur das auf, was auf sein soll.
habe nen debian-server, hier mal das listing, was da so bei mir rauskommt:
tweety:~# nmap localhost
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-27 17:13 CET
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
587/tcp open submission
953/tcp open rndc
3306/tcp open mysql
Nmap finished: 1 IP address (1 host up) scanned in 0.258 seconds
tweety:~#
tweety:~# nmap *externe_ip*
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-27 17:13 CET
Interesting ports on dnsprofiler.de (*externe_ip*):
(The 1658 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
587/tcp open submission
Nmap finished: 1 IP address (1 host up) scanned in 0.240 seconds
tweety:~#
also eigentlich iss nix auf, was nich auf sein sollte
gruss, pseudo
und es ist auch nur das auf, was auf sein soll.
habe nen debian-server, hier mal das listing, was da so bei mir rauskommt:
tweety:~# nmap localhost
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-27 17:13 CET
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1656 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
587/tcp open submission
953/tcp open rndc
3306/tcp open mysql
Nmap finished: 1 IP address (1 host up) scanned in 0.258 seconds
tweety:~#
tweety:~# nmap *externe_ip*
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-01-27 17:13 CET
Interesting ports on dnsprofiler.de (*externe_ip*):
(The 1658 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
587/tcp open submission
Nmap finished: 1 IP address (1 host up) scanned in 0.240 seconds
tweety:~#
also eigentlich iss nix auf, was nich auf sein sollte
gruss, pseudo
ja habe ich. der ist für ca. 10 domains zuständig und wenn ich es ma endlich mache macht er auch mein eigenes dyndns. hatte leider nur noch keine zeit um mir n script zu basteln, aber schwer isses ja nich wirklich...
btw; 53 ist auch noch für udp auf, wegen dns-updates. zudem auch noch dhcp-client und ntp, damit die kiste auch weiss, was die stunde schlägt :o)
habe doch nich n port auf, von dem ich nicht weiss, was er macht *zwinker*
aber mal zurück zum eigentlichen und ich will es nicht besser wissen, aber wofür sollte ich nun eine firewall nutzen? als webserver, der public ist, sehe ich jedenfalls keinen sinn darin. jedenfalls kann ich so ziemlich alles was angeführt wurde als guten grund ausschliessen...
gruss, pseudo
btw; 53 ist auch noch für udp auf, wegen dns-updates. zudem auch noch dhcp-client und ntp, damit die kiste auch weiss, was die stunde schlägt :o)
habe doch nich n port auf, von dem ich nicht weiss, was er macht *zwinker*
aber mal zurück zum eigentlichen und ich will es nicht besser wissen, aber wofür sollte ich nun eine firewall nutzen? als webserver, der public ist, sehe ich jedenfalls keinen sinn darin. jedenfalls kann ich so ziemlich alles was angeführt wurde als guten grund ausschliessen...
gruss, pseudo
mal noch ne anmerkung, wo ich sinn darin sehe...
bei einem gateway. da ist es mehr als sinnvoll, da ich dort das "einganstor" zu meinem
intranet habe. das ist natürlich dichter als dicht genagelt. darauf betreibe ich nen selbst programmiertes webinterface, mittels dem man user im prepaid-verfahren traffic buchen kann den sie dann versurfen können. ist der traffic "leer" sperrt iptables den account.
das webinterface schreibt die änderungen in die db und ein (mehr oder weniger) kleines script arbeitet die db ab und setzt die regeln dann um. alle 5 minuten. so habe ich also maximal einen verlust von 5 min * maximale bandbreite sozusagen. aber das ist nochmal ne ganz andere geschichte. was ich mir evtl. noch vorstellen könnte, wäre ein IDS im lokalen netz, auf einem webserver hingegen bringt das nicht so arg viel, wenn der "standalone" ist. denn das erste was ich machen würde als "pöhser hacker" wäre doch das suchen nach solchen tools. und wenn schon? ich droppe erstmal alle eingeloggten user, ändere das root-pw und sauge mir was ich brauche, fahre die kiste dann in nen sand und anschliessend mach ich noch z.B: ein "dd if=/dev/zero of=/dev/hda &" und geh dann in die heia schlafen. also wie gesagt, in nem netz finde ich das sinnvoll, aber auf nem webserver... *schulterzuck*
gruss, pseudo
bei einem gateway. da ist es mehr als sinnvoll, da ich dort das "einganstor" zu meinem
intranet habe. das ist natürlich dichter als dicht genagelt. darauf betreibe ich nen selbst programmiertes webinterface, mittels dem man user im prepaid-verfahren traffic buchen kann den sie dann versurfen können. ist der traffic "leer" sperrt iptables den account.
das webinterface schreibt die änderungen in die db und ein (mehr oder weniger) kleines script arbeitet die db ab und setzt die regeln dann um. alle 5 minuten. so habe ich also maximal einen verlust von 5 min * maximale bandbreite sozusagen. aber das ist nochmal ne ganz andere geschichte. was ich mir evtl. noch vorstellen könnte, wäre ein IDS im lokalen netz, auf einem webserver hingegen bringt das nicht so arg viel, wenn der "standalone" ist. denn das erste was ich machen würde als "pöhser hacker" wäre doch das suchen nach solchen tools. und wenn schon? ich droppe erstmal alle eingeloggten user, ändere das root-pw und sauge mir was ich brauche, fahre die kiste dann in nen sand und anschliessend mach ich noch z.B: ein "dd if=/dev/zero of=/dev/hda &" und geh dann in die heia schlafen. also wie gesagt, in nem netz finde ich das sinnvoll, aber auf nem webserver... *schulterzuck*
gruss, pseudo