> In my experience, recent Windows' IP stacks aren't _that_ bad at > handling unexpected IP-level data. Most of the threat these days is > at the application level, which is primarily what things like Zone > Alarm and Tiny target.
Yeah, it's not so much recent versions of Windows I'm worried about. I have a number of machines on a home LAN with various versions of Windows on them (98, 2k, XP Pro). Some machines are for playing games (Win98 can play those old DOS games). Some are for other people in my house. Everything here already IS behind a real computer (3.3-RELEASE). I also have VPN connections from the outside, joining some friends' home LANs. My concern is that viruses are smart enough to spread through the insecure MS netowork protocols, which can't be disabled normally under various versions of Windows. I have Kerio firewall (It looks like a hacked-up version of the old Tiny, before they went commercial) on most machines, but I'm fairly sure it's nothing more than a SYN filter. I'm just concerned as to whether smarter virus writers are going to slip around these firewalls and spread through my LAN. Also, I'm not sure I can trust my users 100%. > NT has always had a rudimentary IP filter if all you want to do is > filter ports. Recent versions are slightly more capable: > http://www.hsc.fr/ressources/outils/pktfilter/ Thanks, this is VERY interesting, I'll take a look at this. I've seen NT packet filtering capabilities in 2000/XP, but it seems like they filter all ports by default incoming, and you have to manually re-enable every port you want open. Since LAN users may want to run, say, game servers, I don't want to have to make a firewall hole for each port; I only need to block the ports I know are problems. This sounds promising. > At least Tiny - and probably ZA too judging by its behavior - mostly > watch a fairly high level in the driver stack, where they actually > get explicit notification of new connections. That's why both seem > to be stateful by default -- they're using the OS's stack. > ... > I'm confused about this part. Windows doesn't typically send wire > network data through user space (though I suppose you could argue the > distinction on 9x, but that's another topic). For the BSDs, why? Actually, from what I've seen of both 9x and NT networking stacks, it looks to me more like they exist entirely within "driverland", which is neither kernel-land nor userland, really. The network drivers for an ethernet card collect layer 2 packets and send them up through a layer or two more of driver space before hitting the kernel. At least, this seems to explain why the same firewall software works in pretty much the same way between different versions of Windows. Also, dial-up and ethernet connections are handled differently, so firewalls need to know a lot about both to work for Windows (though I'm only interested in ethernet). So one need (theoretically) only insert a sort of driver between the network abstraction level of Windows (which reassembles IP and manages things like ARP) and the physical device driver (which simply captures and sends packets on the interface). I figure, if there were an implementation of pf that filters packets in userland between file descriptors, one could easily make a userland Windows program (run as a dreaded NT service). Then one could hunt down one of those firewall packet interceptor drivers, or learn how to write one from scratch, and make it forward packets back and forth between the userland service and the interfaces. Or one could get crazy and cram the entire pf engine into the driver, cranking up performance. My comment about userland pf filtration is just the idea of some rather strange uses of pf. Since there is only one pf running on a machine at a time, and it can only be controlled by root, it can't be used for anything but filtering real packets on real interfaces. There may be a reason somebody wants to separate a series of networks, and perform filtration on some channels at a reduced priviledge level (e.g. so a regular user can control filtration, or to prevent leakage between networks). So one could use userland tunneling applications and a userland pf. For instance, one could modify a pptp userland daemon to spit packets through a unix-domain socket instead of a tun driver. Chain two of these together with a userland pf in between, and the user now has a filtering pptp proxy, using the ultra-powerful pf engine, which the admin of that machine doesn't have to maintain or worry about. The user running this proxy could administer it as a normal user, without needing any kind of priviledge escalation. So you could use your OpenBSD server to run a VPN that you don't want to actually be connected to. Why would you wanna do this? Don't ask me, I dunno. But it would be nice if we could, just in case we decide we want to some day later. :-D > Doable, yes, but I suspect there's a shortage of people with time and > willingness to get familiar with both systems. I really wouldn't mind building a system like this myself (maintaining it is a whole other issue). I'm not a master programmer, and I've never done any l33t kernel-hacking or anything, but I can read and write a little C. I guess the only hard part is finding the driver to insert into Windows' network stack. Porting pf to Windows would be much easier, however, if there were a userland implementation of pf. It really wasn't a demand or feature request, but sort of a theoretical musing. If anybody ever runs into some information that would be useful for porting efforts (e.g. some code I could take apart for a packet interception driver), I'd love to hear about it. Armed with sufficient information, I wouldn't mind tackling the port myself. pf is one serious piece of work. It really has proven to be the "killer app" for OpenBSD for most home LAN users, and I wouldn't live a single networked day without it. Thanks! __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
