* nat and dns @ 2004-09-23 9:00 Raphael Jacquot 2004-09-23 10:34 ` Nick Drage 2004-09-23 14:17 ` Aleksandar Milivojevic 0 siblings, 2 replies; 21+ messages in thread From: Raphael Jacquot @ 2004-09-23 9:00 UTC (permalink / raw) To: netfilter hi, I have a setup that looks like : _____ ____ [ ] 192.168.0.100 [ ] [ DNS ]------------------------------[ FW ]---- [_____] 192.168.0.254 [____] (isp) and I want the DNS to answer to queries from the outside what's the proper way of doing this ? Sincerely Raphael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 9:00 nat and dns Raphael Jacquot @ 2004-09-23 10:34 ` Nick Drage 2004-09-23 11:09 ` Samuel Díaz García 2004-09-23 12:00 ` Raphael Jacquot 2004-09-23 14:17 ` Aleksandar Milivojevic 1 sibling, 2 replies; 21+ messages in thread From: Nick Drage @ 2004-09-23 10:34 UTC (permalink / raw) To: netfilter On Thu, Sep 23, 2004 at 11:00:33AM +0200, Raphael Jacquot wrote: > hi, > I have a setup that looks like : > _____ ____ > [ ] 192.168.0.100 [ ] > [ DNS ]------------------------------[ FW ]---- > [_____] 192.168.0.254 [____] (isp) > > and I want the DNS to answer to queries from the outside > what's the proper way of doing this ? I'm presuming that you want to answer queries from everywhere, rather than just from specific hosts, in which case: iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p udp --dport 53 -j DNAT --to-destination 192.168.0.100 iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p tcp --dport 53 -j DNAT --to-destination 192.168.0.100 iptables -A FORWARD --destination 192.168.0.100 -p udp --dport 53 -j ACCEPT iptables -A FORWARD --destination 192.168.0.100 -p tcp --dport 53 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT I'd be interested to hear how you get on by the way, I'm not quite sure that my iptables rulebases are keeping state on DNS requests correctly. -- mors omnia vincit ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 10:34 ` Nick Drage @ 2004-09-23 11:09 ` Samuel Díaz García 2004-09-23 11:23 ` Nick Drage ` (2 more replies) 2004-09-23 12:00 ` Raphael Jacquot 1 sibling, 3 replies; 21+ messages in thread From: Samuel Díaz García @ 2004-09-23 11:09 UTC (permalink / raw) To: Netfilter Mailing List For DNS query only UDP is necesary, not TCP. Regards, Nick Drage writes: > On Thu, Sep 23, 2004 at 11:00:33AM +0200, Raphael Jacquot wrote: >> hi, >> I have a setup that looks like : >> _____ ____ >> [ ] 192.168.0.100 [ ] >> [ DNS ]------------------------------[ FW ]---- >> [_____] 192.168.0.254 [____] (isp) >> >> and I want the DNS to answer to queries from the outside >> what's the proper way of doing this ? > > I'm presuming that you want to answer queries from everywhere, rather > than just from specific hosts, in which case: > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p udp --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p tcp --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -A FORWARD --destination 192.168.0.100 -p udp --dport 53 -j > ACCEPT > > iptables -A FORWARD --destination 192.168.0.100 -p tcp --dport 53 -j > ACCEPT > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > I'd be interested to hear how you get on by the way, I'm not quite sure > that my iptables rulebases are keeping state on DNS requests correctly. > > -- > mors omnia vincit > Samuel Díaz García Director Gerente ArcosCom Wireless, S.L.L. mailto:samueldg@arcoscom.com http://www.arcoscom.com móvil: 651 93 72 48 tlfn/fax: 956 70 13 15 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 11:09 ` Samuel Díaz García @ 2004-09-23 11:23 ` Nick Drage 2004-09-23 13:01 ` Samuel Díaz García ` (2 more replies) 2004-09-23 13:17 ` Alexis 2004-09-23 14:09 ` Aleksandar Milivojevic 2 siblings, 3 replies; 21+ messages in thread From: Nick Drage @ 2004-09-23 11:23 UTC (permalink / raw) To: netfilter On Thu, Sep 23, 2004 at 01:09:43PM +0200, Samuel Díaz García wrote: > For DNS query only UDP is necesary, not TCP. Heh, that's such a common misconception that I almost mentioned it in my original email. Most DNS queries take place over UDP, however if the reply to the query is especially large then a new TCP connection is opened between the client and server. Also zone transfers take place over TCP IIRC, it depends what kind of functionality the DNS server will be providing. -- mors omnia vincit ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 11:23 ` Nick Drage @ 2004-09-23 13:01 ` Samuel Díaz García 2004-09-23 13:19 ` Alexis 2004-09-23 14:13 ` Jason Opperisano 2 siblings, 0 replies; 21+ messages in thread From: Samuel Díaz García @ 2004-09-23 13:01 UTC (permalink / raw) To: Netfilter Mailing List Sorry, you've reason. But I answered that to simplify and thinking about an internal DNS server that only have the intranet names in it and the external queries are redirected throw external servers. Sorry again. Nick Drage writes: > On Thu, Sep 23, 2004 at 01:09:43PM +0200, Samuel Díaz García wrote: >> For DNS query only UDP is necesary, not TCP. > > Heh, that's such a common misconception that I almost mentioned it in my > original email. Most DNS queries take place over UDP, however if the > reply to the query is especially large then a new TCP connection is > opened between the client and server. Also zone transfers take place > over TCP IIRC, it depends what kind of functionality the DNS server will > be providing. > > -- > mors omnia vincit > Samuel Díaz García Director Gerente ArcosCom Wireless, S.L.L. mailto:samueldg@arcoscom.com http://www.arcoscom.com móvil: 651 93 72 48 tlfn/fax: 956 70 13 15 ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: nat and dns 2004-09-23 11:23 ` Nick Drage 2004-09-23 13:01 ` Samuel Díaz García @ 2004-09-23 13:19 ` Alexis 2004-09-23 14:13 ` Jason Opperisano 2 siblings, 0 replies; 21+ messages in thread From: Alexis @ 2004-09-23 13:19 UTC (permalink / raw) To: 'Netfilter Mailing List' Just to add some information to the correct one below. Tcp queries are queries greater than 512 bytes. (normally). Microsoft uses to query via tcp with short queries too, I didn’t found any doc or pattern looking the queries to asume why m$ do this. Zone transfers like Nick said, are all via tcp -----Mensaje original----- De: netfilter-bounces@lists.netfilter.org [mailto:netfilter-bounces@lists.netfilter.org] En nombre de Nick Drage Enviado el: Jueves, 23 de Septiembre de 2004 8:24 Para: netfilter@lists.netfilter.org Asunto: Re: nat and dns On Thu, Sep 23, 2004 at 01:09:43PM +0200, Samuel Díaz García wrote: > For DNS query only UDP is necesary, not TCP. Heh, that's such a common misconception that I almost mentioned it in my original email. Most DNS queries take place over UDP, however if the reply to the query is especially large then a new TCP connection is opened between the client and server. Also zone transfers take place over TCP IIRC, it depends what kind of functionality the DNS server will be providing. -- mors omnia vincit ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 11:23 ` Nick Drage 2004-09-23 13:01 ` Samuel Díaz García 2004-09-23 13:19 ` Alexis @ 2004-09-23 14:13 ` Jason Opperisano 2004-09-23 14:34 ` Aleksandar Milivojevic 2004-09-24 9:43 ` Jozsef Kadlecsik 2 siblings, 2 replies; 21+ messages in thread From: Jason Opperisano @ 2004-09-23 14:13 UTC (permalink / raw) To: Netfilter Mailing List On Thu, 2004-09-23 at 07:23, Nick Drage wrote: > On Thu, Sep 23, 2004 at 01:09:43PM +0200, Samuel Díaz García wrote: > > For DNS query only UDP is necesary, not TCP. > > Heh, that's such a common misconception that I almost mentioned it in my > original email. i surprised you didn't...as it comes up here every time DNS is mentioned. and you're 100% right about it being a misconception. > Most DNS queries take place over UDP, however if the > reply to the query is especially large then a new TCP connection is > opened between the client and server. find me a response to a client resolver request that doesn't fit in a single UDP packet, and i'll stop seeing red every time i see someone recommend allowing TCP 53 from any IP to their DNS server (*). > Also zone transfers take place > over TCP IIRC, it depends what kind of functionality the DNS server will > be providing. TCP 53 is for zone transfers. there is no reason to allow TCP from any IP's other then your slave servers. i also recommend ACL-ing zone tranfers in your DNS server configuration as well. (*) the biggest response i've come across that i can recall is an MX record lookup for earthlink.net, which is about 540 bytes on the wire and still "fits" in a single UDP packet. people that manage DNS servers that respond with messages of this size are aware that many people that they want receiving these answers will not allow TCP 53 in through their firewall and act accordingly. -j -- Jason Opperisano <opie@817west.com> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 14:13 ` Jason Opperisano @ 2004-09-23 14:34 ` Aleksandar Milivojevic 2004-09-23 14:44 ` Jason Opperisano 2004-09-24 9:43 ` Jozsef Kadlecsik 1 sibling, 1 reply; 21+ messages in thread From: Aleksandar Milivojevic @ 2004-09-23 14:34 UTC (permalink / raw) To: Jason Opperisano; +Cc: Netfilter Mailing List Jason Opperisano wrote: > find me a response to a client resolver request that doesn't fit in a > single UDP packet, and i'll stop seeing red every time i see someone > recommend allowing TCP 53 from any IP to their DNS server (*). Theoretically (since I don't know of any such implementation), it is perfectly legal to have resolver library that first tries TCP, and than UDP :-P Of course, such approach would be waste of network resources (sending one UDP datagram one way, and another the other way is usually at least as fast as only establishihg new TCP connection without sending any data through it). Anyhow, I don't see why are you going red when you see TCP port 53 open? If it is possible for random internet site to fetch zone from DNS server, it is misconfiguration of DNS server, not of the firewall. OSI layers and all that stuff, you know ;-). If your DNS server does not allow you to restrict who can do zone transfers, that you should seriously consider switching to different DNS server that does. It is the same as if you were to restrict one directory on HTTP server to only certain range of IP addresses, and than blame it on firewall when you misconfigure HTTP server. -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 14:34 ` Aleksandar Milivojevic @ 2004-09-23 14:44 ` Jason Opperisano 2004-09-23 15:09 ` Aleksandar Milivojevic 0 siblings, 1 reply; 21+ messages in thread From: Jason Opperisano @ 2004-09-23 14:44 UTC (permalink / raw) To: netfilter On Thu, 2004-09-23 at 10:34, Aleksandar Milivojevic wrote: > Theoretically (since I don't know of any such implementation), it is > perfectly legal to have resolver library that first tries TCP, and than > UDP :-P > > Of course, such approach would be waste of network resources (sending > one UDP datagram one way, and another the other way is usually at least > as fast as only establishihg new TCP connection without sending any data > through it). > > Anyhow, I don't see why are you going red when you see TCP port 53 open? > If it is possible for random internet site to fetch zone from DNS > server, it is misconfiguration of DNS server, not of the firewall. OSI > layers and all that stuff, you know ;-). it comes from the days of BIND offering up remote root exploits more often that i care to remember. not allowing TCP 53 through the firewall allowed one to get a least a couple of winks over the course of a night. > If your DNS server does not > allow you to restrict who can do zone transfers, that you should > seriously consider switching to different DNS server that does. just adding layers to the onion. -j -- Jason Opperisano <opie@817west.com> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 14:44 ` Jason Opperisano @ 2004-09-23 15:09 ` Aleksandar Milivojevic 0 siblings, 0 replies; 21+ messages in thread From: Aleksandar Milivojevic @ 2004-09-23 15:09 UTC (permalink / raw) To: netfilter Jason Opperisano wrote: > it comes from the days of BIND offering up remote root exploits more > often that i care to remember. not allowing TCP 53 through the firewall > allowed one to get a least a couple of winks over the course of a night. Well, those days are hopefully over. Modern BIND is just as secure as any other service (hm, thinking about it, this isn't much of an argument ;-) ). Plus, it runs as unpriviledged user in chrooted jail just fine (this one is an argument). > just adding layers to the onion. Let me guess, you named your firewall shrek.817west.com? -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 14:13 ` Jason Opperisano 2004-09-23 14:34 ` Aleksandar Milivojevic @ 2004-09-24 9:43 ` Jozsef Kadlecsik 1 sibling, 0 replies; 21+ messages in thread From: Jozsef Kadlecsik @ 2004-09-24 9:43 UTC (permalink / raw) To: Jason Opperisano; +Cc: Netfilter Mailing List On Thu, 23 Sep 2004, Jason Opperisano wrote: > > Most DNS queries take place over UDP, however if the > > reply to the query is especially large then a new TCP connection is > > opened between the client and server. > > find me a response to a client resolver request that doesn't fit in a > single UDP packet, and i'll stop seeing red every time i see someone > recommend allowing TCP 53 from any IP to their DNS server (*). AIX uses just TCP, even for a plain query. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: nat and dns 2004-09-23 11:09 ` Samuel Díaz García 2004-09-23 11:23 ` Nick Drage @ 2004-09-23 13:17 ` Alexis 2004-09-23 14:09 ` Aleksandar Milivojevic 2 siblings, 0 replies; 21+ messages in thread From: Alexis @ 2004-09-23 13:17 UTC (permalink / raw) To: 'Samuel Díaz García', 'Netfilter Mailing List' Microsoft uses tcp for queries too. -----Mensaje original----- De: netfilter-bounces@lists.netfilter.org [mailto:netfilter-bounces@lists.netfilter.org] En nombre de Samuel Díaz García Enviado el: Jueves, 23 de Septiembre de 2004 8:10 Para: Netfilter Mailing List Asunto: Re: nat and dns For DNS query only UDP is necesary, not TCP. Regards, Nick Drage writes: > On Thu, Sep 23, 2004 at 11:00:33AM +0200, Raphael Jacquot wrote: >> hi, >> I have a setup that looks like : >> _____ ____ >> [ ] 192.168.0.100 [ ] >> [ DNS ]------------------------------[ FW ]---- >> [_____] 192.168.0.254 [____] (isp) >> >> and I want the DNS to answer to queries from the outside what's the >> proper way of doing this ? > > I'm presuming that you want to answer queries from everywhere, rather > than just from specific hosts, in which case: > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p udp > --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p tcp > --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -A FORWARD --destination 192.168.0.100 -p udp --dport 53 -j > ACCEPT > > iptables -A FORWARD --destination 192.168.0.100 -p tcp --dport 53 -j > ACCEPT > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > I'd be interested to hear how you get on by the way, I'm not quite > sure that my iptables rulebases are keeping state on DNS requests correctly. > > -- > mors omnia vincit > Samuel Díaz García Director Gerente ArcosCom Wireless, S.L.L. mailto:samueldg@arcoscom.com http://www.arcoscom.com móvil: 651 93 72 48 tlfn/fax: 956 70 13 15 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 11:09 ` Samuel Díaz García 2004-09-23 11:23 ` Nick Drage 2004-09-23 13:17 ` Alexis @ 2004-09-23 14:09 ` Aleksandar Milivojevic 2 siblings, 0 replies; 21+ messages in thread From: Aleksandar Milivojevic @ 2004-09-23 14:09 UTC (permalink / raw) To: Netfilter Mailing List Samuel Díaz García wrote: > For DNS query only UDP is necesary, not TCP. Wrong. If reply does not fit into single UDP datagram, client will reissue the query over TCP. -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 10:34 ` Nick Drage 2004-09-23 11:09 ` Samuel Díaz García @ 2004-09-23 12:00 ` Raphael Jacquot 1 sibling, 0 replies; 21+ messages in thread From: Raphael Jacquot @ 2004-09-23 12:00 UTC (permalink / raw) To: Netfilter Mailing List Nick Drage wrote: > On Thu, Sep 23, 2004 at 11:00:33AM +0200, Raphael Jacquot wrote: > >>hi, >>I have a setup that looks like : >> _____ ____ >>[ ] 192.168.0.100 [ ] >>[ DNS ]------------------------------[ FW ]---- >>[_____] 192.168.0.254 [____] (isp) >> >>and I want the DNS to answer to queries from the outside >>what's the proper way of doing this ? > > > I'm presuming that you want to answer queries from everywhere, rather > than just from specific hosts, in which case: > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p udp --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p tcp --dport > 53 -j DNAT --to-destination 192.168.0.100 > > iptables -A FORWARD --destination 192.168.0.100 -p udp --dport 53 -j > ACCEPT > > iptables -A FORWARD --destination 192.168.0.100 -p tcp --dport 53 -j > ACCEPT > > iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > > I'd be interested to hear how you get on by the way, I'm not quite sure > that my iptables rulebases are keeping state on DNS requests correctly. > seems to work well, thanks... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 9:00 nat and dns Raphael Jacquot 2004-09-23 10:34 ` Nick Drage @ 2004-09-23 14:17 ` Aleksandar Milivojevic 2004-09-23 22:02 ` Dimitar Katerinski 1 sibling, 1 reply; 21+ messages in thread From: Aleksandar Milivojevic @ 2004-09-23 14:17 UTC (permalink / raw) To: netfilter Raphael Jacquot wrote: > hi, > I have a setup that looks like : > _____ ____ > [ ] 192.168.0.100 [ ] > [ DNS ]------------------------------[ FW ]---- > [_____] 192.168.0.254 [____] (isp) > > and I want the DNS to answer to queries from the outside > what's the proper way of doing this ? Use DNAT target. In short what you need to do is: iptables -A FORWARD -m state --state NEW -j ACCEPT iptables -A FORWARD -p icmp -m state --state RELATED -j ACCEPT iptables -A FORWARD -i ext_if -o int_if -d 192.168.0.100 \ -p udp --port 53 -m state --state NEW -j ACCEPT iptables -A FORWARD -i ext_if -o int_if -d 192.168.0.100 \ -p tcp --port 53 -m state --state NEW -j ACCEPT iptables -t nat -A PREROUTING -i ext_if -d ext_ip \ -p udp --port 53 -j DNAT --to-address 192.168.0.100 iptables -t nat -A PREROUTING -i ext_if -d ext_ip \ -p tcp --port 53 -j DNAT --to-address 192.168.0.100 -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 14:17 ` Aleksandar Milivojevic @ 2004-09-23 22:02 ` Dimitar Katerinski 2004-09-23 22:16 ` Jason Opperisano 2004-09-24 1:56 ` Aleksandar Milivojevic 0 siblings, 2 replies; 21+ messages in thread From: Dimitar Katerinski @ 2004-09-23 22:02 UTC (permalink / raw) To: netfilter Sorry, a little bit off topic, but I allways go red about such kind of crappy rules: > Use DNAT target. In short what you need to do is: > > iptables -A FORWARD -m state --state NEW -j ACCEPT Do you know what you just did? You've just allowed any kind of connections, protocols to any port and from/to any destionation. Cute, isn't it? Remember, --state NEW, never ever have meant, and I doubt it'll ever mean that this is an tcp connection with only SYN bit set. It could be everyting, ACK,URG,PSH etc. So guess what, you just open a wide hole in your so called "firewall" machine. You better use --tpc-flags or --syn alias for such purposes. --state NEW can be used for redundant firewalling for example, but for me it has no use. Regards, Dimitar P.S. Why I go red? Because there're thousands of people who use it, and they learned it from someone like you. -- "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 22:02 ` Dimitar Katerinski @ 2004-09-23 22:16 ` Jason Opperisano 2004-09-24 1:56 ` Aleksandar Milivojevic 1 sibling, 0 replies; 21+ messages in thread From: Jason Opperisano @ 2004-09-23 22:16 UTC (permalink / raw) To: netfilter On Thu, 2004-09-23 at 18:02, Dimitar Katerinski wrote: > Sorry, a little bit off topic, but I allways go red about such kind of crappy rules: > > > Use DNAT target. In short what you need to do is: > > > > iptables -A FORWARD -m state --state NEW -j ACCEPT > > Do you know what you just did? You've just allowed any kind of > connections, protocols to any port and from/to any destionation. Cute, > isn't it? Remember, --state NEW, never ever have meant, and I doubt > it'll ever mean that this is an tcp connection with only SYN bit set. It > could be everyting, ACK,URG,PSH etc. So guess what, you just open a wide > hole in your so called "firewall" machine. You better use --tpc-flags or > --syn alias for such purposes. --state NEW can be used for redundant > firewalling for example, but for me it has no use. if you're going to go on a tirade about the problem with that rule, at least point out the actual problem: it doesn't specify the inbound interface and/or source network(s): iptables -A FORWARD -i $INTERNAL_IF -m state --state NEW -j ACCEPT modifying it to use "-p tcp --syn" still allows all TCP traffic through the FORWARD chain in both directions. -j -- Jason Opperisano <opie@817west.com> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-23 22:02 ` Dimitar Katerinski 2004-09-23 22:16 ` Jason Opperisano @ 2004-09-24 1:56 ` Aleksandar Milivojevic 2004-09-24 6:51 ` Jason Opperisano 1 sibling, 1 reply; 21+ messages in thread From: Aleksandar Milivojevic @ 2004-09-24 1:56 UTC (permalink / raw) To: netfilter Quoting Dimitar Katerinski <train@bofh.bg> Date: Fri, 24 Sep 2004 01:02:11 > Sorry, a little bit off topic, but I allways go red about such kind of crappy > rules: > > > Use DNAT target. In short what you need to do is: > > > > iptables -A FORWARD -m state --state NEW -j ACCEPT > > Do you know what you just did? You've just allowed any kind of > connections, protocols to any port and from/to any destionation. Cute, > isn't it? The above was an obvious typo that I made. It should have read ESTABLISHED, not NEW, of course. It kinda suprised me that it took so long before anybody noticed. As for using only --state NEW in my other rules vs specifying tcp flags, there were some discussions before on the list about it. For most part it will just prevent nmap and similar programs to do some types of tests used to remotely determine OS type. Personally, I do use tcp-flags option in combination with --state NEW. And what I sometimes type when giving examples (mostly not, becase of pure laziness on my part) is that they are examples and that reader should add additional flags to make it more tight. > P.S. Why I go red? Because there're thousands of people who use it, and > they learned it from someone like you. Maybe yes, maybe no. The bottom line is that probability of somebody getting burned by not using tcp-flags (or simply syn) option is quite low. But if that's going to make you so much happier person, I can start typing mile long examples instead of giving hints. I could bet that out of those thousands, there will be at least 99% that will fail to realize that 2.6 series of kernels is extremely trigger happy to load ipv6 module (which will automatically assign link local IPv6 addresses to all Ethernet interfaces), and that is much more serious problem than omiting --syn or whatever... -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: nat and dns 2004-09-24 1:56 ` Aleksandar Milivojevic @ 2004-09-24 6:51 ` Jason Opperisano 0 siblings, 0 replies; 21+ messages in thread From: Jason Opperisano @ 2004-09-24 6:51 UTC (permalink / raw) To: netfilter On Thu, 2004-09-23 at 21:56, Aleksandar Milivojevic wrote: > Quoting Dimitar Katerinski <train@bofh.bg> > Date: Fri, 24 Sep 2004 01:02:11 > > > Sorry, a little bit off topic, but I allways go red about such kind of crappy > > rules: > > > > > Use DNAT target. In short what you need to do is: > > > > > > iptables -A FORWARD -m state --state NEW -j ACCEPT > > > > Do you know what you just did? You've just allowed any kind of > > connections, protocols to any port and from/to any destionation. Cute, > > isn't it? > > The above was an obvious typo that I made. It should have read ESTABLISHED, not > NEW, of course. It kinda suprised me that it took so long before anybody noticed. i regret not pointing out in my response that it was obvious to me that this was a typo, and not any reflection on the poster in any way, shape, or form. > Maybe yes, maybe no. The bottom line is that probability of somebody getting > burned by not using tcp-flags (or simply syn) option is quite low. But if > that's going to make you so much happier person, I can start typing mile long > examples instead of giving hints. precisely. the rules that get posted here are to illustrate the point, not our recommendations of what makes a perfect firewall. i know as well as anyone that the easiest path is to lurk and wait for typo to pounce upon. -j -- Jason Opperisano <opie@817west.com> ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <20020829192902.29524.97535.Mailman@kashyyyk>]
* NAT and DNS [not found] <20020829192902.29524.97535.Mailman@kashyyyk> @ 2002-09-11 12:10 ` Mauricio Gouvea 2002-09-11 13:10 ` Antony Stone 0 siblings, 1 reply; 21+ messages in thread From: Mauricio Gouvea @ 2002-09-11 12:10 UTC (permalink / raw) To: netfilter Hi, is it possible to put a DNS server behind a firewall (iptables) doing NAT ? If I set the FORWARD rules for a valid ip alias 0n my firewall and the POSTROUTING for an inside IP address this DNS SErver will answer to external world with no problems ??? I´ve never tested this. Thanks, Mau ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: NAT and DNS 2002-09-11 12:10 ` NAT and DNS Mauricio Gouvea @ 2002-09-11 13:10 ` Antony Stone 0 siblings, 0 replies; 21+ messages in thread From: Antony Stone @ 2002-09-11 13:10 UTC (permalink / raw) To: netfilter On Wednesday 11 September 2002 1:10 pm, Mauricio Gouvea wrote: > Hi, is it possible to put a DNS server behind a firewall (iptables) doing > NAT ? Yes. > If I set the FORWARD rules for a valid ip alias 0n my firewall and > the POSTROUTING for an inside IP address this DNS SErver will answer to > external world with no problems ??? Not quite. You need the DNAT rule in the PREROUTING chain, and the rule inthe FORWARD rule has to be for the internal (ie private) address, because by the time the packets get to the FORWARD chain, they've already been DNATted. > I´ve never tested this. Remember that DNS uses both UDP and TCP (both on port 53), remember also that depending on what sort of DNS server it is (forwarding, authoritative, primary, secondary, caching...) you may want to allow outgoing requests from it as well as incoming ones. Antony. -- How I want a drink, alcoholic of course, after the heavy chapters involving quantum mechanics. - 3.14159265358979 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2004-09-24 9:43 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-23 9:00 nat and dns Raphael Jacquot
2004-09-23 10:34 ` Nick Drage
2004-09-23 11:09 ` Samuel Díaz García
2004-09-23 11:23 ` Nick Drage
2004-09-23 13:01 ` Samuel Díaz García
2004-09-23 13:19 ` Alexis
2004-09-23 14:13 ` Jason Opperisano
2004-09-23 14:34 ` Aleksandar Milivojevic
2004-09-23 14:44 ` Jason Opperisano
2004-09-23 15:09 ` Aleksandar Milivojevic
2004-09-24 9:43 ` Jozsef Kadlecsik
2004-09-23 13:17 ` Alexis
2004-09-23 14:09 ` Aleksandar Milivojevic
2004-09-23 12:00 ` Raphael Jacquot
2004-09-23 14:17 ` Aleksandar Milivojevic
2004-09-23 22:02 ` Dimitar Katerinski
2004-09-23 22:16 ` Jason Opperisano
2004-09-24 1:56 ` Aleksandar Milivojevic
2004-09-24 6:51 ` Jason Opperisano
[not found] <20020829192902.29524.97535.Mailman@kashyyyk>
2002-09-11 12:10 ` NAT and DNS Mauricio Gouvea
2002-09-11 13:10 ` Antony Stone
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox