The first commercial firewall shipped in 1992. 25 years later the firewall is still the core building block of enterprises’ security infrastructures. Please join Prof. Avishai Wool, AlgoSec’s CTO, for an educational webinar on the history of the firewall. He will take you through a riveting 25-year journey of the evolution of the firewall - from the ancient world of the host-based firewalls of the 90s, to today’s cloud-based firewalls, and will explain how each type of firewall works, its advantages and limitations, and provide some tips and best practices for effective network filtering. In this highly informational, and entertaining webinar Professor Wool will cover: • The Early 90s: Host vs. Network • Late 90s: Keeping State • 2003: Zone-Based firewalls • 2010: Next-Gen firewalls • 2015: Virtualized and cloud firewalls

1. FROM ANTIQUITY TO THE CLOUD:
25 YEARS OF FIREWALLS AND
NETWORK FILTERING
Prof. Avishai Wool

2. WELCOME
Have a question? Submit it to the Chat
This webinar is being recorded!
Slides and recording will be sent to you within 7 days
2

3. AGENDA
• Host- versus Network- firewalls (early 1990s)
• Keeping State (late 1990s)
• Zone-Based firewalls (2003)
• Next-Gen firewalls (2010)
• Virtualized and cloud firewalls (2015)
3

4. Host- versus Network- Firewalls
Circa 1990

5. THE ANCIENT WORLD: HOST-BASED FIREWALL
• A host-based firewall is software running on a server or workstation.
Controls access to (and also from) a single computer.
• The earliest firewalls (1990s) were host-based
• For many years considered to be insufficient for enterprises
• Now making a comeback in virtualized environments
• Public / Private cloud
Examples (2018):
• Linux: iptables / netfilter
• Windows: Windows Firewall (Microsoft) / ZoneAlarm (Check Point)
5

6. HOST-BASED FIREWALLS
6

7. PROPERTIES OF HOST-BASED FIREWALLS
• Connecting program (client) can be known
• Rules say “from ME to somewhere” / “from somewhere to ME”
Advantages:
• Rules work without change on any host (“my” IP address not listed in rule)
• Better granularity: filter based on program
Disadvantages:
• If attacker can take over the host – can (often) turn off the firewall
• Requires root / administrator privileges
• Historically, policy was (usually) not centrally managed
• Central policy requires homogenous devices, remote update capabilities
• Not a real concern any longer
7

8. NETWORK FIREWALLS
• Placed in the network path (as a router)
• Force all traffic to go through it
• Policy managed by IT / Security staff
• Main workhorse for enterprises for the last 30 years
• Connecting program (client) not reliably known
and more…
8

9. NETWORK FIREWALLS: BASIC TOPOLOGY
Firewall
Philosophy:
• “hard crunchy outside – soft chewy inside”
• “Untrusted outside – trusted inside”
9

10. SEMI-TRUSTED: TOPOLOGY WITH DMZ
DMZ: DeMilitarized Zone
Network segment for
semi-trusted systems
10

11. A FIREWALL CAN HAVE MULTIPLE SIDES
11

12. Keeping State
Circa 1995

13. ANCIENT WORLD: STATELESS PACKET FILTERS
• Every packet is filtered on its own
• Firewall does not “remember state of the connection”
• Still in use in routers (e.g., Cisco IOS / Nexus, Juniper, …)
• But TCP traffic is bi-directional:
• ClientServer: s-port = rand, d-port=80
• ServerClient: s-port = 80, d-port=rand
13

14. PROBLEM #1 WITH STATELESS PACKET FILTERS
Suppose we want to allow browsing to anywhere
• Requires 2 stateless rules:
• Allow ClientAny when s-port=any, d-port=80,
• Allow AnyClient when s-port=80, d-port=any
• Insecure!
• Attacker can select source-port to non-random value!
• Can send packets to all services by setting s-port=80
14

15. PROBLEM #2: PERFORMANCE
• A network firewall has many rules
• Including monsters with 20,000 – 50,000 rules !
• 1Gbps = approx 1M packets per second
• Each packet needs to be compared to all rules
• Slow comparisons can become a serious bottleneck
15

16. STATEFUL INSPECTION IN FIREWALLS
• Invented & Patented by Gil Shwed
• US patent 5,606,668, 1993
• Shwed co-founded Check Point,
• serves as CEO to this day
• Productized by Check Point “FireWall 1”, 1994
• Simple & brilliant idea
• Solves both security and (parts of) performance problems
16

17. HOW STATEFUL INSPECTION WORKS #1
• Put only the ClientServer rule in the policy
• Allow ClientAny when s-port=any, d-port=80
• Filtering based on the reliable d-port
• 1st (SYN) packet seen by firewall:
• Clients1, with s-port=3777, d-port=80
• store “(Client, s1, 3777, 80)” in a state table
• E.g., use a hash table data structure
17

18. HOW STATEFUL INSPECTION WORKS #2
Algorithm when receive packet (s, d, s-port, d-port)
// Fast path
If ( “(s, d, s-port, d-port)” in state table, or
“(d, s, d-port, s-port)” in state table ) : Allow
// Slow Path
Else if SYN packet
check “(s, d, s-port, d-port)” against rules
If decision is Allow: Allow, and store in state table
Else Block
18

19. HOW STATEFUL INSPECTION WORKS #2
Performance:
Assume N rules, M connections. Lookup time:
Fast Path: O(1) // with good (M)-size state table data structure
Slow Path: O(N) // Naïve data structure
• Extremely effective on long TCP connections
• Less effective with short connections
Security
• “pinhole” for return traffic of a specific connection
• Much more secure than stateless
Management: need only 50% of rules
19

20. Zone-Based Firewalls
Circa 2003

21. WHAT ARE THE RULES ATTACHED TO?
Early vendors (started circa 1990):
• One policy (Check Point): Same policy for all traffic directions
• Easiest for administrators to manage
• Limitations against “spoofing” (packets arriving from wrong side)
• Policy per interface (Cisco)
Later vendors (from circa 2003):
• Separate set of rules for each pair of interfaces
• Zone-based policy
• Pioneered by Netscreen – then in SRX, Fortinet, Palo Alto, …
21

22. “Next Generation” Firewalls
Circa 2010

23. APPLICATION AWARENESS
• Traditional firewalls filter based on IP addresses and ports.
• Choice of port is a convention
• Developer can pick any port – so can malware developer
• Result: many applications, benign or evil, use
• tcp/80 (HTTP) or udp/53 (DNS)
• … because firewalls allow these ports broadly
23

24. NEXT GEN – IDEA #1
• Use “deep packet inspection” (DPI) to identify application
• Consider additional features in the packet besides TCP headers:
• Strings inside the packet
• … or missing strings (like missing HTTP or DNS headers)
• Known (suspicious) dns names
• … and more
• Classify a connection: tag it as an “Application” (“Mirai C&C”)
• Allow administrators to write rules based on the Application tag
• Pioneered by Palo Alto, Check Point a close 2nd
24

25. USER AWARENESS
• Humans move around campus with laptop/tablet/smartphone
• Their devices’ IP addresses change
• Can we enforce a policy that is tied to the user – not the IP?
• Allow administrators to write rules with “user=JohnDoe”
• Policy “follows the user around”
• A host-based firewall can easily achieve this –
• … Challenge for network firewalls
25

26. NEXT GEN – IDEA #2
• When SYN packet arrives, with a source IP
• firewall discovers who is currently logged at that IP
• Via organization’s LDAP
• Via NAC
• Via WiFi access point
• … or other technologies
• Firewall then applies rules that match the user
• Implicit assumption: a single human is logged in
• Pioneered by Palo Alto, Check Point a close 2nd
26

27. NEXT GEN FIREWALLS - OPINION
• Application-awareness is fairly popular
• Palo Alto, Check Point
• More secure to allow “Application=DNS” than “Service=udp/53”
• Legitimate DNS allowed, fake applications will be blocked
• Potentially makes administration more complicated
• (more granular rules)
• Potentially a performance bottleneck
• Value decreased when malware uses encryption
• User Awareness – less popular, challenging to deploy successfully
• Homogenous environment (same OS, same authentication mechanisms,…)
27

28. Virtualization & Cloud
circa 2015

29. VIRTUALIZATION
• Support from Intel hardware
• Run a “computer inside a computer” // many computers inside a computer
• “Guest”/”VM” inside the “host”
• Hypervisor software:
• Commercial: VMware, Hyper-V (Microsoft)
• Open Source: Xen, KVM
• VM has virtual CPU (compute), disk (storage) – and networking
• A virtual network can live inside the hypervisor
• A virtual network can connect to other networks (virtual or physical)
29

30. HYPERVISOR-LEVEL FILTERING
• The hypervisor “sees” all network traffic into and out of each VM
• So it can enforce filtering
• Result: embed a firewall in the network fabric
• Traditional firewall vendors have all virtualized their solutions
• … to the various virtualization platforms
• Plus - New wave of specialized products (2010+):
• VMware NSX, Cisco ACI, Amazon AWS, Microsoft Azure, Google Cloud …
30

31. WHO OWNS THE HYPERVISOR?
Enterprise owns the hypervisor:
• “Private Cloud”
• Software-Defined Networking (SDN) / Software-Defined Data Center
(SDDC)
• Usually use commercial hypervisor (VMware, Hyper-V)
• Open source attempt: OpenStack
IaaS (Infrastructure as a Service) provider owns the hypervisor:
• “Public Cloud”
• Usually use open source: e.g., AWS uses Xen, now switching to KVM
• (avoid license fees; have staff and knowhow to manage the solution)
31

32. HOST-BASED FIREWALLS MAKE A COMEBACK
• Dynamic (elastic) cloud environments: servers go up & down
• Static IP address assignment to servers – undesirable
• How to write firewall rules?
Solution: host-based rules!
• Rules say “from ME to somewhere” / “from somewhere to ME”
• Independent of server IP
32

33. HOST-BASED FIREWALLS IN THE CLOUD/SDN
• Crucial capability: central management
• Easier than in the past – homogenous environments
• 3rd party platforms: Dome9, Illumio, Cisco Tetration
• Use host-based firewalls – e.g., iptables – with custom management system
• Enforcement inside the VM
• Hypervisor platforms: AWS, Azure (Microsoft), Google, NSX
• Enforcement inside the hypervisor
33

34. LIMITATIONS AND PROPERTIES
• “If attacker can take over the host – can (often) turn off the firewall”
• Still true for 3rd party platforms
• Not true on hypervisor platforms – attacker needs access to platform too
• Is it an evolutionary step forward?
• Very basic capabilities – like firewalls of the 1990’s
• No “next gen”
• (almost) no network-object groups, no service-object groups
• Severely limited capacity: e.g., 50-200 rules per security-group on AWS
34

35. DEPLOYMENT TRENDS IN ENTERPRISES
Hybrid estates!
• Public cloud:
• hypervisor firewalls inside cloud (“can’t beat the price”)
• virtualized traditional firewalls on borders
• Private cloud:
• hypervisor firewall for “east-west” filtering / “microsegmentation”
• traditional firewalls for “north-south” filtering and high-security zones
35

36. UPCOMING WEBINARS
HTTPS://WWW.ALGOSEC.COM/WEBINARS/
Upcoming Webinars
• Topic: Intent based networking:
turning intentions into reality with
network security policy
management
When: Tuesday, April 24
Presented by: Edy Almer, VP Products
• Topic: Agility vs. Control: The
Security Policy Management
Balancing Act
When: Tuesday, May 15
Presented by: Anner Kushnir, VP
Technologies
OnDemand Webinars
---Sign up now on Brightalk!---

37. BE OUR FRIEND
Follow us for the latest on security policy management trends, tips &
tricks, thought leadership, fun stuff and prizes, and much more!
And subscribe to our YouTube channel for a wide range of educational
videos presented by Prof. Wool
www.linkedin.com/company/algosec
www.facebook.com/AlgoSec
www.youtube.com/user/AlgoSec
www.twitter.com/algosec
blog.algosec.com

38. AlgoSummit World Tour 2018
AlgoSummit EMEA 2018
The premier event for AlgoSec
customers and channel partners
Barcelona, May 4-7, 2018
For more info: https://www.algosec.com/algosummit/

39. Thank you!
Questions can be emailed to
marketing@algosec.com