Re: [pfSense Support] DNS cache poisoning (solved)
Chris Buechler wrote: Does somebody know a consumer grade DSL-Router who does NAT with port randomization out of the box? Not sure if my Westell does or not, I use the IP passthrough so my firewall gets the public IP and would suggest you do the same if possible. I do use its NAT for my dual WAN test network, but don't really care what it does for that usage. I found a simple workaround for this issue at least for the combination Zyxel DSL-Router / pfsense: Instead of using SUA (many to one NAT) use 1:1 NAT from xDSL to pfSense. Then the port Numbers are not affected. And it's better than switch to bridge mode, because there is no more control over the router via SNMP, Pings, Management and more. This should work with other routers, with different naming for NAT. Beat Siegenthaler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning (solved)
A bit Off-Topic... You can find no Information about DNS-Cache Poisoning at ZyXEL's Website. As manufacturer of NAT-Serializers this is poor behavior. Not for old and probably not patchable Routers nor the Information that maybe newer Products can solve this issue. Does somebody know a consumer grade DSL-Router who does NAT with port randomization out of the box? regards, Beat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning (solved)
On Thu, Jul 31, 2008 at 3:01 AM, Beat Siegenthaler [EMAIL PROTECTED] wrote: A bit Off-Topic... You can find no Information about DNS-Cache Poisoning at ZyXEL's Website. As manufacturer of NAT-Serializers this is poor behavior. Wow, indeed it is. I would suggest contacting them, I'm sure you won't be the first. Maybe they'll get the point eventually... Not for old and probably not patchable Routers nor the Information that maybe newer Products can solve this issue. Does somebody know a consumer grade DSL-Router who does NAT with port randomization out of the box? Not sure if my Westell does or not, I use the IP passthrough so my firewall gets the public IP and would suggest you do the same if possible. I do use its NAT for my dual WAN test network, but don't really care what it does for that usage. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Chris Buechler wrote: How is your outbound NAT configured? Even static port won't rewrite the source ports to something incremental, it just retains whatever the source port is. Automatic outbound NAT rule generation (IPsec passthrough) Auto created rule for LAN Static Port NO Port Forward: WAN TCP/UDP 53 (DNS) atom (ext.: x.y.z.b) 53 (DNS) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Tue, Jul 22, 2008 at 1:02 AM, Beat Siegenthaler [EMAIL PROTECTED] wrote: Chris Buechler wrote: How is your outbound NAT configured? Even static port won't rewrite the source ports to something incremental, it just retains whatever the source port is. Automatic outbound NAT rule generation (IPsec passthrough) Auto created rule for LAN Static Port NO Port Forward: WAN TCP/UDP 53 (DNS) atom (ext.: x.y.z.b) 53 (DNS) Strange, I'm on the 1.3 alpha snaps and am not seeing this behaviour through my unpatched BIND instance (which tcpdump confirmed was using the same source port and on the outside of pfsense was using what appeared to be random ports). It's possible that this is fixed in the PF import in FreeBSD 7.0, but I'm a little surprised. You might try the 1.2.1 snaps and see if you have better results. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning (solved)
On Tue, Jul 22, 2008 at 1:17 AM, Beat Siegenthaler [EMAIL PROTECTED] wrote: Beat Siegenthaler wrote: Upps, stop the press... I apologize for the hype. No cause for alarm. Packet Dump at the pfSense WAN side shows a excellent entropy. I did not realize that there is another DSL natting device between pfSense and the Internet. Did I mention it's a standard ZyXEL? Sorry about this Beat (me) lol, thanks! --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Mon, Jul 21, 2008 at 4:58 AM, sai [EMAIL PROTECTED] wrote: checkpoint firewalls seem to have a problem in not randomising (or even de-randomising) dns request source port [1] do we have a similar problem with pfSense? I did 3 digs to 198.6.1.1, 198.6.1.2 and 198.6.1.3 ( I have 2 isps, load balanced) pfctl -ss (to see the states) self udp 10.60.60.10:33306 - a.b.c.d:51192 - 198.6.1.1:53 MULTIPLE:SINGLE self udp 10.60.60.10:33306 - e.f.g.h:57512 - 198.6.1.2:53 MULTIPLE:SINGLE self udp 10.60.60.10:33306 - a.b.c.d:56970 - 198.6.1.3:53 MULTIPLE:SINGLE self udp 198.6.1.1:53 - 10.60.60.10:33306 SINGLE:MULTIPLE self udp 198.6.1.2:53 - 10.60.60.10:33306 SINGLE:MULTIPLE self udp 198.6.1.3:53 - 10.60.60.10:33306 SINGLE:MULTIPLE looks like my (linux) box is sending source only set to port 33306 (bad linux, bad) but pfSense is randomising it just fine. yes I know that this is not a statistically valid data set, and the port range is quite limited, but it looks ok. could one of the devs confirm that dns cache problem is mitigated ? sai refs: [1] http://seclists.org/fulldisclosure/2008/Jul/0104.html [2] http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html [3] https://www.dns-oarc.net/oarc/services/porttest See http://blog.pfsense.org/?p=210 Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
sai wrote: checkpoint firewalls seem to have a problem in not randomising (or even de-randomising) dns request source port [1] do we have a similar problem with pfSense? No, pf has randomized source ports on all NATed TCP and UDP traffic for 8 years. I was surprised to find out that's the exception rather than the norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize source ports on NATed traffic. The net result of this is if your DNS servers are behind pfSense, you could very well be protected from all this DNS noise of late even without patches. For the DNS forwarder running on pfSense itself, see http://blog.pfsense.org/?p=210 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Chris Buechler wrote: No, pf has randomized source ports on all NATed TCP and UDP traffic for 8 years. I was surprised to find out that's the exception rather than the norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize source ports on NATed traffic. I am not enthusiastic about this: Same Server behind pfSense and dd-wrt does differ sightly: The server runs patched [EMAIL PROTECTED] pfSense: [EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. IP is POOR: 26 queries in 4.7 seconds from 26 ports with std dev 8.47 dd-wrt: [EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. IP is GOOD: 26 queries in 4.6 seconds from 26 ports with std dev 17271.44 Source: https://www.dns-oarc.net/ Also the web-based test is very interesting: pfsense: source-port randomness=poor (deviation 17) transaction id randomness=great (deviation 19030) dd-wrt: source-port randomness=great (deviation 21110) transaction id randomness=great (deviation 17122) Other Test @ www.doxpara.com : Your name server, at x.y.z.y, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 5. Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds. Requests seen for e85e29497dea.toorrr.com: x.y.z.y:11970 TXID=47044 x.y.z.y:11971 TXID=62299 x.y.z.y:11972 TXID=65287 x.y.z.y:11973 TXID=13892 x.y.z.y:11975 TXID=50242 Not really a problem for me, but some may have ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [pfSense Support] DNS cache poisoning
Tested using those tests, out of curiosity - and we passed with flying colors. Could it be your ISPs DNS that is bad? (that pfSense is relaying?) and not pfSense directly? -Tim -Original Message- From: Beat Siegenthaler [mailto:[EMAIL PROTECTED] Sent: Monday, July 21, 2008 1:11 PM To: support@pfsense.com Subject: Re: [pfSense Support] DNS cache poisoning Chris Buechler wrote: No, pf has randomized source ports on all NATed TCP and UDP traffic for 8 years. I was surprised to find out that's the exception rather than the norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize source ports on NATed traffic. I am not enthusiastic about this: Same Server behind pfSense and dd-wrt does differ sightly: The server runs patched [EMAIL PROTECTED] pfSense: [EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. IP is POOR: 26 queries in 4.7 seconds from 26 ports with std dev 8.47 dd-wrt: [EMAIL PROTECTED]:~] # dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. IP is GOOD: 26 queries in 4.6 seconds from 26 ports with std dev 17271.44 Source: https://www.dns-oarc.net/ Also the web-based test is very interesting: pfsense: source-port randomness=poor (deviation 17) transaction id randomness=great (deviation 19030) dd-wrt: source-port randomness=great (deviation 21110) transaction id randomness=great (deviation 17122) Other Test @ www.doxpara.com : Your name server, at x.y.z.y, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 5. Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds. Requests seen for e85e29497dea.toorrr.com: x.y.z.y:11970 TXID=47044 x.y.z.y:11971 TXID=62299 x.y.z.y:11972 TXID=65287 x.y.z.y:11973 TXID=13892 x.y.z.y:11975 TXID=50242 Not really a problem for me, but some may have ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Tim Dickson wrote: Could it be your ISPs DNS that is bad? (that pfSense is relaying?) and not pfSense directly? -Tim Same Server behind pfSense and dd-wrt does differ sightly: The server runs patched [EMAIL PROTECTED] No ISP DNS, my own Server. Official DNS for my domains. In my DMZ. Only difference during the test was a different firewall. Maybe is Your DNS in Front of pfSense ? Beat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Mon, Jul 21, 2008 at 4:10 PM, Beat Siegenthaler [EMAIL PROTECTED] wrote: Chris Buechler wrote: No, pf has randomized source ports on all NATed TCP and UDP traffic for 8 years. I was surprised to find out that's the exception rather than the norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize source ports on NATed traffic. I am not enthusiastic about this: Same Server behind pfSense and dd-wrt does differ sightly: The server runs patched [EMAIL PROTECTED] And it does recursive queries, does not rely on upstream servers? Are you running with static port enabled? That's the only way your source ports aren't going to be randomized, assuming the server is NATed and not just firewalled. Static port disables the source port randomization. This without question works as described. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Mon, Jul 21, 2008 at 3:39 PM, Chris Buechler [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 4:10 PM, Beat Siegenthaler [EMAIL PROTECTED] wrote: Chris Buechler wrote: No, pf has randomized source ports on all NATed TCP and UDP traffic for 8 years. I was surprised to find out that's the exception rather than the norm. Cisco, Checkpoint, amongst numerous others apparently do not randomize source ports on NATed traffic. I am not enthusiastic about this: Same Server behind pfSense and dd-wrt does differ sightly: The server runs patched [EMAIL PROTECTED] And it does recursive queries, does not rely on upstream servers? Are you running with static port enabled? That's the only way your source ports aren't going to be randomized, assuming the server is NATed and not just firewalled. Static port disables the source port randomization. This without question works as described. Unless the delay between queries given the same source port on the querying machine is smaller than the UDP state timeout. Nothing we can do to solve this, it's an issue with the process doing the querying. --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Chris Buechler wrote: And it does recursive queries, does not rely on upstream servers? Are you running with static port enabled? That's the only way your source ports aren't going to be randomized, assuming the server is NATed and not just firewalled. Static port disables the source port randomization. This without question works as described. Yes for internal hosts, I do recursive lookups. Shure, wan incoming port tcp/udp 53 is NAT'ed to the Server in DMZ. But also this is identical in both firewall setups dd-wrt/pfSense And I think it is not really a big problem as long the transaction ID's are really good random. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Beat Siegenthaler wrote: And I think it is not really a big problem as long the transaction ID's are really good random. Curiosity killed the Cat: done a dump on pfSense at the dmz-side. It looks that the source ports from BIND are very good in random. But at the wan-side, the ports are just ascending more or less. What about the mentioned UDP timeout? I try to check out another time what the openwrt, exactly X-WRT (it's not dd-wrt like mentioned before) guys do better in this case ... Number of samples: 29 Unique ports: 29 Range: 21929 - 21961 Modified Standard Deviation: 9 Bits of Randomness: 5 Values Seen: 21929 21930 21931 21932 21933 21934 21935 21936 21937 21938 21939 21940 21941 21942 21943 21944 21945 21946 21947 21948 21949 21950 21951 21952 21953 21954 21956 21960 21961 At the other side, the real good random values before NAT: 00:25:48.787921 4872 my_dns_server.9391 oarc_test.3.35.53: 47201% 00:25:48.979118 4872 my_dns_server.61156 oarc_test.3.36.53: 36685% 00:25:49.168621 4877 my_dns_server.44809 oarc_test.3.37.53: 6012% 00:25:49.357540 4878 my_dns_server.27958 oarc_test.3.38.53: 1136% 00:25:49.544582 4879 my_dns_server.56394 oarc_test.3.39.53: 1611% 00:25:49.731813 4880 my_dns_server.24383 oarc_test.3.40.53: 25202% 00:25:49.919190 4909 my_dns_server.60308 oarc_test.3.41.53: 58128% 00:25:50.108660 4924 my_dns_server.27970 oarc_test.3.42.53: 63983% 00:25:50.312579 4925 my_dns_server.16216 oarc_test.3.43.53: 257% 00:25:50.498615 4926 my_dns_server.34101 oarc_test.3.44.53: 54490% 00:25:50.689823 4928 my_dns_server.38677 oarc_test.3.45.53: 57967% 00:25:50.878837 4947 my_dns_server.39679 oarc_test.3.46.53: 32702% 00:25:51.068412 4966 my_dns_server.29164 oarc_test.3.47.53: 61296% 00:25:51.255607 4967 my_dns_server.13102 oarc_test.3.48.53: 58659% 00:25:51.471649 4968 my_dns_server.18020 oarc_test.3.49.53: 8577% 00:25:51.661415 4969 my_dns_server.31855 oarc_test.3.50.53: 63803% 00:25:51.850299 4982 my_dns_server.47298 oarc_test.3.51.53: 400% 00:25:52.039704 5007 my_dns_server.41360 oarc_test.3.52.53: 35624% 00:25:52.228943 5008 my_dns_server.18233 oarc_test.3.53.53: 24806% 00:25:52.418190 5009 my_dns_server.37245 oarc_test.3.54.53: 9403% 00:25:52.605281 5010 my_dns_server.49778 oarc_test.3.55.53: 24300% 00:25:52.796269 5017 my_dns_server.64789 oarc_test.3.56.53: 52018% 00:25:52.991502 5040 my_dns_server.63998 oarc_test.3.57.53: 7458% 00:25:53.181050 5049 my_dns_server.14257 oarc_test.3.58.53: 13284% 00:25:53.372107 5050 my_dns_server.8396 oarc_test.3.59.53: 24801% 00:25:53.561257 5053 my_dns_server.65268 oarc_test.3.59.53: 10654% 00:25:53.750866 5057 my_dns_server.44739 oarc_test.3.59.53: 20519% - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Mon, Jul 21, 2008 at 5:54 PM, Beat Siegenthaler [EMAIL PROTECTED] wrote: done a dump on pfSense at the dmz-side. It looks that the source ports from BIND are very good in random. But at the wan-side, the ports are just ascending more or less. What about the mentioned UDP timeout? Shouldn't make a difference if the source port is getting nat'd sequentially. That sounds a little odd to me, but I can check that out when I get home and see if I can duplicate. Can you send me whatever test script you are using? Thanks --Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
On Mon, Jul 21, 2008 at 6:54 PM, Beat Siegenthaler [EMAIL PROTECTED] wrote: Beat Siegenthaler wrote: And I think it is not really a big problem as long the transaction ID's are really good random. Curiosity killed the Cat: done a dump on pfSense at the dmz-side. It looks that the source ports from BIND are very good in random. But at the wan-side, the ports are just ascending more or less. What about the mentioned UDP timeout? I try to check out another time what the openwrt, exactly X-WRT (it's not dd-wrt like mentioned before) guys do better in this case ... I just confirmed what I said previously, unless static port is enabled the source port on DNS traffic (and all TCP and UDP traffic for that matter) is rewritten to a randomly selected port. Description of this behavior from OpenBSD developer Ryan McBride: http://seclists.org/fulldisclosure/2008/Jul/0272.html How is your outbound NAT configured? Even static port won't rewrite the source ports to something incremental, it just retains whatever the source port is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [pfSense Support] DNS cache poisoning
Bill Marquette wrote: Shouldn't make a difference if the source port is getting nat'd sequentially. That sounds a little odd to me, but I can check that out when I get home and see if I can duplicate. Can you send me whatever test script you are using? Thanks I use the Link: http://entropy.dns-oarc.net/test/ This generates a randomly choosen link like http://1ddade8a4f72fea465f51549.et.dns-oarc.net/ then the dns-oarc.net can check from which server the recursive query's came. Also quite good readable with lynx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
