#172 ****security warning**** bad route

9.2.0.1
closed
nobody
None
1
2014-12-03
2014-05-04
No

The n4f 9.2 series has a security problem.
I think that 9.2 series should be frozen until this is fixed.
this is not a network configuration issue.
This is the way to reproduce the problem.

1) boot a live cd (no config just a fresh live cd)
2) live cd boots with a default ip
3) I think it is option 2 and choose use dhcp and no for ip6
4) dhcpd will then qurey dns for dhcp.xxx.xxx (you can see this happen if you turn on querylog in bind) make sure to turn it off when you are done))
5) if an IP is returned then it will be bound to eth0 or what ever your nic is
6) at this point ifconfig and netstat -rn will not be ok even before you made any settings to the server config.
7) if a dns query is returned for dhcp.xx.xx then it will break cifs even if you set a static IP.
8) Is it possible this being done on a kernel level? or is it on a script initialization level? Either way I cant fix it.... only reproduce it....beyond my knowledge
9) if you do "nslookup nonexistentdomain.tld" or "dig nonexistentdomain.tld" if no IP is returned you will not be able to reproduce this problem, if an IP is returned then there will be no problem duplicating the results. N4f is specifically asking for the host dhcp.your.domaine
10) here is a good link on"hijacking the NXDOMAIN response" http://hackercodex.com/guide/how-to-stop-isp-dns-server-hijacking/ and N4f is creating a bad route because of this. as you can tell this is really bothering me.
11) another way to reproduce this problem is add dhcp.xxx.xxx in your zone file (adjusted for your lan so it resolves) and boot a live cd
12) m$ netstat -rn
Routing tables
13) my ISP has hijacked the NXDOMAIN and it looks like they were also able to hijack my route as well in the 9.2 versions
14) another way to reproduce this problem is add dhcp.xxx.xxx in your zone file (adjusted for your lan so it resolves) and boot a live cd
15)I don't think the problem is with vlans. I did mention that I noticed the spaningtree protocol (stp) with a protocol analyzer. My best guess is that my ISP used that to correct the bad route. I just wish I could understand how the route was create. It looks to me that nothing malicious has been done to my network.

I hope I have reported this properly and I hope I could get an explanation and the potential damage this bad rout has caused.

I would also like to say that even though I have this issue I think n4f is a great operating system.

my ISP has hijacked the NXDOMAIN and it looks like they were also able to hijack my route as well in the 9.2 versions

16) I hope someone can help me understand this problem.

Here is my route using a bad DNS server

$ netstat -rn
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGS 0 58 re0
66.152.109.0/24 link#1 U 0 21 re0
66.152.109.110 link#1 UHS 0 0 lo0
127.0.0.1 link#11 UH 0 1417 lo0
192.168.1.0/24 link#1 U 0 567 re0
192.168.1.28 link#1 UHS 0 0 lo0

Internet6:
Destination Gateway Flags Netif Expire
::1 link#11 UH lo0
fe80::%lo0/64 link#11 U lo0
fe80::1%lo0 link#11 UHS lo0
ff01::%lo0/32 ::1 U lo0
ff02::%lo0/32 ::1 U lo0

Discussion

  • Daisuke Aoyama

    Daisuke Aoyama - 2014-12-03
    • status: open --> closed
     
  • Daisuke Aoyama

    Daisuke Aoyama - 2014-12-03

    fixed

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks