In article <[EMAIL PROTECTED]>, Brian J. Murrell <[EMAIL PROTECTED]> wrote: >On Sun, Apr 07, 2002 at 11:13:58AM +0200, Andre Breiler wrote: >I think I disagree. Security (access mitigation) as always been >there, NAT as kinda "grown on", through a historical path of >MASQUERADING in 2.2, and heck I don't even recall what it was on 2.0. >I know ipfwadm but forget it's core functionality.
Everything before netfilter (ipchains, ipfwadm, and ipfw(?) in the pre-1.3 days) was pretty much the same model with different API's: accept/reject/drop/log packets, MASQ, transparent proxy, and (in ipchains and later) mark packets for traffic classification and policy routing. Netfilter seems to be an attempt to add a clumsy programming language for a clumsy virtual machine (chains with jump and RETURN are Turing-complete, and a number of the extension modules implement things that act like memory and registers) into the existing filtering framework, in addition to general [SD]NAT and higher-layer protocol mangling. It would probably be faster and more reliable if netfilter actually _was_ a programming language for a virtual machine, because then we could use global filter optimization and dynamic machine code generation, and we wouldn't need a new kernel module *and* user-space shared library for every new feature--just have iptables-restore generate a .o file and insmod it. >I guess what I am asking is don't more netfilter boxes go in for >security than access provision? Almost all of my netfilter boxes are for access provision, because I build security boxes with ipchains. I have years of experience building ipchains boxes, whereas I have only started experimenting with iptables recently. I estimate almost a year of auditing and development on my part before I will have any reason to use iptables instead of ipchains for production security boxes. I do use iptables for a lot of really nifty things that ipchains can't do, but security is not one of them. When talking to people who are not experts in the field (e.g. potential customers/IT managers/etc), I try to distinguish between a "firewall" (a security device) and a "gateway" (an access provision device). Incidentally, if anyone has a good way to communicate this concept to other human beings, or even more-standard jargon than those two words, I'd be interested in hearing about it. A "firewall" and a "gateway" are both cheap Linux boxes running some kernel packet filter or another (ipchains or iptables), a log daemon, and maybe a cron job which dumps the entire machine onto a CD-R (assuming that the machine in question isn't actually booted from one), and maybe some customized code (nothing I haven't audited at source level personally). A "firewall" runs nothing else, while a "gateway" also runs application proxies, DNS, email or web servers, etc. Additionally, the network that goes behind a "firewall" is quite limited--it tends to live in a locked room. Not surprisingly, I have a lot more demand for "gateways" than "firewalls." If both security and access provision are required, I usually specify one box for each requirement. I find that often the customer has one or the other already, or they want three levels of security to begin with, so that's not a particularly onerous requirement. I often end up with e.g. a Cisco box for security and Linux for access, or a WinNT box for access and a Linux box for security. >There is nothing stopping a trojan, spread by e-mail virii from making >a UPnP request and making the machine a zombie sitting in wait for >instructions from it's "master". Your first problem is that you allowed untrusted network traffic (e-mail) through your firewall to an unhardened machine. Fix that problem, then worry about UPnP. ;-) >With protocol aware conntracking, >this is more difficult. A trojan could mask itself as a supported >protocol which allows port "listening" but it would take substantial >effort for the trojan to mask another protocol enough for this to >work. I've never seen a protocol that a trojan can't easily tunnel a command channel, with or without protocol-aware conntracking and/or listening sockets. I've written dozens of such tunnels myself, including tunnels through some highly invasive content-filtering application proxies, and participated in the arms-race between hiding these tunnels and detecting them on both sides. There is a distinction between tunneling systems that listen and tunneling systems that poll, but it's not a difference. Both involve making holes in the firewall for extensive periods of time. Both show up if you analyze the firewall's audit trail to find them, and neither show up if you don't. Frankly, I don't see the advantage of launching an attack through a firewall's NAT helpers by manipulating them from the client side. I would go through the internal box I had already compromised, since it's much less likely to have any real auditing features enabled, and it's much less likely to be noticed when it talks to other internal machines at my request. It's also likely that the people who run the network in question do not have a working defense against whatever method I used to compromise the internal network, which suggests I should continue to use that method in the future. In practice, I have to either trust both the software and the user running it, or I don't. To me there's no difference at all between e.g. Windows Media Player on Windows and X-Chat on Linux when it comes to cracking your way through a firewall. Both of them have at least one widely installed version that can be remotely commandeered to open arbitrary listening ports through some kind of filtering NAT proxy or other. What license the software is distributed under is irrelevant, and the user and the software cannot be considered independently--no system is secure if the user sitting in front of it clicks wherever it says "click here." -- Zygo Blaxell (Laptop) <[EMAIL PROTECTED]> GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
