Hi,
ich mach mal wieder vollkommen schamlos Werbung für mich selbst! ;-)
Da die Frage nach Firewall ab und zu kommt habe ich mein Wissen mal in HTML gegossen: http://silmor.de/58
Für IPv6-Surfer: http://six.silmor.de/58
Bitte mailt mir wenn irgendwas unklar oder falsch ist.
Konrad
Hi,
onrad Rosenbaum konrad@silmor.de (So 10 Mai 2009 19:14:12 CEST):
Hi,
ich mach mal wieder vollkommen schamlos Werbung für mich selbst! ;-)
Da die Frage nach Firewall ab und zu kommt habe ich mein Wissen mal in HTML gegossen: http://silmor.de/58
*filter :INPUT DROP :FORWARD DROP :OUTPUT DROP :ineth -
#filter input -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -j ineth
#allow output to known devices -A OUTPUT -o lo -j ACCEPT -A OUTPUT -o eth0 -j ACCEPT
#ethernet input -A ineth -p icmp -j ACCEPT * -A ineth -p udp -m udp --sport 53 -j ACCEPT -A ineth -p tcp -m tcp --syn -j DROP -A ineth -p tcp -m tcp --dport 1024: -j ACCEPT -A ineth -j DROP
COMMIT
*) Was soll das? Alles UDP, was von Port 53 kommt, ist gut? Ich halte das für gewagt. Von ``-m state --state ESTABLISHED,RELATED'' hälst Du nix? Ist zwar auch nicht perfekt, aber wahrscheinlich besser als das o.a., oder bin ich blind?
Hi,
On Mon, May 11, 2009 11:53, Heiko Schlittermann wrote:
- -A ineth -p udp -m udp --sport 53 -j ACCEPT -A ineth -p tcp -m tcp --syn -j DROP -A ineth -p tcp -m tcp --dport 1024: -j ACCEPT
*) Was soll das?
Das soll zumindest besser sein als gar keine Firewall - was leider sehr haeufig anzutreffen ist. Ich behaupte nicht alle Details ueber netfilter zu wissen.
Alles UDP, was von Port 53 kommt, ist gut?
Nein, nur 95% sind gut. Der Rest wird vom Resolver gefilter oder kaeme auch durch eine Stateful-FW durch.
Ich halte das für gewagt.
Ich auch.
Von ``-m state --state ESTABLISHED,RELATED'' hälst Du nix?
Ich wuerde nicht sagen "nix", aber in diesem speziellen Fall: "relativ wenig".
Auf der anderen Seite schadet es nicht. Ich werde es heute abend mal mit in die Anleitung einbauen.
Wenn wir schon dabei sind und aus lauter Neugier: warum stossen Dir die beiden Zeilen danach (s.o.) nicht auf? ;-)
Die sind die stateless-Fassung von -A ineth -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
Ist zwar auch nicht perfekt, aber wahrscheinlich besser als das o.a., oder bin ich blind?
Nein, Du bist nicht blind. Wenn Dir nochwas auffaellt lass' es mich wissen!
Konrad
Konrad Rosenbaum konrad@silmor.de (Mo 11 Mai 2009 13:43:46 CEST):
On Mon, May 11, 2009 11:53, Heiko Schlittermann wrote:
- -A ineth -p udp -m udp --sport 53 -j ACCEPT -A ineth -p tcp -m tcp --syn -j DROP -A ineth -p tcp -m tcp --dport 1024: -j ACCEPT
*) Was soll das?
Das soll zumindest besser sein als gar keine Firewall - was leider sehr haeufig anzutreffen ist. Ich behaupte nicht alle Details ueber netfilter zu wissen.
Alles UDP, was von Port 53 kommt, ist gut?
Nein, nur 95% sind gut. Der Rest wird vom Resolver gefilter oder kaeme auch durch eine Stateful-FW durch.
Nun, wer sagt, daß es zum Resolver geht, und nicht z.B. zum Portmapper oder woanders hin? Nur, weil es *von* Port 53/UDP kommt, muß es noch keine Antwort auf Anfragen Deines Resolvers sein, oder?
Die stateful FW (soweit 'state' bei UDP Sinn hat) hilft hier insofern, als daß sie auch noch Zielport auf der eigenen Maschine mit in die Betrachtung einbezieht (es muß halt die Antwort kommen zum Quellport des ausgehenden Paketes, und das innerhalb eines bestimmten Zeitfensters).
Von ``-m state --state ESTABLISHED,RELATED'' hälst Du nix?
Ich wuerde nicht sagen "nix", aber in diesem speziellen Fall: "relativ wenig".
Auf der anderen Seite schadet es nicht. Ich werde es heute abend mal mit in die Anleitung einbauen.
Wenn wir schon dabei sind und aus lauter Neugier: warum stossen Dir die beiden Zeilen danach (s.o.) nicht auf? ;-)
Doch, die waren mir auch aufgefallen, und bei zweimal hinsehen, habe ich dann gesehen, daß es 'poor man's state' sein könnte... Du könntest sicher auch das finale ACCEPT weglassen, wenn Du die SYN blockst, sollte niemand mehr Verbindungen aufbauen können.
Die sind die stateless-Fassung von -A ineth -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
Ja.
On Mon, May 11, 2009 14:05, Heiko Schlittermann wrote:
Konrad Rosenbaum konrad@silmor.de (Mo 11 Mai 2009 13:43:46 CEST):
Alles UDP, was von Port 53 kommt, ist gut?
Nein, nur 95% sind gut. Der Rest wird vom Resolver gefilter oder kaeme auch durch eine Stateful-FW durch.
Nun, wer sagt, daà es zum Resolver geht, und nicht z.B. zum Portmapper oder woanders hin? Nur, weil es *von* Port 53/UDP kommt, muà es noch keine Antwort auf Anfragen Deines Resolvers sein, oder?
Stimmt. Haette ich dran denken koennen - Asche auf mein Haupt!
Die stateful FW (soweit 'state' bei UDP Sinn hat) hilft hier insofern, als daà sie auch noch Zielport auf der eigenen Maschine mit in die Betrachtung einbezieht (es muà halt die Antwort kommen zum Quellport des ausgehenden Paketes, und das innerhalb eines bestimmten Zeitfensters).
Urspruenglich hatte ich das mal so geregelt, dass ich nach den Ports meines eigenen Servers gefiltert hatte. Seit Bekanntwerden des Kaminsky-Bugs geht das aber nicht mehr, weil die Query-Ports randomisiert werden.
Was sind eigentlich die Timeouts fuer stateful filtering?
Ich suche noch nach einer gezielten Moeglichkeit auf meinen bind einzuschraenken: --uid-owner geht leider nur in OUTPUT.
Wo wir gerade dabei sind: kennt sich jemand mit DNSSEC aus und hat Lust mal einen Vortrag zu machen?
Wenn wir schon dabei sind und aus lauter Neugier: warum stossen Dir die beiden Zeilen danach (s.o.) nicht auf? ;-)
Doch, die waren mir auch aufgefallen, und bei zweimal hinsehen, habe ich dann gesehen, daà es 'poor man's state' sein könnte... Du könntest sicher auch das finale ACCEPT weglassen, wenn Du die SYN blockst, sollte niemand mehr Verbindungen aufbauen können.
Das ACCEPT fuer TCP ist noetig, sonst funktionieren von innen etablierte Verbindungen nicht. Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler.
Konrad
Das ACCEPT fuer TCP ist noetig, sonst funktionieren von innen etablierte Verbindungen nicht. Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler.
hast du jetzt die ironietags vergessen
<halb ernst> <ironie> Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler. </ironie>
weil wenn eine Regel mir erlaubt reinzugehen auch wenn sie "falsch" ist macht ein drop es nicht wieder gut
weil wie entscheidet ein "-A ineth -j DROP" über Konfigurationsfehler?
</halb ernst>
habe nur mal kurz gelesen was mich persönlich etwas stört ist das man auf den Gedanken kommt UDP --> TCP setzen 'nur' auf IP auf
andreas
Konrad
On Monday 11 May 2009, Grimnin Fridyson wrote:
Das ACCEPT fuer TCP ist noetig, sonst funktionieren von innen etablierte Verbindungen nicht. Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler.
hast du jetzt die ironietags vergessen
Nein.
weil wenn eine Regel mir erlaubt reinzugehen auch wenn sie "falsch" ist macht ein drop es nicht wieder gut
weil wie entscheidet ein "-A ineth -j DROP" über Konfigurationsfehler?
Es ist die Art der Konfigurationsfehler gemeint, bei der eine Regel *hinter* der Chain Blödsinn macht. Kleines Beispiel mit korrigierter Reihenfolge:
:INPUT DROP :ineth - :ineth2 -
-A INPUT -i eth0 -j ineth -A ineth -p icmp -j ACCEPT -A ineth -p udp -m udp --dport 123 -j ACCEPT -A INPUT -i eth1 -j ineth2 -A INPUT -i eth2 -j ineth2 -A ineth2 -j ACCEPT
Nehmen wir mal an eth0 ist aussen, eth1 und eth2 sind intern.
Sollte ich jetzt aus irgendeiner Dussligkeit heraus -i eth1 und -i eth2 als -i eth+ zusammenfassen dann habe ich den Salat, weil alles akzeptiert wird statt wie erwartet auf eth0 nur ICMP und NTP zu erlauben.
Daher ein Paranoia-DROP am Ende jeder Device-Chain. Hat auch den netten Nebeneffekt dass es Protokolle abfängt von denen ich noch nix weiß (GRE, IP-in-IP, IP/Sec, SCTP, etc.pp.).
habe nur mal kurz gelesen was mich persönlich etwas stört ist das man auf den Gedanken kommt UDP --> TCP setzen 'nur' auf IP auf
Ich hatte keine Lust alle Einzelheiten von TCP/IP zu erklären. Daher auch die Links auf Wikipedia.
Ja, TCP und UDP können auch auf IPv6 laufen und sie benutzen das Schwesterprotokoll ICMP für bestimmte Fehler und IPv4 benutzt auch noch ARP auf Link-Ebene (IPv6 benutzt da bestimmte neue ICMP-Messages).
Es ist nicht sonderlich sinnvoll ICMP oder ARP in einer Firewall zu behandeln (die Mode ICMP-Ping zu filtern ist vorbei).
Wo genau liegt Dein Problem? Was genau kann ich noch klarer schreiben? Muss ich wirklich TCP/IP Grundlagen komplett erklären?
Konrad
:INPUT DROP :ineth - :ineth2 -
-A INPUT -i eth0 -j ineth -A ineth -p icmp -j ACCEPT -A ineth -p udp -m udp --dport 123 -j ACCEPT -A INPUT -i eth1 -j ineth2 -A INPUT -i eth2 -j ineth2 -A ineth2 -j ACCEPT
Nehmen wir mal an eth0 ist aussen, eth1 und eth2 sind intern.
Sollte ich jetzt aus irgendeiner Dussligkeit heraus -i eth1 und -i eth2 als -i eth+ zusammenfassen dann habe ich den Salat, weil alles akzeptiert wird statt wie erwartet auf eth0 nur ICMP und NTP zu erlauben.
Daher ein Paranoia-DROP am Ende jeder Device-Chain. Hat auch den netten Nebeneffekt dass es Protokolle abfängt von denen ich noch nix weiß (GRE, IP-in-IP, IP/Sec, SCTP, etc.pp.).
ist schon klar, und auch alles verständlich,
doch gibt es beispiele wo es dir nix hilft
deshalb war die aussage von mir auch halb ernst gemeint es gibt beispiele wie dein erwehntes wo es hilfreich ist aber es schütz nicht gegen alle fehler die man so machen kann (leider das währe auch zu schön, aber dann währe man als firewall admin wohl auch arbeitslos), und wenn man wirklich paranoid ist schlisst man den rechner nicht ans netz :-)
habe nur mal kurz gelesen was mich persönlich etwas stört ist das man auf den Gedanken kommt UDP --> TCP setzen 'nur' auf IP auf
Ich hatte keine Lust alle Einzelheiten von TCP/IP zu erklären. Daher auch die Links auf Wikipedia.
tcp/atm gibt es auch was ich sagen wollte es muss nicht immer ip sein
nicht mehr nicht weniger,
man könnte meinen es gäbe nur tcp/ip
tcp kann man auch durch udp ersetzen
Ja, TCP und UDP können auch auf IPv6 laufen und sie benutzen das Schwesterprotokoll ICMP für bestimmte Fehler und IPv4 benutzt auch noch ARP auf Link-Ebene (IPv6 benutzt da bestimmte neue ICMP-Messages).
Es ist nicht sonderlich sinnvoll ICMP oder ARP in einer Firewall zu behandeln (die Mode ICMP-Ping zu filtern ist vorbei).
Wo genau liegt Dein Problem?
kein problem nur ein hinweis
Was genau kann ich noch klarer schreiben?
siehe oben, muss man aber nicht
Muss ich wirklich TCP/IP Grundlagen komplett erklären?
ne (dann macht man noch gern den 'fehler' und vermicht das tcp/ip model mit dem osi 7 sichten model (tcp/ip kennt 4 sichten))
andreas
Konrad
On Monday 11 May 2009, Grimnin Fridyson wrote:
Daher ein Paranoia-DROP am Ende jeder Device-Chain. Hat auch den netten Nebeneffekt dass es Protokolle abfängt von denen ich noch nix weiß (GRE, IP-in-IP, IP/Sec, SCTP, etc.pp.).
ist schon klar, und auch alles verständlich,
doch gibt es beispiele wo es dir nix hilft
*ARP *Protokolle, die nix mit IPv4/6 zu tun haben (IPX, Appletalk, etc.pp.) *RAW-Sockets
Alles nix worüber ich Schlaf verliere.
deshalb war die aussage von mir auch halb ernst gemeint es gibt beispiele wie dein erwehntes wo es hilfreich ist aber es schütz nicht gegen alle fehler die man so machen kann
Richtig, aber es schützt gegen einige der Gröberen.
(leider das währe auch zu schön, aber dann währe man als firewall admin wohl auch arbeitslos), und wenn man wirklich paranoid ist schlisst man den rechner nicht ans netz :-)
Korrekt ;-)
habe nur mal kurz gelesen was mich persönlich etwas stört ist das man auf den Gedanken kommt UDP --> TCP setzen 'nur' auf IP auf
Ich hatte keine Lust alle Einzelheiten von TCP/IP zu erklären. Daher auch die Links auf Wikipedia.
tcp/atm gibt es auch was ich sagen wollte es muss nicht immer ip sein
Ok, das habe ich mal versucht zu verifizieren: TCP over ATM ist nicht spezifiziert. Jedenfalls nicht in einem RFC. Wäre auch blödsinnig, weil die Hälfte jeder Zelle durch den TCP-Header belegt würde.
Der Modus ist üblicherweise TCP->IP->ATM oder TCP->IP->PPP/Ethernet->ATM.
nicht mehr nicht weniger,
man könnte meinen es gäbe nur tcp/ip
In meiner Welt: ja.
In der Welt der großen Glasfaserleitungsbesitzer gibt es auch noch POTS, ISDN und wesentlich mehr Link-Layer-Protokolle als ich gewillt bin zu lernen.
In der Welt der Liebhaber alter Hard-/Software gibt es auch noch Appletalk, IPX, DECNet und ein paar andere gnadenlos veraltete Protokolle, die kein modernes Netz spricht.
Meine Anleitung ist nicht für die Techniker der Telekom-Switches gedacht, sondern für normale Anwender/Admins eines Computers mit irgendeiner Form von IP-Connectivity. Ob IP über Ethernet, ATM, DSL, PPP oder Token Ring geht ist irrelevant.
Konrad
Konrad Rosenbaum konrad@silmor.de (Mo 11 Mai 2009 18:11:45 CEST):
On Monday 11 May 2009, Grimnin Fridyson wrote:
Das ACCEPT fuer TCP ist noetig, sonst funktionieren von innen etablierte Verbindungen nicht. Das finale DROP am Ende meiner Chains ist reine Paranoia - Absicherung gegen Konfigurationsfehler.
hast du jetzt die ironietags vergessen
Nein.
weil wenn eine Regel mir erlaubt reinzugehen auch wenn sie "falsch" ist macht ein drop es nicht wieder gut
weil wie entscheidet ein "-A ineth -j DROP" über Konfigurationsfehler?
Es ist die Art der Konfigurationsfehler gemeint, bei der eine Regel *hinter* der Chain Blödsinn macht. Kleines Beispiel mit korrigierter Reihenfolge:
:INPUT DROP :ineth - :ineth2 -
-A INPUT -i eth0 -j ineth -A ineth -p icmp -j ACCEPT
Ich würde vielleicht nicht jedes ICMP reinlassen, sondern nur, wenn es zu Dingen gehört, die ich verursacht habe (bzw. wenn es ECHO-Request ist) (`-m state --state ESTABLISHED,RELATED', wobei es hier vor allem auf das "RELATED" ankommt.)
-A ineth -p udp -m udp --dport 123 -j ACCEPT
Wozu das? Antworten auf NTP Queries? Hier wieder der Hinweis auf ``-m state''.
Es ist nicht sonderlich sinnvoll ICMP oder ARP in einer Firewall zu behandeln (die Mode ICMP-Ping zu filtern ist vorbei).
On Tue, May 12, 2009 09:08, Heiko Schlittermann wrote:
Konrad Rosenbaum konrad@silmor.de (Mo 11 Mai 2009 18:11:45 CEST):
On Monday 11 May 2009, Grimnin Fridyson wrote: Es ist die Art der Konfigurationsfehler gemeint, bei der eine Regel *hinter* der Chain Blödsinn macht. Kleines Beispiel mit korrigierter Reihenfolge:
:INPUT DROP :ineth - :ineth2 -
-A INPUT -i eth0 -j ineth -A ineth -p icmp -j ACCEPT
Ich würde vielleicht nicht jedes ICMP reinlassen, sondern nur, wenn es zu Dingen gehört, die ich verursacht habe (bzw. wenn es ECHO-Request ist) (`-m state --state ESTABLISHED,RELATED', wobei es hier vor allem auf das "RELATED" ankommt.)
Ich sehe nicht wirklich welche ICMPs gefaehrlich genug sein koennen, um komplexere Regeln zu schreiben. Insbesondere bei IPv6 wuerde das sehr schnell ausarten, da es einige sehr wichtige Requests gibt (RD/RA, ND/NA, Redirect). Die Regeln fuer ICMP-Processing sind inzwischen so, dass sich die Firewall eigentlich keine Muehe geben muss.
-A ineth -p udp -m udp --dport 123 -j ACCEPT
Wozu das? Antworten auf NTP Queries? Hier wieder der Hinweis auf ``-m state''.
Nein, in diesem Fall Zitat aus einer Maschine die NTP-Server ist.
Konrad
lug-dd@mailman.schlittermann.de
-
Grimnin Fridyson -
Heiko Schlittermann -
Konrad Rosenbaum