Security Incidents mailing list archives
Eggshell security (was Re: indirect doorway to network via mobile remote access stations)
From: John Pettitt <jpp () CLOUDVIEW COM>
Date: Wed, 9 Aug 2000 14:08:21 -0700
This is a good example of a bigger issue - "eggshell security" (hard outer shell but a soft runny middle). Once the shell is breached the game is effectively over. Wandering laptops are not the only source of non approved and/or hostile software. Users still bring in CD's and floppy disks from home. Outside vendors and other visitors plug into the LAN. Service tech's load and run software that has been run on countless other machines with debatable security. The only real answer here is to compartmentalize everything and treat all machines as potentially hostile. One immediate step is to severely limit what traffic is permitted peer to peer inside the net (it helps a lot if all users are switched). Another good idea is to lock down unused switch ports and control which mac addresses are allowed on which ports (prevents unauthorized machines being on the net). The first principle here is "All that is not expressly permitted is denied". All of this is much harder to do than just putting up a firewall and claiming to be secure. John
--Insert Standard Disclaimer Here-- (I am sending this email from a different domain not to draw attention to the affected domain, please respond to <A HREF="mailto:incidents () securityfocus com">incidents () securityfocus com</A>) We have WinNT 4.0 sp4 (laptop) stations accessing the internal network in three ways: 1. Directly connected RJ45 to the internal LANs 2. Remotely connected PPP Dialup (w/ SecurID) to the internal LANs 3. Remotely connected PPTP Tunnel (w/ SecurID) through the Internet, to the internal LANs - There is a firewall protecting the internal LANs/WANs from number 2 and 3 (remotely connected). - There is an anti-virus software running on the servers and the stations. - There is no firewall between the corporate resources and the LANs/WANs. Our problem is with number 3 (remotely connected via the Internet). - On one station whose anti-virus was not up to date, we found a virus trying to contact IRC servers. - We have discovered other stations that are scanning the network on udp port 161 (snmp). We have yet to investigate this one, so we do not know yet what software is doing this, however, we've eliminated known (enterprise standardized) software. Scenario: When the stations are brought 'on the road', they are used to access the internal network via a VPN. First they must establish a connection with a local ISP, then they connect to our VPN servers. The entire duration of their 'Internet' connection, they are only protected by an anti-virus software. Of course the information traveling on the VPN is (more) secure, but the station itself is vulnerable to network scans and attacks. The anti-virus software cannot help with the scans, and might be of assistance with the copying or executing of know viral content. However, this leaves the stations quite open to 'newer' attacks that may be unknown to the anti-virus software. If the station becomes compromised, information contained within that station, or transacted over the VPN are not safe. Problem: Our concern is that when the station is brought back on site, and directly connected to the internal network, undetected viral software is then free to roam and discover our LANs/WANs. This information could then be gathered later when the station returns on the Internet. (Of course, the affected station could also simply perform various attacks onto our corporate resources.) We consider this a 'time-differentiated security whole' into our internal network. We are currently evaluating three avenues: 1. Impose a firewall policy on the stations, 2. Impose an access policy on the internal routers (this only limits the damage) 3. impose a security policy on the servers (and other corporate resources) Number two and three are a matter of cost/benefit analysis. However, if we do not secure the stations themselves, there will always be a risk of invasion. We have contacted our firewall manufacturer for information on products that would answer our specific need, but we were told that they did not offer solutions in the 'personal firewall' market. Their focus is on 'enterprise-level' solutions. (Well, we consider this to be an 'enterprise-level' problem.) We have evaluated 'personal firewall' products that are available on the Internet. Most of them are not adequate for our needs as they require either knowledge and/or interaction on the part of the user for the purpose of decision making. We have retained one product so far as being a 'close call', but there are issues where deployment is concerned. Also, a great deal of effort will have to be made on our part to attempt to secure it in the case where the anti-virus software didn't 'catch' a user's action which would result in infection. (This product is 'ConSeal PC Firewall' from www.signal9.com.) Conclusion: What we seek from the community are insight, info, ideas or experiences with products or solutions that may help with our problem. Yours truly, Frank.
John Pettitt <jpp () cloudview com> AOL-IM: CanisRosa SigInt bait ;-) A big hello to the folks at Fort Meade, Menwith Hill and Pine Gap. Keywords: NSA, Echelon, GCHQ, F83, Magnum, Mentor, P415, STEEPLEBUSH
Current thread:
- Re: indirect doorway to network via mobile remote access stations Tinberg, Mark (Aug 09)
- Eggshell security (was Re: indirect doorway to network via mobile remote access stations) John Pettitt (Aug 10)