Hallo, wie viele hier (???) verwende ich Linux auch um ins Internet einzuwaehlen. Nun hoert man ja von vielen boesen Jungs ;-) , die einen zugrunde richten wollen, indem Sie den Rechner 'hacken'. Also muss ein Firewall her. Problem dabei ist die dynamische IP-Adresse, die ich (wier so viele) bei jeder Einwahl zugewiesen bekomme. Was mich stoerte, war, dass das Ganze immer ip-up/-down ablaeuft. Nun habe ich eine ipchains Konfiguration gefunden, die nur einmal beim Rechnerstart ablaeuft und alles ist paletti. Es sollen keine Serverdienste im Internet bereitgestellt werden, was ja fuer viele reicht. Diese ipchains-Konfiguration moechte ich hier zur Diskussion stellen. ----- ipchains-rules Beginn --------- :input DENY :forward DENY :output ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i eth0 -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 -j ACCEPT ! -y -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 -j ACCEPT ----- ipchains-rules Ende --------- Das kann man per ipchains-restore < ipchains.rules aktivieren. Den Eintrag fuer eth0 hab ich nur, da noch ein internes Netz dranhaengt das alles darf. Nun, was sagt ihr dazu. Das muesste doch fuer die Mehrzahl der Benutzer reichen. Zumindest Saint (Testprogramm) hatte danach keine Chanche mehr. Ich bin kein Netzwerk-Profi, also ... Fuer Vorschlaege bin ich offen. So long Petric --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Wed, 29 Mar 2000, Petric Frank wrote:
Also muss ein Firewall her. Problem dabei ist die dynamische IP-Adresse, die ich (wier so viele) bei jeder Einwahl zugewiesen bekomme. Was mich stoerte, war, dass das Ganze immer ip-up/-down ablaeuft. Diese ipchains-Konfiguration moechte ich hier zur Diskussion stellen.
----- ipchains-rules Beginn --------- :input DENY
Faschist! ;-)
:forward DENY
Also keine weiteren Clients ..?
:output ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i eth0 -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y
Wird problematisch bei Namensauflösungen, oder? Weil da nämlich meistens die Antwortpakete per UDP verschickt werden ...
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Aaah! Das ist UDP, nehme ich an ..? Ungewöhnlich, aber ...
----- ipchains-rules Ende ---------
Das kann man per ipchains-restore < ipchains.rules aktivieren.
Den Eintrag fuer eth0 hab ich nur, da noch ein internes Netz dranhaengt das alles darf.
Alles außer surfen! Dazu fehlt nämlich die Masquerading-Regel ;-)
Nun, was sagt ihr dazu. Das muesste doch fuer die Mehrzahl der Benutzer reichen. Zumindest Saint (Testprogramm) hatte danach keine Chanche mehr.
Ah jo -- ich bin auch erstmal irritiert :-) Ich handhabe alles ein bißchen *g* restriktiver, aber nach ein paar Bierchen sind alle Firewalls schön! Du läßt alles per UDP zu. Mich macht so etwas nervös. Um zur dynamsichen IP zurückzukommen: Du brauchst IMHO echo "7" > /proc/sys/net/ipv4/ip_dynaddr Mit "2" statt "7" klappt es auch (habe ich so aus dem Howto übernommen). Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Carsten Meyer wrote on Tue, Mar 28, 2000 at 22:46 +0200:
:output ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i eth0 -j ACCEPT
-s 0/0 sollte auch gehen, find ich aber besser lesbar.
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Also, Du möchtest bei tcp (kannst Du nicht -p tcp hinschreiben, spart ein cat /etc/protocols :)), daß keine Verbindungen aufgebaut werden können? Alle anderen IP Protokolle wie z.B. udp (was machst Du da eigentlich noch alles?) dürfen durch... Ist das so gewollt?! Eigentlich kann man doch jetzt durch ippp0 keine Verbindungen aufbauen, oder sehe ich was nicht?
Aaah! Das ist UDP, nehme ich an ..? Ungewöhnlich, aber ...
Ja, und alle anderen IP Protokolle: ICMP, GGP und wer weiß was es da noch gibt... Ja, IPSec noch...
Alles außer surfen! Dazu fehlt nämlich die Masquerading-Regel ;-)
Ja, und erlaubter Verbindungsaufbau bei ippp0 (Sonst funktionieren ja keine Proxies)
Ah jo -- ich bin auch erstmal irritiert :-)
Ah jo -- dito :-)
Ich handhabe alles ein bißchen *g* restriktiver, aber nach ein paar Bierchen sind alle Firewalls schön!
:) Pah - cooler Spruch :)
Du läßt alles per UDP zu. Mich macht so etwas nervös.
Na ja, die TCP Regel gefällt mir persönlich auch nicht so :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Steffen, Steffen Dettmer schrieb:
* Carsten Meyer wrote on Tue, Mar 28, 2000 at 22:46 +0200:
:output ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i eth0 -j ACCEPT
-s 0/0 sollte auch gehen, find ich aber besser lesbar.
Das macht das ipchains-save Script so.
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Also, Du möchtest bei tcp (kannst Du nicht -p tcp hinschreiben,
.o.
spart ein cat /etc/protocols :)), daß keine Verbindungen aufgebaut werden können? Alle anderen IP Protokolle wie z.B. udp (was machst Du da eigentlich noch alles?) dürfen durch... Ist das so gewollt?! Eigentlich kann man doch jetzt durch ippp0 keine Verbindungen aufbauen, oder sehe ich was nicht?
Nuja, ippp laeuft auf dial-on-demand (defaultroute liegt drauf). Ausserdem laeuft ein Proxy (Squid) und ein forwarding DNS. Fuer Mails ist ein lokaler POP3-Server und fetchmail zustaendig.
Aaah! Das ist UDP, nehme ich an ..? Ungewöhnlich, aber ...
Ja, und alle anderen IP Protokolle: ICMP, GGP und wer weiß was es da noch gibt... Ja, IPSec noch...
Da bin ich ueberfragt - deswegen auch die Mail hier.
Alles außer surfen! Dazu fehlt nämlich die Masquerading-Regel ;-)
Ja, und erlaubter Verbindungsaufbau bei ippp0 (Sonst funktionieren ja keine Proxies)
Tut alles. Was meinst du wie ich hier surfe.
Ah jo -- ich bin auch erstmal irritiert :-)
Ah jo -- dito :-)
(big grins)
Ich handhabe alles ein bißchen *g* restriktiver, aber nach ein paar Bierchen sind alle Firewalls schön!
:) Pah - cooler Spruch :)
Du läßt alles per UDP zu. Mich macht so etwas nervös.
Na ja, die TCP Regel gefällt mir persönlich auch nicht so :)
Nun, es sind halt alle TCP's erlaubt, ausser denen, die eine Verbindung aufbauen wollen (SYN). Brauchts da noch weitere Regeln ?
oki,
Steffen
So long Petric --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Petric Frank wrote on Wed, Mar 29, 2000 at 20:40 +0100:
Steffen Dettmer schrieb:
-s 0/0 sollte auch gehen, find ich aber besser lesbar.
Das macht das ipchains-save Script so.
Wäre besser, hättest Du die Aufrufe gemailt, besser lesbar, aber geht auch so ;)
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Also, Du möchtest bei tcp (kannst Du nicht -p tcp hinschreiben, spart ein cat /etc/protocols :)), daß keine Verbindungen aufgebaut werden können?
Sorry, ist ja ne input rule, hatte ich übersehen. Bleibt aber dabei: wäre mir zu "offen", das Ding.
Nuja, ippp laeuft auf dial-on-demand (defaultroute liegt drauf). Ausserdem laeuft ein Proxy (Squid) und ein forwarding DNS. Fuer Mails ist ein lokaler POP3-Server und fetchmail zustaendig.
Nun, ich erlaube (i.d.R.) immer nur, was auch benötigt wird, d.h. TCP, UDP und ICMP, diese dann auch noch eingeschränkt. Es gibt u.B. Möglichkeiten, auch ohne SYN Bits einen Scan zu machen (gut, damit sollte man dann nix anfangen können, aber trozdem).
Ja, und alle anderen IP Protokolle: ICMP, GGP und wer weiß was es da noch gibt... Ja, IPSec noch...
Da bin ich ueberfragt - deswegen auch die Mail hier.
Wenn Du es nicht brauchst, verbiete es doch! Vielleicht läuft im hinteren Netz ja irgentwo ein Router, der GGP spricht oder so (na gut, bißchen konstruiert :)). Davon abgesehen, Masquerading alias Addresshiding ist schon schön sicher. Vielleicht gibt es jedoch auch irgentwo bugs. Vielleicht konfigurierst Du auch mal ne Firewall, die auf einem "normalen" Router läuft --> besser gleich richtig machen IMHO.
Ja, und erlaubter Verbindungsaufbau bei ippp0 (Sonst funktionieren ja keine Proxies)
Tut alles. Was meinst du wie ich hier surfe.
Yepp, sorry, hatte mich verguckt. Es darf über ippp0 keiner zu Dir verbinden, was ja Sinn macht (Nun gut, man kommt auch nicht per SSH Fernwartung drauf, kommt drauf an, was Du brauchst; aber bei dynamischen IPs eh nur eingeschränkt machbar).
Na ja, die TCP Regel gefällt mir persönlich auch nicht so :)
Nun, es sind halt alle TCP's erlaubt, ausser denen, die eine Verbindung aufbauen wollen (SYN).
Brauchts da noch weitere Regeln ?
"Brauchen"... man braucht überhaupt keine Firewall :) Und wenn Masquerading als Addresshiding verkauft wird, gilts auch als eine der sichersten Firewalls :) IMHO aber JA, denn ich würde nur erlauben, was unbegingt nötig ist. Das werden dann auch mal 100 Regeln oder so, aber auf 'ner Pentiummaschine kein Problem (besonders, wenn da ne dünne Leitung hinter ist). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Steffen,
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Also, Du möchtest bei tcp (kannst Du nicht -p tcp hinschreiben, spart ein cat /etc/protocols :)), daß keine Verbindungen aufgebaut werden können?
Sorry, ist ja ne input rule, hatte ich übersehen. Bleibt aber dabei: wäre mir zu "offen", das Ding.
Drum die Frage hier - was muesste man noch zumachen.
Nun, ich erlaube (i.d.R.) immer nur, was auch benötigt wird, d.h. TCP, UDP und ICMP, diese dann auch noch eingeschränkt. Es gibt u.B. Möglichkeiten, auch ohne SYN Bits einen Scan zu machen (gut, damit sollte man dann nix anfangen können, aber trozdem).
Ja, und alle anderen IP Protokolle: ICMP, GGP und wer weiß was es da noch gibt... Ja, IPSec noch...
Da bin ich ueberfragt - deswegen auch die Mail hier.
Wenn Du es nicht brauchst, verbiete es doch! Vielleicht läuft im
Wie macht man IPSec zu ?
Na ja, die TCP Regel gefällt mir persönlich auch nicht so :)
Nun, es sind halt alle TCP's erlaubt, ausser denen, die eine Verbindung aufbauen wollen (SYN).
Brauchts da noch weitere Regeln ?
"Brauchen"... man braucht überhaupt keine Firewall :) Und wenn
;-)
Masquerading als Addresshiding verkauft wird, gilts auch als eine der sichersten Firewalls :) IMHO aber JA, denn ich würde nur erlauben, was unbegingt nötig ist. Das werden dann auch mal 100 Regeln oder so, aber auf 'ner Pentiummaschine kein Problem (besonders, wenn da ne dünne Leitung hinter ist).
Meine Zielrichtung war ein Regelsatz fuer einen Internet-Benutzer und nicht fuer einen Provider (Services fuer Internet bereitstellen). Da muesste es doch reichen alle Arten von Verbindungsaufbauten aus dem Internet zu blockieren, oder ? Was fehlt dazu noch an Regeln ? Wohlgemerkt, als I-Net Benutzer will ich dann aber mit moeglichst wenigen Einschraenkungen herumschlagen muessen, aber meine System soll trotzden sicher sein.
oki,
Steffen
So long Petric --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Petric Frank wrote on Sat, Apr 01, 2000 at 22:51 +0100:
Wie macht man IPSec zu ?
Weiß nicht, hab nur TCP, UDP und ICMP Regeln, der Rest ist damit per default verboten.
Meine Zielrichtung war ein Regelsatz fuer einen Internet-Benutzer und nicht fuer einen Provider (Services fuer Internet bereitstellen). Da muesste es doch reichen alle Arten von Verbindungsaufbauten aus dem Internet zu blockieren, oder ? Was fehlt dazu noch an Regeln ? Wohlgemerkt, als I-Net Benutzer will ich dann aber mit moeglichst wenigen Einschraenkungen herumschlagen muessen, aber meine System soll trotzden sicher sein.
Genau, dann mach ne Masquerading Regel, tcp nur ausgehend aufbauend erlaubt, ICMP und UDP komplett erlaubt, output offen. UDP erlaubst Du "domain" und gut ist. ICMP eingehend akzeptierst Du nur, wenn nicht fragmentiert. Aber das ist schon fast paranoia :) Wenn Du nicht's fürs Internet bereitstellst, ist das mit der Firewall nicht so ein Problem. Außerdem kein "echtes" Routing, macht's auch einfacher. Was von Deinem Router intern nicht gebraucht wird, machst Du aus (sicher ist sicher. z.b. telnet abschalten). TCP Wrapper würde ich trozdem konfigurieren, falls die Firewall mal ne Macke hat. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Carsten, Carsten Meyer schrieb:
On Wed, 29 Mar 2000, Petric Frank wrote:
Also muss ein Firewall her. Problem dabei ist die dynamische IP-Adresse, die ich (wier so viele) bei jeder Einwahl zugewiesen bekomme. Was mich stoerte, war, dass das Ganze immer ip-up/-down ablaeuft. Diese ipchains-Konfiguration moechte ich hier zur Diskussion stellen.
----- ipchains-rules Beginn --------- :input DENY
Faschist! ;-)
;-)
:forward DENY
Also keine weiteren Clients ..?
Nur ueber einen Proxy (Squid).
:output ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i eth0 -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i lo -j ACCEPT -A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p 6 \ -j ACCEPT ! -y
Wird problematisch bei Namensauflösungen, oder? Weil da nämlich meistens die Antwortpakete per UDP verschickt werden ...
-A input -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -i ippp0 -p ! 6 \ -j ACCEPT
Aaah! Das ist UDP, nehme ich an ..? Ungewöhnlich, aber ...
Was ?
----- ipchains-rules Ende ---------
Das kann man per ipchains-restore < ipchains.rules aktivieren.
Den Eintrag fuer eth0 hab ich nur, da noch ein internes Netz dranhaengt das alles darf.
Alles außer surfen! Dazu fehlt nämlich die Masquerading-Regel ;-)
Proxy - s.o. Und Stichwort: Forwarding DNS.
Nun, was sagt ihr dazu. Das muesste doch fuer die Mehrzahl der Benutzer reichen. Zumindest Saint (Testprogramm) hatte danach keine Chanche mehr.
Ah jo -- ich bin auch erstmal irritiert :-)
Saint ist so ein Security-Testtool.
Ich handhabe alles ein bißchen *g* restriktiver, aber nach ein paar Bierchen sind alle Firewalls schön! Du läßt alles per UDP zu. Mich macht so etwas nervös.
Wenn du mir sagst wie man per UDP einbrechen kann ... (Deswegen sagte ich - bin kein Profi)
Um zur dynamsichen IP zurückzukommen: Du brauchst IMHO echo "7" > /proc/sys/net/ipv4/ip_dynaddr Mit "2" statt "7" klappt es auch (habe ich so aus dem Howto übernommen).
Bei SuSE gibts dazu einen Eintrag in der /etc/rc.config: IP_DYNP="yes"
Carsten
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Petric Frank wrote on Wed, Mar 29, 2000 at 20:31 +0100:
Nun, was sagt ihr dazu. Das muesste doch fuer die Mehrzahl der Benutzer reichen. Zumindest Saint (Testprogramm) hatte danach keine Chanche mehr.
Ah jo -- ich bin auch erstmal irritiert :-)
Saint ist so ein Security-Testtool.
Glaube, das bezog sich nicht auf Saint :) Wird das eigentlich noch entwickelt? Dachte, die machen nur noch Nessus?
Wenn du mir sagst wie man per UDP einbrechen kann ... (Deswegen sagte ich - bin kein Profi)
Tja, irgenteine Sicherheitslücke... Oder Du hast NFS laufen (NFS v2 verwendet UDP). Oder bind crasht vielleicht immernoch bei ganz bestimmten Packet. Kann immer was sein. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo Steffen,
Wenn du mir sagst wie man per UDP einbrechen kann ... (Deswegen sagte ich - bin kein Profi)
Tja, irgenteine Sicherheitslücke... Oder Du hast NFS laufen (NFS v2 verwendet UDP). Oder bind crasht vielleicht immernoch bei ganz bestimmten Packet. Kann immer was sein.
Hier laeft kein nfs. Aber ein guter Hinweis. UDP fuer den NFS-Port sperren. Gibts irgendwo Hinweise zum Bind-Bug. Die Leute sind ja inzwischen bei bind v9.0.0 angelangt. Den (ab v8) kann man so trimmen, dass er nur auf interne Requests reagiert (wenn ich mich da nicht verlesen habe).
oki,
Steffen
So long Petric --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Petric Frank wrote on Sat, Apr 01, 2000 at 22:56 +0100:
Hallo Steffen,
Tja, irgenteine Sicherheitslücke... Oder Du hast NFS laufen (NFS v2 verwendet UDP). Oder bind crasht vielleicht immernoch bei ganz bestimmten Packet. Kann immer was sein.
Hier laeft kein nfs. Aber ein guter Hinweis. UDP fuer den NFS-Port sperren.
NFS hat im extremfall immer einen anderen Port (man portmap), also nicht so einfach so sperren. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (3)
-
cmeyer＠mail.com -
pfrank＠gmx.de -
steffen＠dett.de