Shawn, I didn't mean to leave you defending firewalls on my behalf. You've done a good job!
After 40 years designing electronic circuits and programming computers, some of which have been in mission critical applications like nuclear subs, I've met many of the personalities which occupy those professions. Some are rocks -- rocks don't learn much -- usually argue both sides of an issue unknowingly, and spare no names for those who don't submit to their logic. Others listen carefully, ask good questions and offer good advice. Noah doesn't believe in firewalls. Running secure servers directly off the Internet is good, (better?) and besides firewalls don't do you any good. As proof of this, Noah quotes an instance of an NT server being cracked via port 80 and that machine subsequently infected other machines on its network. The only proof I see here is the fact that the system design was inadequate. A good design deals with failures in hardware or software with minimal disruption of services, so rather than conclude that firewalls are no good, let's look at the system design some more. We'll say something later about using machines in public space which have a history of vulnerabilites. Servers in the DMZ should not be serving up anything that isn't permissable as public information. They should have no content on them which would be a liability if exposed to the public. Servers in the DMZ should not be allowed to initiate any connections -- except surreptitiously. No server in the DMZ should listen to or accept any input from other servers in the DMZ (shared applications aside). So, your boss insists you run an insecure OS in the DMZ. You know it will be cracked before long, but it's pretty much contained with the constraints stated above. Provided the other servers are secure, as Noah claims they can be, then all you have is a single failed server in the DMZ, which all the other servers know has been compromised because it's breaking the rules and trying to initiate contact. Are the connections all severed and the system effectively disconnected? No, servers in a trusted zone, connected to the DMZ via a firewall can initiate connections to servers in the DMZ. Obviously that should be done using encryption. Trusted servers, polling servers in the DMZ, is a bottleneck and, depending on latency, may leave critical data on the DMZ servers long enough to be cracked. This is where we resort to surreptitious communications. One of the obvious things a server might do, when it is processing on-line transactions, is to print them. But printer isn't listening on the other end, a trusted computer is. To a cracker, what's going out on the printer port looks pretty normal - transaction data. Besides normal transactions going out the printer port, a regular time tick is printed. Does a cracker dare turn off the printer? Not likely. Will a cracker wonder what some of those strange numbers are that get printed? Maybe. Will they figure out that those numbers are an encrypted message which represents a spread spectrum shifted checksum of running processes? Not nearly as fast as the trusted listener will know that something has gone wrong with the DMZ machine. Besides providing that `ping' which the trusted server needs to hear on a regular basis, the ping can also indicate that the trusted server needs to initiate a connection and get/put some information. I'll repeat, as near as memory allows me, that there are two kinds of computers hooked to the Internet, those which have been cracked and those that will be. Running a broad range of services on those Internet connected machines only means they will be cracked sooner than later. I'm aware that this is a `ridiculous' statement, so no further flames are required. Once again, I repeat that security will be better with a firewall, running a minimal chunk of code. Those machines which allow connections to be made from the Internet should be in a DMZ -- including both web servers and mail servers. Servers in a DMZ should not be able to talk to one another unless they are sharing a common application. Data collected on the DMZ servers, which must not become public information, should be quickly pulled off those servers by a trusted machine which initiates the connection via a secure channel. There are many ways to surreptitiously monitor servers in the DMZ to detect their failures and/or compromises, the printer port being just one of them. Operating an OS in the DMZ, which has a history of exploits, may be a political necessity, but as a system designer, it's your job to contain that expected exploit as quickly as possible - a trusted machine can pull the power plug a lot faster than rousting the sys admin out of bed to do it. Complaining that firewalls are little more than a false sense of security doesn't do much to address the requirements of the system or provide a design to meet those requirements. As a consultant who spent more months than I want to remember as a key player in the design of a double redundant communications and failover system for multiple computers operating a uranium enrichment facility, I have some ideas about what it takes for computers to share a sense among themselves that they are working OK. I also know that there will always be some uncertainty - two people with watches generally don't know what time it is, though they generally know the time. I've provided the method I would use for a secure and robust system. If it works properly, it will contain an exploit to a single DMZ server. That exploit will be detected in a reasonable number of milliseconds by a trusted machine. Corrective action will be automatic. With failover to another server, the system will continue to operate without the loss of any transactions. Anyone who can improve on this model, or show that an alternative model is more secure, can be sure I'm all ears. If you don't understand the presentation, ask me to elaborate or provide an example. And yes, flames are welcome too. Forest fire fighters use firewalls, sometimes successfully, to contain flames, but for the rest of use there's procmail and /dev/null. -- Sincerely, David Smead http://www.amplepower.com. On Sun, 21 Apr 2002, Shawn McMahon wrote: > begin Noah Meyerhans quotation: > > > > I just don't see how that gets you anything at all if only the "trusted" > > ports have any services listening on them. I have seen personally a > > WinNT box, behind a firewall, with only port 80 visible to the world get > > cracked. Not only was it cracked, but it was then used as a launch pad > > for an attack on another box that was also in the DMZ. All that was > > with only port 80 open. > > Ok, I don't see why "this has not been sufficient in some circumstances" > translates to not getting you anything at all. > > Every security tool ever used fails this test you seem to be using. > > > Basically, my approach is to assume that all ports on all hosts are > > visible to the world. To me, this as a fundamental fact of networking. > > That probably works on a small network. Try it with several thousand > servers and 200,000 users, not counting internet customers. Or try it > with an ISP, where you can't control the configuration on ANY of the > users' computers. > > I've worked in both situations. Firewalls are a godsend. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
