>Subject: Re: 3k attack risks, Encryption, Linemode Telnet >Date: 9 Mar 1995 08:16:51 GMT >Organization: Hewlett Packard >Eric Schubert ([log in to unmask]) wrote: >: Well, the next question is...how can VT be firewalled? Does anyone have >: VT firewalled anywhere? My guess is that the firewall would require >: purchase of an HP9000 so that a proxy can come off of this machine using the >: VT3k software? >- Wouldn't the best firewall be a router? Sure there are routers one can > configure to allow certain services to pass and others to drop dead. > Any host that one can log-on is questionable as a firewall. The > assumption is that a hacker can always logon to a system. What if > there is no system? Just a router that will not accept connections to it > from outside world although from inside one could telnet in and manage it. Yes, this is good. In fact, that is how our HP3000 router is configured. The trouble starts when your "inside" network has holes in it. Put one machine on the inside network without this router protection (it could be a "harmless" network printing service), well flush security down the drain. The hacker simply breaks into a local machine and uses that machine to attack from the inside. > What I'm getting at is that no matter whether there's a 9000 or whatever > machine as a firewall, if someone succeeds to logon to it, the security > is history at that point. The machine is in your internal net as well > and can now open a connection to any machine. A 'box' that one cannot > logon has the best chance of being a good firewall - it only does IP > routing of selected IP fragments. It gets back to a closed network is a secure network (well, secure from the outside attackers!) Yes, but what if you WANT to give internet access...Your choice is to firewall it with a machine that can be closely monitored. A good detection program and packet monitors are in order. Also, if your logon into the firewall machine uses a one time password scheme, maybe this will secure it well enough. I think you are assuming traditional (unchanging) host password files. >- Firewalling VT would be the same than any other service - just disable > connections to port #1537 (with the firewall 'box' whatever that is) > and you're done. Admitted, you cannot do this with just a plain hp3000 > today - it's all or nothing. When/if inetd security comes to hp3000, all > NS services should make use of it and that ought to be really easy. > DSDAD controls all incoming NS servers and thus there's only one central > point that needs to change. Eero, you're on the right track. The first and utmost strategy to security is to localize and centralize the access points, then cook up good detection monitors and such. Another thing. People tend to argue about security using absolute terms, and this is where the trouble begins. There are only DEGREES of security and responses to attacks. For instance, take your statement "if the firewall machine is cracked into then it's no good." Well, that may be true, but if this is the only access point into your 3k and you have alarms, bells and packet monitors and such (the DMZ to the 3k) in the access paths, then it is a good trade off. A recent advertisement for hand held authenticators quoted a study that said: 80% to 97% of compromised systems go undetected. I tend to believe this. Detection is not possible when your access system is flawed or worst yet, there IS NO plan of detection. You assume the logon password will do it married to an LDEV. Well, those days are over connecting to an unsecured network. Well, you say, I'll just use the IP Address and User name, that should do it. right? Wrong! packet spoofing will get around this approach. You might keep out the teenager, but the real cracker will tie you in knots. I read the book "Firewalls and Internet Security - repelling the Wily hacker, William Cheswick and Steven Bellovin" and currently engaged in a project to evaluate strategies of securing our 3k machines. Let me tell you, there are no simple answers. These guys work for ATT&T and designed AT&T's firewall systems for Internet access. They have good ideas. It is important when talking about host security issues that absolute phrases are not expressed. Absolute statements, like "secure network" are oxymoronic phrases. Security can only be expressed in degrees of scale, not absolutes. Contrary to some opinions, the authors of this book believe highly secure networks are possible by isolating a sub-network using firewalls. "HIGH DEGREE OF SECURITY" meaning that the connecting user is really who they say they are and that services are delivered according to computer policy. Now think about this core principle of security: "If the user is really who they say they are." Traditional passwords over an unsecured network are pretty much useless to meet this requirement. A better method is to move into some sort of hand held authenticator that produces a unique password every time. This approach immediately removes the farse of using passwords over an unsecured network. Then again, you must believe your data is valuable enough to protect to this degree. If not, then use passwords. This is just the surface. Like I said, security is a matter of degrees - related to how valuable your data on our machine is to the mission of the organization. Life on the 'net is not your DTC environment. If you try to apply your DTC security approaches to an unsecured network, you are going to loose it. A different mindset must be employed. >: VT messages. mmmmm. Using a sniffer you can probably figure what the VT >: handshake is about, or maybe turn on the trace of some TCP stacks with >: NS/open would dump it. I was wondering if VT had "secret" responses of >: something along encryption lines, you don't believe it is so. It's just a >: matter of figuring out the proper response to VT messages to roll your own >: VT client? >- I guess it can be done... but oh boy wouldn't it be tough! By just watching > the traffic I guess one can get to the logon - and of course the trace would > reveal the passwords - logon as well. However, making it a well working > one... hmmm.. lot's of grey hair. VT messages contain several fields > that indicate different success/failure/etc statuses and those could > mess one up pretty bad. Anyway, I guess the point is to logon - well, > a trace of almost any non-encrypted traffic allows one to do it no matter > what protocols are in use. Well, the easy approach is to crack into a box with NS/open installed and steal it! or grab a copy of "hpterm" floating around 9k's. If we flood our campus with NS/open clients, how long will it take before someone cracks into a unsecured host and steals a copy? >:-) Eero Laurila - HP CSY Networking lab. -------------------------------------------------------------------- Eric J. Schubert Administrative Information Services Senior Data Base Analyst University of Notre Dame, IN USA Email: [log in to unmask] World Wide Web: http://www.nd.edu/~eschuber