The document presents a comprehensive overview of the evolution of firewalls and network filtering over the past 25 years, starting from host-based firewalls in the 1990s to next-generation and cloud-based solutions. It discusses significant developments in firewall technology, including stateful inspection, zone-based firewalls, and application awareness, along with their advantages and challenges. The current trend highlights the shift towards virtualized and cloud environments, emphasizing the importance of host-based firewalls in dynamic cloud settings.

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