right you are. it's a problem for both firewall and vpn products, and our consultants see this frequently in the field when doing network assessments. most of the vendors try to control the environment by taking the traffic to their own processes (sometimes in the kernel, often in userland), which can do proxying or stateful inspection. (sometimes these processes have even been statically linked.) (they think this limits the size of the exposed target to a productive attack -- as opposed to a denial of service). when you ask an architectural question "what services provided by the OS do you rely on, and for what, exactly?" very few software companies have prepared or documented an answer to this question, and without open source you can't answer it yourself. we are left to wonder if they even *know* the answer, which doubtless changes for each dot release of each firewall product. in practice: many of the vendors try to document their way around the problem. e.g. they have a big section in their administration manual or on the web site about securing the operating system before doing the installation, prerequisite patches and the like. usually, on unix, they turn off services by replacing /etc/rc* and inetd.conf, and most of them add a packet filter (as a kernel driver) which limits traffic to ports running known services, often provided by the vendor. seldom do they replace key binaries (e.g. named, sendmail). seldom is there a mechanism for maintaining trust in key binaries or configurations (e.g. tripwire). areas of concern i've noticed include: - reliance on naming services (like dns) - how logging is done (syslog, nt event logs, proprietary logs etc). - management tools provided by hardware vendors (running snmp) - mystery users running processes for firewall products running on NT, this is a much bigger mess, since any sort of installation script would be taking the operating system from one unknown state to what is merely a different unknown state. given a random installation done by some reseller of the product, what can we do after the fact? you can't trust the gui, in my experience. you have to look at the text output of the gui, which represents the rules and definitions of objects such as trusted networks which are what is actually loaded by the bits that do the actual work. you look at netstat and services running, scratch your head (who's got *that* port open?), try to find some analog for lsof on NT (please tell me about your favorites), run scans against the firewall, and ask the vendor: "which of these services MUST be left running on NT lest the firewall stop working?" it usually isn't documented, and you get crappy off-the-cuff answers, in my experience. (then you go through a painful dialog: "now, tell me what you use the rpc service for. tell me why i have to run the microsoft dns service on an nt firewall, rather than relying on another dns. tell me what this user with a predefined password is for... yes, i know compaq insight manager comes on every compaq machine, but...") it's painful partly because it's hard to find the people at the vendor to answer the questions, since the support people are not the programmers, and even when they answer a question about how it needs to be to continue working, they don't know how to answer the question "why?" and refuse to say "i don't know but i'll let you talk to someone who does".). to reduce radius exposed to attack, you're forced to practice computer science as if it were experimental brain surgery: lobotomize some services, and see if anything noticeably breaks. (taking comfort only in binary search converging in log n time.) On Tue, Nov 23, 1999 at 08:25:06PM +0000, Crispin Cowan wrote: > I'm rather amazed at the existance of the firewall *application* market, where > you buy a firewall product and install it on one of your server machines. How > can such an application install take a pre-installed machine from an unknown > state to a secure state? Does the install script for (say) Checkpoint do > extensive configuration checking and adjusting? Or do they just assume a very > competent sys admin puts the machine into a "firewall" configuration? > -- mark seiden, misat_private, 1-(650) 592 8559 (voice) Pacific Time Zone or misat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:14:15 PDT