> I did not mean to imply that the list had let an obvious security hole get > propagated - I know my own understanding is limited and probably flawed, > and I probably phrased the post poorly.
No, your question was phrased well. I was explicit in my reply because a) this question has come up before, b) being as clear as possible helps avoid confusion, and c) maybe someone will actually find the post in the archives someday, and any extra clarity may help them get their question answered. > Just to confirm my understanding: > > In order to allow HTTP access to 192.168.100.1, I do need to comment the > explicit DENY rule, but there should not be a need to add an explicit > ACCEPT rule for 192.168.100.1 allowing HTTP traffic. After disabling the > DENY rule, the cable modem becomes, for all intents and purposes, just > another web site on the web. > > Right? If the 192.168.100.1 IP is referring to a "secret" IP embedded in your cable/xDSL modem, and you want to pull up a web-page, start a telnet connection, or otherwise connect to your modem, then you are correct. > Is there a way, or any reason, to DENY everything *but* 192.168.100.1? A > pointer to TFM to RTFM would be a appreciated! This involves merging two network ranges...you want to deny everything from 192.168.0.0/16, but allow packets from 192.168.100.1. With ipchains, this is possible, but it involves creating a new rule chain. Basically, you send all the questionable traffic to a seperate chain, which can then return back to the list for any allowed traffic, and finally deny anything that wasn't specifically allowed. If you simply add a rule allowing traffic from 192.168.100.1 prior to the default deny for the 192.168.0.0/16 subnet, *ALL* packets from 192.168.100.1 will be accepted, bypassing the later firewall rules, and you *WILL* have the sort of security hole you were worrying about. Out of necessity, I have added new chains for exactly this sort of filtering when building a proxy-arp or static-nat based DMZ, but the existing private-IP spoofing protection has not yet been migrated to this form yet, mainly due to the fact that I haven't really modified this functionality from the original Materhorn/Eiger firewall rules built by Matthew Grant. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
