Here we are with our second installment of network security horror stories and having already discuss some of the firewall change control issues
in this article we’re going to review some firewall misconfigurations
I’ve seen at client sites. The firewall plays an important part in your
security architecture and needs to be configured properly in order to
gain the most from this layer of security. Here are a few stories of
classic firewall misconfigurations:
1. Dangerous Ports Open
2. Remote Control Gone Wrong
1. Dangerous Ports Open
There was a particular network I worked
in once that was constantly being breached. We started looking at ways
the attackers were gaining access and noticed that there were improperly
configured firewall rules that allowed full NetBios access to all
systems in the DMZ. These webservers were also running all applications
as administrator with an old version of Microsoft IIS.
After cleaning up the firewall access
rules, removing unneeded services and updating vulnerable software we
were able to help the network owners for the time being. There should be
a constant audit of your environment as well as vulnerability scans
both internally and externally that would find this low hanging fruit.
Using tools that point out vulnerabilities and areas that you’re not
compliant are extremely beneficial to your security posture.
2. Remote Control Gone Wrong
Once while troubleshooting a server
outage of a critical server I noticed that the firewall was previously
configured to have these servers put in a group that allowed RDP access
to them through the firewall and they were NAT’d directly into the
server VLAN, which wasn’t in the DMZ. This allowed attackers to gain
access directly through the firewall, bypass the DMZ and used this box
as a pivot point in the server VLAN.
Noticing this I confronted the firewall
and server administrator as to why this was configured this way. Their
response was that this is how the vendor came in to perform maintenance
on the server when it crashed. Little did they know that it wasn’t only
the vendor that was using this access and that the server wasn’t only
crashing, but it was compromised. Using other tools like Webex or
GoToMeeting would be a safer and easier method to troubleshoot issues
over the web.
Read the rest of the article at Algosec.com blog: http://blog.algosec.com/2012/09/network-security-horror-stories-firewall-misconfigurations.html
No comments:
Post a Comment