Firewallkonfiguration jetzt mit Configeinträgen
..siehe auch Configuration ! Liebe Liste, meine Anfrage gestern war wohl zu undifferenziert. Hier nochmal konkreter: Wie ist die Firewall zu konfigurieren, damit diese Pakete (S. Fehlerlog) nicht abgelehnt werden. Für jegliche Hinweise dankbar. LL Jul 24 21:30:08 linuxsrv pppd[4354]: Script /etc/ppp/ip-up started (pid 6329) Jul 24 21:30:08 linuxsrv ip-up: Modified /etc/resolv.conf for DNS at ppp0 Jul 24 21:30:08 linuxsrv SuSEfirewall: Firewall rules successfully set. Jul 24 21:30:08 linuxsrv pppd[4354]: Script /etc/ppp/ip-up finished (pid 6329), status = 0x0 Jul 24 21:30:16 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 194.25.2.129:53 217.230.90.52:1040 L=129 S=0x00 I=39341 F=0x0000 T=60 (#84) Jul 24 21:30:20 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 217.5.100.129:53 217.230.90.52:1040 L=129 S=0x00 I=57377 F=0x0000 T=55 (#84) Jul 24 21:30:22 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 217.5.100.129:53 217.230.90.52:1040 L=129 S=0x00 I=57867 F=0x0000 T=55 (#84) Jul 24 21:30:33 linuxsrv pppd[4354]: sent [LCP EchoReq id=0x1 magic=0x4caf14e4] Jul 24 21:30:33 linuxsrv pppd[4354]: rcvd [LCP EchoRep id=0x1 magic=0xfa19d73] Jul 24 21:30:36 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 217.5.100.129:53 217.230.90.52:1040 L=129 S=0x00 I=61577 F=0x0000 T=55 (#84) Jul 24 21:30:42 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 194.25.2.129:53 217.230.90.52:1040 L=129 S=0x00 I=13922 F=0x0000 T=60 (#84) Jul 24 21:30:46 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 217.5.100.129:53 217.230.90.52:1040 L=129 S=0x00 I=64717 F=0x0000 T=55 (#84) Jul 24 21:30:51 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 194.25.2.129:53 217.230.90.52:1040 L=129 S=0x00 I=29243 F=0x0000 T=60 (#84) Konfiguration: FW_DEV_EXT="eth1 ppp0 ippp0" FW_DEV_INT="eth0 ippp1" FW_DEV_DMZ="" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="192.168.100.0/24" FW_PROTECT_FROM_INTERNAL="yes" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="" # Common: smtp domain FW_SERVICES_EXT_UDP="domain" # Common: domain FW_SERVICES_DMZ_TCP="" # Common: smtp domain FW_SERVICES_DMZ_UDP="" # Common: domain syslog FW_SERVICES_INT_TCP="ssh smtp domain pop3 netbios-ssn 3128" FW_SERVICES_INT_UDP="domain syslog netbios-ns netbios-dgm 3128" FW_TRUSTED_NETS="" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" # Common: "ftp-data" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" # Common: "DNS" or "domain ntp" FW_SERVICE_DNS="yes" FW_SERVICE_DHCLIENT="no" # if you use dhclient to get an ip address FW_SERVICE_DHCPD="no" # set to "yes" if this server is a DHCP server FW_SERVICE_SAMBA="no" FW_FORWARD="yes" FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="no" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" FW_KERNEL_SECURITY="yes" FW_STOP_KEEP_ROUTING_STATE="no" FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" FW_ALLOW_PING_EXT="no" FW_ALLOW_FW_TRACEROUTE="yes" -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo Gerhard, FW_SERVICES_EXT_TCP="" # Common: smtp domain FW_SERVICES_EXT_UDP="domain" # Common: domain das kann nicht sein. TCP Port 53 wird für DNS ebenfalls benötigt. Gruß Sebastian
Hi,
Wie ist die Firewall zu konfigurieren, damit diese Pakete (S. Fehlerlog) nicht abgelehnt werden. Für jegliche Hinweise dankbar.
Jul 24 21:30:16 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17 194.25.2.129:53 217.230.90.52:1040 L=129 S=0x00 I=39341 F=0x0000 T=60 (#84)
host dns03.btx.dtag.de DNS von T-Online will was von deinem Highport 1040 über udp. Da du INCOMMING_HIGHPORTS auf yes hast wundert mich das eigentlich sehr.
Konfiguration:
FW_DEV_EXT="eth1 ppp0 ippp0"
Warum die Drei? Also ppp0 ippp0 kann ich mir ja noch denken wenn man Modem und ISDN am Rechner hat, was allerdings auch komisch währe aber eth1? Cable Modem auch noch?
FW_DEV_INT="eth0 ippp1"
ippp1 intern? Einwahlserver?
FW_SERVICES_EXT_UDP="domain" # Common: domain
domain nur auf udp? udp an sich ist schon ungewöhnlich da DNS ein tcp service ist. Außerdem gibst du damit den port 53 auf udp nach außen frei was auch relativ sinnfrei ist oder läuft bei dir nen DNS server der auf udp horcht?
FW_SERVICE_DNS="yes"
hm vieleicht. Ich würde erstmal die ganzen devices rausnehmen, das ding bei udp auf "" setzen, die firewall starten und mir ipchains -L anschaun. Henne p.s. Läuft bei dir ein lokaler Nameserver der vieleicht diese reaktionen von t-online hervoruft weil er query's schickt oder zonen anmelden will oder sowas? bind? -- Hendrik Vogelsang aka Henne mailto: mickey@naturalbornkiller.de Kiff! I have made it with a Women. Inform the men Futurama - Love´s labour lost in space # random sigs made with fortune
* Mittwoch, 25. Juli 2001 um 22:27 (+0200) schrieb Henne Vogelsang:
domain nur auf udp? udp an sich ist schon ungewöhnlich da DNS ein tcp service ist.
Nein, Name-Anfragen über UDP sind der Normalfall.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Wednesday 25 July 2001 23:46, Andreas Koenecke wrote:
* Mittwoch, 25. Juli 2001 um 22:27 (+0200) schrieb Henne Vogelsang:
domain nur auf udp? udp an sich ist schon ungewöhnlich da DNS ein tcp service ist.
Nein, Name-Anfragen über UDP sind der Normalfall.
Genau, DNS ist ein UDP-Dienst. Das einzige was dabei ueber TCP abgewickelt wird, sind die Zonentransfers zwischen den Master- und Slave-Servern des DNS, damit wird aber kaum einer was zu tun haben. Darum nur UDP. mfg, Gerd -- /"\ \ / ASCII Ribbon Campaign x Say NO to HTML in email and news !! / \
Hi, On Thu, 26 Jul 2001, Gerhard Feiner wrote:
On Wednesday 25 July 2001 23:46, Andreas Koenecke wrote:
* Mittwoch, 25. Juli 2001 um 22:27 (+0200) schrieb Henne Vogelsang:
domain nur auf udp? udp an sich ist schon ungewöhnlich da DNS ein tcp service ist.
Nein, Name-Anfragen über UDP sind der Normalfall.
Genau, DNS ist ein UDP-Dienst. Das einzige was dabei ueber TCP abgewickelt wird, sind die Zonentransfers zwischen den Master- und Slave-Servern des DNS, damit wird aber kaum einer was zu tun haben. Darum nur UDP.
Warum sollte man einen port öffnen in der Firewall für domain anfragen wenn nicht für die tcp dienste von z.b. bind? Ich glaube kaum das Mr. Lindenlaub einen Nameserver über ppp0(ð1 wahrscheinlich DSL) oder ippp0 für das gesamte internet betreibt und dabei SuSEfirewall verwendet. Und seine DNS anfragen haben eh das korekte bit um einfach so durch zu gehen da bedarf es keines offenen udp ports auf der Firewall. Henne der immer noch an ein verkonfigurierten lokalen namerserver glaubt und sich mal wieder mißverständlich ausgedrückt hat ;) -- Hendrik Vogelsang aka Henne mailto: mickey@naturalbornkiller.de Professor: "Good news, everyone. Several years ago I tried to log onto AOL, and it just went through. Whee! We're online." # random sigs made with fortune
Am Thu, 26 Jul 2001 schrieb Henne Vogelsang:
Hi,
On Thu, 26 Jul 2001, Gerhard Feiner wrote:
Genau, DNS ist ein UDP-Dienst. Das einzige was dabei ueber TCP abgewickelt wird, sind die Zonentransfers zwischen den Master- und Slave-Servern des DNS, damit wird aber kaum einer was zu tun haben. Darum nur UDP.
Das ist soweit schonmal falsch. Ich empfehle zum Nachlesen das IpChains-HowTo.
Warum sollte man einen port öffnen in der Firewall für domain anfragen wenn nicht für die tcp dienste von z.b. bind?
Ich glaube kaum das Mr. Lindenlaub einen Nameserver über ppp0(ð1 wahrscheinlich DSL) oder ippp0 für das gesamte internet betreibt und dabei SuSEfirewall verwendet. Und seine DNS anfragen haben eh das korekte bit um einfach so durch zu gehen da bedarf es keines offenen udp ports auf der Firewall.
doch doch, dessen bedarf es unter Umständen schon. Zur Erklärung: BIND verwendet sowohl TCP als auch UDP zum Übertragen von Requests _und_ Antworten. Im Prinzip wird ab einer bestimmten Antwortgröße auf UDP umgeschaltet, weil dieses Protokoll in dem Fall wohl effizienter sein soll als TCP. Zumindest wenn man einen Caching DNS auf dem Rechner hat unterhält der sich mit seinem Forwarder sowohl über TCP als auch über UDP, und interessanterweise kommt zumindest mit ipchains auch ab und an ein SYN-Paket vom Forwarder zurück an den TCP-Port. Deshalb sollte man TCP und UDP Port 53 von und zu den in der named.conf eingetragenen Forwardern öffnen. Aber besser nirgendwoanders hin. Und latürnich sollte der lokale DNS dann auf forward-only stehen. Sonst kann es passieren, daß sporadisch DNS-Requests schiefgehen - gibt dann lustige Effekte. Übrigens hab ich auch schon gesehen, daß der nscd einem da in die Suppe spuckt. -- Erhard Schwenk http://www.fto.de http://www.akkordeonjugend.de
* Donnerstag, 26. Juli 2001 um 11:24 (+0200) schrieb Erhard Schwenk:
Zur Erkl?rung: BIND verwendet sowohl TCP als auch UDP zum ?bertragen von Requests _und_ Antworten. Im Prinzip wird ab einer bestimmten Antwortgr??e auf UDP umgeschaltet, weil dieses Protokoll in dem Fall wohl effizienter sein soll als TCP.
Umgekehrt: NS-Abfragen werden normalerweise über UDP durchgeführt. Nur wenn die Antworten grösser als 512 Byte sind, wird TCP benutzt (Oder eben bei Zone-Transfers).
und interessanterweise kommt zumindest mit ipchains auch ab und an ein SYN-Paket vom Forwarder zur?ck an den TCP-Port.
Vielleicht will der Forwarder einen Zone-Transfer initiieren? Wenn man keinen "offiziellen" NS unterhält, sollte der lokale Port 53 für Pakete, die von "außen" kommen, völlig geblockt werden.
Deshalb sollte man TCP und UDP Port 53 von und zu den in der named.conf eingetragenen Forwardern ?ffnen. [ ... ] Sonst kann es passieren, da? sporadisch DNS-Requests schiefgehen - gibt dann lustige Effekte.
ACK.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Thursday 26 July 2001 13:20, Andreas Koenecke wrote:
* Donnerstag, 26. Juli 2001 um 11:24 (+0200) schrieb Erhard Schwenk:
Zur Erkl?rung: BIND verwendet sowohl TCP als auch UDP zum ?bertragen von Requests _und_ Antworten. Im Prinzip wird ab einer bestimmten Antwortgr??e auf UDP umgeschaltet, weil dieses Protokoll in dem Fall wohl effizienter sein soll als TCP.
So stimmt es. Nur eins noch: Wieso sollte eine DNS-Anfrage groesser als 512byte werden? Da muss dann schon einer am Paket gefummelt haben. In der Praxis reicht es voellig aus, UDP zuzulassen.
Umgekehrt: NS-Abfragen werden normalerweise über UDP durchgeführt. Nur wenn die Antworten grösser als 512 Byte sind, wird TCP benutzt (Oder eben bei Zone-Transfers).
und interessanterweise kommt zumindest mit ipchains auch ab und an ein SYN-Paket vom Forwarder zur?ck an den TCP-Port.
Vielleicht will der Forwarder einen Zone-Transfer initiieren? Wenn man keinen "offiziellen" NS unterhält, sollte der lokale Port 53 für Pakete, die von "außen" kommen, völlig geblockt werden.
Deshalb sollte man TCP und UDP Port 53 von und zu den in der named.conf eingetragenen Forwardern ?ffnen. [ ... ] Sonst kann es passieren, da? sporadisch DNS-Requests schiefgehen - gibt dann lustige Effekte.
ACK.
Gruß
Andreas
-- /"\ \ / ASCII Ribbon Campaign x Say NO to HTML in email and news !! / \
* Donnerstag, 26. Juli 2001 um 11:14 (+0200) schrieb Henne Vogelsang:
Und seine DNS anfragen haben eh das korekte bit um einfach so durch zu gehen da bedarf es keines offenen udp ports auf der Firewall.
Ja, seine Anfragen gehen auch raus, doch die Antworten des Nameservers
werden von seinem Paketfilter geblockt. Ein Auszug aus dem Log:
Jul 24 21:30:16 linuxsrv kernel: Packet log: input DENY ppp0 PROTO=17
194.25.2.129:53 217.230.90.52:1040 L=129 S=0x00 I=39341 F=0x0000 T=60
(#84)
D.h., die Antwort des T-Online Nameservers (BTW die 194.25.2.129
sollte man nur im Notfall benutzen) über UDP wird geblockt --> keine
Namensauflösung!
Abhilfe wäre, wie ja auch schon in der Liste gepostet,:
ipchains -A input -p UDP -i ppp0 -s 194.25.2.129 53 --dport 1024: -j ACCEPT
Welche Variable in der SuSEFirewall eine solche Regel erzeugt, kann
ich allerdings auch nicht sagen.
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
On Thursday 26 July 2001 11:14, Henne Vogelsang wrote:
Hi,
On Thu, 26 Jul 2001, Gerhard Feiner wrote:
On Wednesday 25 July 2001 23:46, Andreas Koenecke wrote:
* Mittwoch, 25. Juli 2001 um 22:27 (+0200) schrieb Henne Vogelsang:
domain nur auf udp? udp an sich ist schon ungewöhnlich da DNS ein tcp service ist.
Nein, Name-Anfragen über UDP sind der Normalfall.
Genau, DNS ist ein UDP-Dienst. Das einzige was dabei ueber TCP abgewickelt wird, sind die Zonentransfers zwischen den Master- und Slave-Servern des DNS, damit wird aber kaum einer was zu tun haben. Darum nur UDP.
Warum sollte man einen port öffnen in der Firewall für domain anfragen wenn nicht für die tcp dienste von z.b. bind?
Ich glaube kaum das Mr. Lindenlaub einen Nameserver über ppp0(ð1 wahrscheinlich DSL) oder ippp0 für das gesamte internet betreibt und dabei SuSEfirewall verwendet. Und seine DNS anfragen haben eh das korekte bit um einfach so durch zu gehen da bedarf es keines offenen udp ports auf der Firewall.
Wenn du mir jetzt noch erklaerst, was das fuer ein Bit sein soll? Erstens: kennt UDP keinen Header im Sinne von TCP, und zweitens entscheidet alleine der Nameserver/Client ob die Anfrage/Antwort richtig ist. Eine Firewall kann nicht in das Paket schauen. Das ist Sache eines Application-Level-Proxies ... mfg, Gerd -- /"\ \ / ASCII Ribbon Campaign x Say NO to HTML in email and news !! / \
participants (6)
-
Andreas Koenecke -
Erhard Schwenk -
Gerhard Feiner -
Gerhard Lindenlaub -
Henne Vogelsang -
Sebastian Wolfgarten