With our latest network revision we are focusing more on network security and lowering the amount of unprotected and unsecured ports. Some ports you can not help but open like your FTP and HTTP which are inherently internet facing. There are things that can be done to tweak the underlying daemon to be more secure though. Also other modules and encrypted versions of the protocols exist that use secure certificates and algorithms to obscure the data being transfered between hosts. For instance HTTPS uses certificates to establish secure methods of communications between client browsers and Web servers. The certificates are used mainly to encrypt HTTP requests for banking sites, web based emails, and other web based resources.
We have grown to accustomed to opening ports for various services like camera servers, a/c controllers, and odd port HTTP services. Our goal is to have less ports opened for internet facing services. Now hackers can still jump on to an incoming stream to exploit any vulnerabilities on the other side. For now we are working on edge based security by implementing other tools like Intrusion Detection and Prevention Systems (IDS/IPS) like Snort. Snort can be used as an add-on to routers with a package based system like PFSense which is what we use, installed as a daemon on a server that is turned into a router, or as an outside server configured with port mirroring monitoring the traffic transparently.
So as the first step to minimizing our surface for attack is to use a VPN tunnel to control/manage servers behind the firewall as opposed to opening a port. Even remote management of firewalls is a security risk. For example dd-wrt was a victim of an attack on its web based management tool when accessible from the internet. A work around to this would be to use a VPN connection or a system behind the firewall to manage the firewall. Though remote control protocols are always targeted, especially RDP on the well known port 3389. We choose to use IPSec for our VPN this time around instead of OpenVPN or PPTP (which only works for a while if at all). We didn’t feel like messing with CAs and Keys this time around but may be implemented later on if we choose too. We are still researching any vulnerabilities with IPSec as configured along with best practices for this setup on our development network. Yes, we test things before deploying it in the wild. It gives us time to learn and figure out the best method for implementing services like VPNs or Networking topologies.
So far I like it. Using Schrewoft’s IPSec client and PFSense I get to the web management GUI and it works with my redundant firewalls We just have to reconnect when one goes down. We will be testing the ability to reach other devices later on when we added more boxes to the network. We like the speed even over wireless from Bellsouth to Comcast. We will be testing data transmission speeds also when more boxes are added since a basic webpage isn’t a great test for the speed of connections.
So to summarize, no more swiss cheese firewalls, all open holes are monitored and flagged if suspicious traffic is discovered, and management is done over encrypted tunnels instead internet facing management GUIs that may be vulnerable. We will be doing more of this in future deployments of any network we roll out.