1. Central Management of 300 Firewalls and Access-Lists Fabian Mauchle fabian.mauchle@switch.ch TNC 2012 Reykjavík, 21-May-2012

2. © 2012 SWITCH Outline WHY Router Access Lists versus Stateful Firewalls The Judgment of Solomon HOW Basic Concept Pitfalls of Local Firewalls Building Blocks Experiences 2

3. © 2012 SWITCH 3 Access Lists vs. Stateful Firewalls How to protect SWITCH’s IT infrastructure from attacks from the Internet? Are static IP access lists in the routers good enough? Are stateful firewalls needed?

4. © 2012 SWITCH 4 Access Lists Up till recently SWITCH only used static router ACL –stateless –outgoing connections generally open –incomingTCP connection forbidden, except what is explicitly needed –incoming UDP connections: a few well-known ports open where required –incoming UDP packets protocol ports ≥ 1024 allowed, Features –simple, but limited in its capabilities –excellent performance and stability, –IPv6 support

5. © 2012 SWITCH Access Lists 5

6. © 2012 SWITCH Firewalls can do better Stateful firewalls dynamically open and close ports based on the state of each TCP connection or UDP conversation –not all UPD high port need to be permanently open Features –better (stateful) handling of UDP traffic –better control in case of fragmented packets –sophisticated logging –deep packet inspection But also: –potential bottleneck –single point of failure –… and redundancy is hard to configure and maintain 6

7. © 2012 SWITCH Network people and PERT staff hate firewalls: –can introduce hard to diagnose problems  IP multicast, IP fragments, path MTU discovery  still buggy IPv6 support –difficult to deploy in a redundant configuration –performance issues Security people love them: –state-of-the-art protection –central point to monitor and log traffic –ability to filter on payload –independence (separation of power) Network Security;-) 7

8. © 2012 SWITCH Judgement of Solomon protection of the office: –wide range of equipment –every employee can have root access on his computer –guidelines for the employees (patched, disk encryption) protection of the servers: –well managed (patched, software only installed when needed) –only few people have root access –goal: maximum availability and performance 8

9. © 2012 SWITCH Judgment of Solomon protection of the office: protection of the servers: 9 => static access lists in the routers => plus a stateful firewall on every server but no firewall in the network =>separate IP subnets for the different departments and teams =>a central, stateful, redundant firewall state-of-the-art

10. © 2012 SWITCH Outline WHY Router Access Lists versus Statefule Firewalls The Judgment of Solomon HOW Basic Concept Pitfalls of Local Firewalls Building Blocks Experiences 10

11. © 2012 SWITCH Basic Concept for Server Security 11

12. © 2012 SWITCH Basic Concept for Server Security 12 reinforce every host (local firewall) reduce resources on router

13. © 2012 SWITCH High Level View 13 Internet 41 ACLs 372+ + Server or VM

14. © 2012 SWITCH Advantages Stateful firewall Protection within subnet 2 nd line of defense High scalability –Virtually no performance impact –Scales with number of hosts –No central performance bottleneck –No bandwidth limitation No state synchronization required –multipathing and asymmetric traffic possible 14

15. © 2012 SWITCH Performance of Local Firewall 15 CPU Network firewall activated on Aug. 28. 2011 Example: dione.switch.ch aka switch.dl.sourceforge.net

16. © 2012 SWITCH Pitfalls of a Local Firewall Requires rules on router and local firewall Local connections (localhost) Connections between hosts (on the same subnet) –Seldom used connections Heterogeneous environments (different firewall impl.) 16

17. © 2012 SWITCH Cavari How to manage 300+ firewalls? Web interfaced Full IPv6 capable Use existing information (DNS, Server Management) Request based policy management Simple rollback Platform support for –Cisco IOS ACL –Linux iptables –Solaris ipfilter 17

18. © 2012 SWITCH Building Blocks 18 FirewallBuilder Compilers Cavari Web Application Install Scripts DNS Host DB New Tool (SWITCH) Existing Open Source Existing Tool (SWITCH) Existing Tool (SWITCH)

19. © 2012 SWITCH Mechanics Define allowed connections –source, destination, service (protocol, port) Use network topology to determine firewall rules Optimize rules on each firewall –remove duplicate entries and redundant more specifics 19

20. © 2012 SWITCH Experiences Stable operation since end of 2011 Good user acceptance –Let users (admins) view actual rules! Update IP addresses from DNS is very useful Migration takes time –Start with logging to find unknown communication Central logging facility is crucial Hosts without firewall –Extended set of rule on the router (as before) 20

21. © 2012 SWITCH Future Work Add Support for Mac OSX maybe Windows … Audit procedure 21

22. © 2012 SWITCH Questions 22