A 10G Bouncer for your Network Server Ports

We’ve all been to an exclusive club where we may have been denied entry because we weren’t on “the list.”  Does your server have a “list?” It should.

Friday the Department of Homeland Security informed us that over 1,000 US business have been hit by a new hacker tool called “Backoff.” UPS it seems got the most negative press on this one, and “Backoff” had ONLY compromised 1% of their US stores, 51 in total. Reporting the cyber break in made nationwide news on Friday.  So this week UPS is the new face of cyber victims, for the time being replacing Target who suffered an estimated $2.5B loss due to a similar incident last winter.

Unlike Target, which started with weak security on an HVAC system, UPS was hit by a very sophisticated piece of software called “Backoff.” This hacker tool contains a key logger, memory scraping (yes it crawls through memory looking for userids, passwords, system names, credit card info, etc…) and it plays several cute tricks to immunize itself from removal. So how do you minimize & possibly eliminate your servers from being hit by “Backoff?” One method would be to install a white list based security firewall in your server, essentially putting a bouncer on your server’s network port.

This network server bouncer would then only let systems enter your server that come in from places on the list, and they would only be allowed in via communications ports they were pre-approved for. In other words, say you have a web server on an internal address of 10.0.0.77 and you’ve configured it to talk to your database server on port 7940.  Your database server also has this network server bouncer running, and he’s using a whitelist that says: allow 10.0.0.77:7940.  Now suppose your web server was hacked the only possible way the attacker could jump from the web server to the database server would be through port 7940.  All the other ports: telnet, ssh, ftp, etc… from 10.0.0.77 don’t exist, those paths from the web server to the database server are unavailable to the attacker because they aren’t on the whitelist. To actually get into the database server the attacker would have to communicate as if he were a database server himself because that is all the database server will permit on port 7940.  Also remember that HVAC server that brought down Target, it wouldn’t be on the list at all to access any of your core business servers so the sideways attack Target experienced would be impossible.  Your data, on these servers at least, would be considerably more secure.

Taking this one step further, as the admin you could then use this whitelist capability on each ethernet server port to logically wire together your infrastructure such that only systems, and admin workstations that should talk with each other on predetermined, acceptable, ports can. A typical web server might have a whitelist that contains a pool of database servers, on a fixed set of ports, a management server or two, also talking on a different set of permitted ports, and a management workstation or few that also can only communicate over a very narrow band of ports. This would all be enforced in the network server adapter’s hardware that was executing the white list, being the bouncer, so ANY attempted access is stopped before it reaches the operating system.

Does such a magical network server bouncer with a white list on his clipboard exist today, yes.  It’s SolarSecure running on Solarflare’s Flareon network server adapters. With it you can specify a list of acceptable individual IP addresses or ranges of IP addresses that can communicate with a server on a given ethernet interface.  You can then filter off all communications on unapproved ports, in a second layer of filtering.  To learn more post something here, or drop me an email.

Leave a Reply