AW: [suse-isdn] Suse Firewall und Dial on demand
Dank Dir Norbert, die Idee mit den eigenen Regeln hatte ich auch schon, bleiben aber noch ein par probleme: 1 dynamische ip vom provider - deshalb der aufruf in ip-up damits die firewall mitbekommt wie mach ich das ? 2 wenn ich die firewall routen uns masq machen lasse wozu brauche ich dann noch einen proxy 3 und andersrum wenn ich einen proxy verwende (squid) muß die firewall dann routen, womit ich wieder bei 2 bin ( das könnten die unbekannten ports sein die geblockt werden ) 4 bequemlicherweise arbeite ich noch mit t-online 194.25.2.129 ist der dns00.btx.dtag.de 212.185.249.244 ist der www-proxy.ef1.srv.t-online.de kann sein das die parallel antworten da ja die *.btx.dtag.de umbenannt werden sollen
-----Ursprüngliche Nachricht----- Von: Dr Norbert Boese [mailto:Norbert.Boese@ptb.de] Gesendet: Donnerstag, 14. September 2000 11:55 An: SUSE-ISDN@suse.com Betreff: Re: [suse-isdn] Suse Firewall und Dial on demand
---------- Von: Dr Norbert Boese[SMTP:NORBERT.BOESE@PTB.DE] Gesendet: Donnerstag, 14. September 2000 11:54:39 An: SUSE-ISDN@suse.com Betreff: Re: [suse-isdn] Suse Firewall und Dial on demand Diese Nachricht wurde automatisch von einer Regel weitergeleitet.
Hallo,
mit meiner ersten linux installation habe ich so meine probleme das meiste konnte ich mit viel, viel howtos und readmes lösen aber seit einiger zeit plage ich mit der Firewall von Suse, sobald sie installiert ist werden die DNS-Antworten aus dem Internet geblockt, meiner meinung nach ist die konfiguration richtig ( Suse 6.4 mit firewall 2.1) kann mich einer in die richtige richtung schubsen ich stochere nur noch
ich bin kein Freund der vorgegebenen Konfiguration. Mein persoenlicher Ratschlag waere: bau Dir eine eigene Regeldatei, in der Du zu Anfang alle Regeln loeschst und die Default-Policy fuer die Chains input, forward und output auf DENY setzt. Dann schaust Du in Deine /var/log/firewall und gibst von den abgewiesenen Paketen genau die frei, die Du erlauben willst.
route.conf #192.168.1.0 internes netz #192.168.2.99 ippp0 #192.168.2.100 ppp partneradresse ippp0 # # Ziel |Dummy oder Gateway | Netzmaske |Device 192.168.1.0 0.0.0.0
255.255.255.0 eth0
192.168.2.100 0.0.0.0 255.255.255.255 ippp0 default 192.168.2.99
scheinen keine grundlegenen Fehler drin zu sein.
die konfigurationsanleitung aus der SUSE sdb stimmt leider nicht mit der SuSEfirewall-technical überein
sdb: für dialup verbindungen "/sbin/SuSEfirewall" in ip-up eintragen technical: "/sbin/init.d/rc2.d/S99firewall_setup" start in ip-up eintragen
wenn Du in rc2.d den Link S99firewall_setup stehen hast und die Variable START_FW auf yes gesetzt hast, dann wird das Startscript mit dem Parameter start bei jedem Wechsel in Runlevel 2 (Systemstart) in der Gruppe der letzten Scripte (alle mit 99) aufgerufen. Du brauchst also nichts mehr in ip-up aufrufen.
Sep 13 19:59:30 linux1 kernel: Packet log: input DENY ippp0 PROTO=6 62.224.38.48:3084 62.224.154.120:27374 L=48 S=0x00 I=62973 F=0x4000 T=116 SYN (#135)
ist ein Verbindungsaufbau (SYN gesetzt) auf mir unbekannten Ports mit TCP-Protokoll
Sep 13 19:59:38 linux1 kernel: Packet log: input DENY ippp0 PROTO=17 194.25.2.129:53 62.224.154.120:1027 L=136 S=0x00 I=55581 F=0x0000 T=57 (#135)
das ist z.B. ne DNS-Rueckmeldung. 194.25.2.129 will auf Port 53 mit Protokoll UDP den Rechner 62.224.154.120 auf Port 1027 erreichen. Wenn Du das erlauben willst, waere also folgender Eintrag sinnvoll:
ipchains -A input -p UDP -s 194.25.2.129 domain -d 62.224.154.120 -i ippp0 -l ACCEPT
Sep 13 19:59:58 linux1 kernel: Packet log: input DENY ippp0 PROTO=17 212.185.249.244:53 62.224.154.120:1027 L=145 S=0x00 I=55822 F=0x0000 T=59 (#135)
Sep 13 20:00:03 linux1 kernel: Packet log: input DENY ippp0 PROTO=17 194.25.2.129:53 62.224.154.120:1027 L=145 S=0x00 I=3149 F=0x0000 T=57 (#135)
Sep 13 20:00:08 linux1 kernel: Packet log: input DENY ippp0 PROTO=17 212.185.249.244:53 62.224.154.120:1027 L=145 S=0x00 I=58860 F=0x0000 T=59 (#135)
Sep 13 20:00:13 linux1 kernel: Packet log: input DENY ippp0 PROTO=17 194.25.2.129:53 62.224.154.120:1027 L=145 S=0x00 I=8189 F=0x0000 T=57 (#135)
dto. Nameserver-Antworten. Arbeitest Du mit zwei Nameservern (194.25.2.129 und 212.185.249.244) ? Dann musst Du natuerlich auch beide freigeben.
Ich hoffe, es hilft etwas
Gruss Norbert -- Nur fuer Segelbegeisterte: http://www.wscg.de/ Norbert Boese eMail: norbert.boese@ptb.de Phone +49-531-18533 Fax +49-531-592693231
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-isdn-unsubscribe@suse.com For additional commands, e-mail: suse-isdn-help@suse.com
Lüttich Holger schrieb:
die Idee mit den eigenen Regeln hatte ich auch schon, bleiben aber noch ein par probleme:
1 dynamische ip vom provider - deshalb der aufruf in ip-up damits die firewall mitbekommt wie mach ich das ? Wozu brauchen Deine Regeln die dynamische IP-Adresse? Ich habe auch eigene Regeln und die sehen so aus:
/sbin/ipchains -P input REJECT # alles sperren /sbin/ipchains -P output REJECT /sbin/ipchains -F input # Regeln löschen /sbin/ipchains -F output /sbin/ipchains -A input -i eth0 -j ACCEPT # Ethernet darf alles /sbin/ipchains -A output -i eth0 -j ACCEPT /sbin/ipchains -A input -i lo -j ACCEPT # Loopback darf alles /sbin/ipchains -A output -i lo -j ACCEPT /sbin/ipchains -A input -i dummy -j ACCEPT # Dummy darf alles /sbin/ipchains -A output -i dummy -j ACCEPT # ----------------------- ausgehende Verbindungen ------------------- # ssh ausgehend erlaubt /sbin/ipchains -A output -i ippp0 -p tcp --dport 22 -j ACCEPT /sbin/ipchains -A input -i ippp0 -p tcp --sport 22 -j ACCEPT # telnet ausgehend erlaubt /sbin/ipchains -A output -i ippp0 -p tcp --dport 23 -j ACCEPT /sbin/ipchains -A input -i ippp0 -p tcp --sport 23 -j ACCEPT # smtp ausgehend erlaubt /sbin/ipchains -A output -i ippp0 -p tcp --dport 25 -j ACCEPT /sbin/ipchains -A input -i ippp0 -p tcp --sport 25 -j ACCEPT ... ... # archie ausgehend erlaubt /sbin/ipchains -A output -i ippp0 -p tcp --dport 1525 -j ACCEPT /sbin/ipchains -A input -i ippp0 -p tcp --sport 1525 -j ACCEPT # ping ausgehend erlaubt /sbin/ipchains -A output -i ippp0 -p icmp \ --icmp-type echo-request -j ACCEPT /sbin/ipchains -A input -i ippp0 -p icmp \ --icmp-type echo-reply -j ACCEPT # ----------------------- eingehende Verbindungen ------------------- # ssh eingehend erlaubt /sbin/ipchains -A input -i ippp0 -p tcp --dport 22 -j ACCEPT /sbin/ipchains -A output -i ippp0 -p tcp --sport 22 -j ACCEPT ... ... # https eingehend erlaubt /sbin/ipchains -A input -i ippp0 -p tcp --dport 443 -j ACCEPT /sbin/ipchains -A output -i ippp0 -p tcp --sport 443 -j ACCEPT # ping eingehend erlaubt /sbin/ipchains -A input -i ippp0 -p icmp \ --icmp-type echo-request -j ACCEPT /sbin/ipchains -A output -i ippp0 -p icmp \ --icmp-type echo-reply -j ACCEPT Die Freischalt-Zeilen sind jeweils die erlaubte Richtung und die Antwort-Pakete dazu. Ausgehend braucht man wohl ftp (20,21), ssh (22), telnet (23), smtp(25), time (37), dns (UDP 53), http (80), pop (110), nntp (119) und https (443). Wer will, kann auch noch real-audio (554) und archie (1525) dazunehmen. Eingehend kann man sich auf ssh (22) beschränken, wenn man nicht noch ftp (20,21), http (80), pop (110), imap (143) und https (443) anbieten möchte. Forwarding-Regeln habe ich keine, da alles, was geforwarded wird, ja sowieso über Input und Output läuft bzw. gesperrt wird. Wenn ich noch Masquerading will, kommen noch folgende Zeilen hinzu: /sbin/ipchains -F forward /sbin/ipchains -A forward -i ippp0 -s 192.168.4.0/24 -j MASQ Fertig ist die Laube.
2 wenn ich die firewall routen uns masq machen lasse wozu brauche ich dann noch einen proxy Ein Proxy läßt sich meist differenzierter steuern als eine Firewall. Sieh Dir mal die Konfiguration von Squid an; da wird Dir schwindelig. Außerdem ist Squid z.B. ein caching Proxy; d.h. wenn Du 15 Leute hast, die sich alle die gleichen Seiten ansehen, wird jede Seite nur einmal über's Netz geholt.
3 und andersrum wenn ich einen proxy verwende (squid) muß die firewall dann routen, womit ich wieder bei 2 bin ( das könnten die unbekannten ports sein die geblockt werden ) Wenn Deine Clients nur Surfen wollen bzw. Du für alles, was Du von den Clients aus tun willst, einen Proxy aufsetzt, brauchst Du kein Masquerading. Allerdings weiß ich nicht, ob es z.B. einen Real-Audio-Proxy gibt.
Hallo Holger, ich hab' meinen Senf mal oben reingeschrieben. Auch mein Tip: Vergiß die SuSE-Skripte und nimm eigene. Da weißt Du wenigstens was passiert. mfg Volker -- Volker Böhm Tel.: 040/25 15 37-118 Alpha Leasing GmbH Fax: 040/25 15 37-190 Grevenweg 72 e-Mail: boehm@alpha-leasing.de 20537 Hamburg vboehm@t-online.de
participants (2)
-
Lüttich Holger
-
Volker Böhm