donderdag 24 april 2014

Test Results: Default Firewall

Like my previous blogpost, I will discuss some of my findings during my tests of IPv6 networks where the systems have their default firewalls enabled. The same OS's will be tested with the same attacks. These tests are made so we can have an insight at how well networks would handle attacks once the perimiter firewalls or IDS is bypassed. Note that these tests work with the assumption of an IT administrator that just left the default values as they were in the firewall regarding IPv6. The IPv4 part of the firewall can very well be adequatly protected.

Another thing to note is that most Linux OS's do not have any default rules whatsoever. Linux distributions work with IP tables. On the distributions I tested, these allowed everything. One more point of interest is Windows XP. Since it does not support IPv6 natively and had to be installed, by default no firewall rules were in place for the IPv6 network. This is adjusted since Service Pack 2 where IPv6 firewall rules are grouped under IPv4 firewall rules. This means that traffic that both IP's use will be subject to these firewall rules while the others will not. E.g. Echo Request and Responses (pings) will be blocked since both IPv4 and IPv6 make use of them. RA, RS, NA and NS messages on the other hand will not be blocked.

UNIX

Scanning

FreeBSD uses the ipfw (IP firewall) which is not enabled by default, but can be enabled with some default firewall rules in place. Most rules allow traffic on the local level but not on the global level. For scanning this is the most interesting path anyway. There are two rules however that only allow some ICMPv6 type messages to get through on the global level. These being 1,2, 135, 136. This means that for our scanning tests, the scans failed. None of the scan tests tested managed to find the FreeBSD Host

DoS

Since the DoS attacks work both on the global as the local level, none of the DoS were effectively blocked.

MITM

The NA and redirect MITM attacks did fail this time around since the redirect I tested used global addresses. Normally NA MITM should be successful but as this is a local MITM attack, and the firewall only allows the packets with a global address through, this attack also failed.

LINUX

As stated previously in Linux distributions no real default rules are added. The IP tables let all traffic through by default.

WINDOWS

Scanning

As expected, just like with the IPv4 firewall rules, all Echo Request/Response packets are blocked by the default firewall. So all the ping scan tests failed. On the portscan however, Windows 7, 2008 and 2012 still had ports open. (port 5357)

DoS

No Windows system actively blocked one of the DoS attacks. This can be verified by looking at the firewall rules, where the inbound rules state that almost all ICMPv6 traffic (except for pings) is allowed through.

MITM

Same as with the DoS attacks, no system actively blocked more MITM attacks then they already did (or didn't).

Conclusion

While Linux systems generally handle IPv6 traffic a little better than Microsoft systems (e.g. during floods), their default allow-all rules obviously did not help in these set of tests. Of course one can argue that most IT administrators that use Linux distributions generally know what they are doing and would not leave the "default" firewall rules (in this case IP tables) the same.

FreeBSD did very well on this test, with the pleasant surprise of at least some form of IPv6 rules that made some attacks impossible. Still Floods can be the most disruptive (and hard to deflect) attacks, these all still worked.

Microsoft had no real surprises other than that they blocked pings. Almost all other ICMPv6 traffic was allowed through making the effort of blocking the pings obsolete.

In general it is safe to say decent firewall rules are not widely used yet because IPv6 is not as common as IPv4 yet. One can argue however, that those who make the transition to IPv6 (or use dualstack) generally know what they are doing and at least implement some basic firewall rules

Geen opmerkingen:

Een reactie posten