I'm setting up LEAF (Bering uClib 2.0) for a new condo with in-the-wall ethernet and lots of tech-savvy visitors some of whom run virus hosts from Redmond. I want vistors to be able to plug their laptops into any jack in the wall, including jacks that may be used by members of the household. But I don't want to allow them the same priveleges as "known" hosts, esp. access to other hosts on the LAN.
Basically, I want to offer DHCP leases on eth1, and if the MAC address is unknown to put it in an effective dmz that's only allowed access to the WAN via eth0. This would be trivial to do if I had an eth2, but there's only one jack at each location so I can't just add a new NIC.
I'd also like to refuse connections to static IP addresses that happen to be in the right range so that folks have to go through dhcp.
Is this possible using Bering? Any suggestions where to start reading on how to set it up? The hardware in this case is a Soekris box (boot medium is a CF card), so I'm not limited to a floppy-based distro; but I use Bering everywhere else and want to keep things compatible.
The short answer to your question is NO. Not for any reason specific to Bering, LEAF, or even Linux ... routing and firewalling just don't work that way.
You can certainly configure DHCP to offer one set of IP addresses (191.168.1.0/24, say) to machines with "recognized" MAC addresses, and a different set of IP addresses (191.168.2.0/24, say) to machines with "unknown" MAC addresses. And doing so will prevent honest visitors from accessing your local systems inadvertently. But doing this will not prevent an intruder from plugging in and accessing your LAN on purpose, at least not if the intruder knows a little about your LAN.
Since access to LAN hosts is direct, not routed, all an intruder needs to do is know that the "good" LAN network is 192.168.1.0/24. He can then skip DHCP assignment completely, using trial and error to find a 192.168.1.d address not currently in use, and then use it to access "good" LAN hosts directly. (My use of "access" here is intentionally blurry; the intruder still needs to find ways to connect to the machines, but you used "access" in your question, so I assume you have something concrete in mind, like the ability to connect to Samba shares.)
One possibility, I suppose, is to route ALL traffic through the router, even LAN-to-LAN traffic. You do this by putting every machine on a static route to the router (in effect, on a /32 network with a single, static route in its routing table). Then the router sees every packet coming *from* each "good" host. I've done only tiny, experimental setups like this, and it works for some uses, but I suspect a real implementation would hit problems that my small experiment missed. (It also effectively halves your LAN bandwidth.) An intruder can still put himself on a /24 network, but the replies go through the router so be controllable.
Another possibility is to implement the desired restrictions on the individual "good" hosts on the LAN. In effect, this means run a local firewall on each of them, one that ALLOWs traffic only to and from "good" MAC addresses. I could do this for a system of all-Linux machines. Probably a Windows expert could do it for Windows hosts (and an OS/X specialist for Mac hosts, and so on).
BTW, the more common version of this question works the opposite way - give "good" hosts access to the Internet but allow "bad" hosts to access ONLY the LAN. This is easy to do, since Internet access, unlike LAN access, does have to go through the router. (You do it by filtering on MAC address directly in the Bering router, a standard capability of iptables.)
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
