This is what we are up against as firewall administrators. Firewalls will have to be configured to allow some traffic to pass through it. Attackers will use these holes to attempt to gain unauthorized access to computers on your network. So why bother using firewalls at all?
Practice a layered approach to security, with firewalls being just one, albeit fundamental, role in your security strategy. They do stop a good number of attacks, and make out jobs more defined. For example when you open holes in your firewall pay special attention to which services and machines those hole correspond to. Patch those holes first, make certain your Intrusion Detection system is monitoring those services, and if you can help it make sure those services use secure protocols and strong authentication. Firewalls are just like other systems, they have security holes themselves, yet another reason why they should not be your first line of defense. By far the greatest downfall of firewalls is the human factor. When a firewall fails to do its job its most likely due to the firewall administrator not paying attention or not following the proper firewall guidelines. Always test the rules you put in place and audit your firewall rules on a regular basis, making sure that you are really blocking what you think you are blocking.
The DMS is a powerful concept when implemented correctly. Firewall collect a large amount of useful information and can provide an early warning service. Firewalls are targets just like your systems, and should be configured accordingly. Many management protocols are weak when it comes to security, and VPN is one way to counteract this.
The DMZ (or DeMilitarized zone) is a zone or area off of your firewall that is separate from your local network. Machines that need to communicate with the Internet (i.e. web servers, ftp servers) are usually placed here. There is a separate firewall policy that protects the DMZ.
Only allow the services that are required. This example is a pretty easy one, HTTP and HTTPS are used for web communications and run on TCP ports 80 and 443. Sometimes you may have to open an application to the Internet that is not well documented, making the task of determining which ports to open all that more difficult.
If your web server is compromised you don’t want it to start attacking your local network. The DMZ configuration allows you to contain the vulnerable servers, and prevent a compromise from spreading. Also, you must allow the local network to connect to the web server, using a secure protocol such as SSH.
This one may take some convincing of you developers and systems administrators. In all reality your web servers do not need to connect out to the Internet . If one becomes compromised the first thing an attacker is going to do is download some malicious code (root kit, backdoor, sniffer, etc..). You can prevent this by not letting you web server connect to the Internet. This makes patching a little more difficult. Patches must be downloaded by another system, then copied to the web server. Numerous attacks have been (and many could have been) prevented if this simple rule was in place.
Firewalls have the ability to provide valuable information in the form of logs. It is important to review these logs on a regular basis to see who is trying to penetrate your network and how. Portscanning is more than just noise. Many people ask after they have been compromised, “How did they find my server”. The answer is portscanning, so be aware of your environment and know what people are looking for. Certain rules provide more useful information, such as the rule that logs traffic from the DMZ to your network. This is a low traffic rule that should be monitored closely.
We have approximately 90mb/s of Internet bandwidth, with plans for more. We are scanned hundreds of times per day. The logs from just a few weeks of traffic contains over 30,000 packets. So how do we make this data work for use? If there is only time to secure one application this week, choose the one people are actively scanning for, not the one that has no known exploit. Zero-Day attacks happen, but it is more likely that you will be compromised with an older vulnerability. Sometime portscans are down right intrusive, so don’t be afraid to block them for a while (a few hours, a day, a week) until the scanning stops.
So where do we put our focus with regards to security? Hey, secure you web servers man And when that’s done lock down and patch those SQL servers and turn off NetBIOS.
If a server in the DMZ attempts to connect to the Internet, or even worse to your local network, you want to be notified ASAP. Email is a great way to do that.
Transcript of "powerpoint"
Firewall Tips & Tricks Paul Asadoorian Network Security Engineer Brown University November 20, 2002
Defense in Depth <ul><li>Firewalls mitigate risk </li></ul><ul><li>Blocking MOST threats </li></ul><ul><li>They have vulnerabilities as well </li></ul><ul><li>Improper configuration is the largest threat </li></ul>
Tips & Tricks Outline <ul><li>Using the “DMZ” to your advantage </li></ul><ul><li>Firewalls as Intrusion Detection devices </li></ul><ul><li>Configure VPN’s for management </li></ul>
The “DMZ” Configuration <ul><li>Separate area off the firewall </li></ul><ul><li>Usually a different subnet </li></ul><ul><li>Commonly used to house Internet facing machines (i.e. Web Servers) </li></ul><ul><li>Has its own firewall policy </li></ul>
The “DMZ” Configuration <ul><li>Place web servers in the “DMZ” network </li></ul><ul><li>Only allow web ports (TCP ports 80 and 443) </li></ul>
The “DMZ” Configuration <ul><li>Don’t allow web servers access to your network </li></ul><ul><li>Allow local network to manage web servers (SSH) </li></ul>
The DMZ Configuration <ul><li>Don’t allow servers to connect to the Internet </li></ul><ul><li>Patching is not convenient </li></ul>
Firewalls as IDS <ul><li>Collect log information from the deny rules </li></ul><ul><li>Find Portscanning, hacking attempts, etc… </li></ul><ul><li>Isolate traffic with deny rules helps cut down the information overload </li></ul>
Firewalls as IDS <ul><li>What to do with ALL that data…..Graph It! </li></ul><ul><li>Shows trends, what people are looking for </li></ul><ul><ul><li>Helps prioritize security tasks </li></ul></ul><ul><li>Occasionally you may want to block portscans </li></ul>
Firewalls as IDS Data collected from July – August 2002, Brown University Network
Firewalls as IDS Data collected from October – November 2002, Brown University Network
Firewall as IDS <ul><li>Pay close attention to traffic leaving DMZ </li></ul><ul><li>Often the first sign of a compromise </li></ul><ul><li>Low traffic rules, so logs aren’t as enormous </li></ul><ul><li>Email is nice, provided you’re the only one reading it </li></ul>
Firewalls as IDS <ul><li>Ways to accomplish alerting: </li></ul><ul><ul><li>Swatch </li></ul></ul><ul><ul><li>http://www.oit.ucsb.edu/~eta/swatch/ </li></ul></ul><ul><ul><li>Logsentry </li></ul></ul><ul><ul><ul><li>http://www.psionic.com/products/logsentry.html </li></ul></ul></ul><ul><ul><li>Alert.sh (Firewall-1) http:// www.enteract.com/~lspitz/intrusion.html </li></ul></ul>
Firewall as IDS <ul><li>Date: Wed, 31 Dec 1997 15:40:01 -0600 (CST) </li></ul><ul><li>From: [email_address] To: [email_address] </li></ul><ul><li>Subject: #### Firewall ALERT #### </li></ul><ul><li>You have received this message because someone is </li></ul><ul><li>potentially scanning your systems. The information </li></ul><ul><li>below is the packet that was denied and logged by </li></ul><ul><li>the Firewall. This is email alert number 3, with a </li></ul><ul><li>limit of 5 from evil.example.org. </li></ul><ul><li>----- CRITICAL INFORMATION ----- </li></ul><ul><li>Date: 31Dec1997 Time: 15:39:59 Source: evil.example.org </li></ul><ul><li>Destination: ns1 Service: domain-tcp </li></ul><ul><li>----- ACTUAL LOGENTRY ----- </li></ul><ul><li>31Dec1997 15:39:59 drop fw1 >elx0 mail proto tcp src </li></ul><ul><li>evil.example.org dst ns1 service domain-tcp s_port 37401 len 44 </li></ul><ul><li>rule 6 </li></ul>
Configuring VPN For Management <ul><li>VPN is far more secure than other management methods: </li></ul><ul><ul><li>SSL and SSH are vulnerable to Man-In-The Middle Attacks </li></ul></ul><ul><ul><li>Telnet and SNMP are clear text </li></ul></ul><ul><ul><li>There are no known MIM attacks against IPSEC (Yet) </li></ul></ul>
Configuring VPN For Management <ul><li>VPN clients are supported on most platforms </li></ul><ul><li>Most firewalls will work with most clients </li></ul><ul><li>Netscreen now officially supports FreeSwan </li></ul><ul><li>Mac OS X is now supporting VPN </li></ul>
Useful Links <ul><li>http://www.enteract.com/~lspitz/ - Lance Spitzner’s Web Site </li></ul><ul><li>http://rr.sans.org/firewall/blocking_ipchains.php - Guide to blocking ports </li></ul><ul><li>http://rr.sans.org/firewall/index.php - All sorts of good stuff </li></ul>
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.