1 / 37

Building Network Firewalls

Building Network Firewalls. Jason Testart, Computer Science Computing Facility. Topics in this Session. TCP/IP Primer Types of Firewalls Client-only network: Example Rulesets CSCF Firewall Open Source solution to high availability and high performance. Internet Protocol.

kiona
Download Presentation

Building Network Firewalls

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Building Network Firewalls Jason Testart, Computer Science Computing Facility

  2. Topics in this Session • TCP/IP Primer • Types of Firewalls • Client-only network: Example Rulesets • CSCF Firewall • Open Source solution to high availability and high performance WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  3. Internet Protocol • Network layer protocol • Traffic directed between machines by routers • Addresses are 32-bits long, split up into four 8-bit chunks, seperated by a “.” • Networks are determined by netmasks (eg. 129.97.0.0/255.255.0.0) • For addressing, IP header contains source IP address and destination IP address WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  4. IP Addressing (Networks) • 10.0.0.0/8 is the same as 10.0.0.0/255.0.0.0 = 10.*.*.* • 129.97.0.0/16 is the same as 129.97.0.0/255.255.0.0 = 129.97.*.* • 129.97.15.0/24 is the same as 129.97.15.0/255.255.255.0 = 129.97.15.* • 129.97.128.10/32 is the same as 129.97.128.10/255.255.255.255 = 129.97.128.10 WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  5. Transport Protocols • TCP and UDP are most common • Transmission Control Protocol (TCP) is connection oriented and reliable (eg. HTTP, SSH, Telnet) • User Datagram Protocol (UDP) is connectionless and unreliable (eg. DNS, Xbox Live) • Addressing consists of source port and destination port • Port number is in the range 1-65535 WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  6. Privileged ports (1-1023) Most Operating systems won’t let just anyone bind to privileged ports Notice most “servers” are on privileged ports? Ephemeral ports (typically 1024-65535) Ports that clients bind to when talking to servers Ephemeral port range varies from OS to OS and may be customized More about ports http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  7. TCP Flags There are several flags (bits) in the TCP header. We care about: • SYN • ACK • FIN • RST WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  8. TCP Connection (simplified) Client Host (port 33000) Server Host (port 80) SYN =1 SYN=1, ACK=1 ACK=1 ACK=1 Either side can end connection with a FIN packet WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  9. RST TCP Flag • RST flag is used if something goes wrong with the connection • If a client tries to connect to a port on a server where there is no process bound, the server sends the client a RST packet WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  10. “Backwards” TCP Protocols • X11 (port 6000) – the server actually runs on the client machine. The “client” is the program that you run on the remote host. • Ident (port 113) – aka Auth – When you the client connect to a service on a server, that service may try to connect to port 113 on your machine and ask: What user is bound to ephemeral port X? WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  11. Internet Control Message Protocol Has message types and message codes Common examples: Type 8, code 0 – echo request Type 0, code 0 – echo reply Type 3, code 1 – host unreachable Type 3, code 3 – port unreachable (UDP) ICMP WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  12. Types of Firewalls • Simple packet filters • Stateful packet filters • Application firewalls • Intrusion Prevention systems Most firewalls are stateful packet filters WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  13. Filter traffic based on source IP address and port, and destination IP address and port You need a rule for each direction of traffic for any given protocol Examples include: Switch ACLs Windows 2000 IPSec filters ipchains (Linux) Simple Packet Filters WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  14. Filter traffic based on source IP address and port, and destination IP address and port “Remember” the first packet, allow remaining packets of the connection through Cheat for UDP since the protocol has no concept of state Examples include: Most commercial firewalls iptables (Linux) ipfilter (*BSD/Solaris 10) ipfw (FreeBSD/Darwin) pf (OpenBSD) Windows XP ICF Stateful Packet Filters WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  15. How do we “remember” packets? • Memory is in the form of a state table, where each entry represents a connection. • Firewall first checks to see if a TCP packet belongs to a connection in the state table. • If not in state table, evaluate the packet against the ruleset (sanity check – SYN =1, ACK=0) • If allowed, an entry representing that TCP connection is added to a state table • With UDP, we look at src/dest IPAddr/ports and timing and hope for the best WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  16. Application Firewalls • Analyse the payload of each packet, looking for nasty content • Behaves like a proxy server • Many commercial firewalls offer HTTP and SMTP application filtering • Limited to those protocols understood by the firewall • Needs lots of CPU for processing WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  17. Intrusion Prevention Systems • Like Intrusion Detection Systems, look at all traffic for known attack signatures • Block traffic based on attacks/certain behaviours • Latest products focus on dealing with worms • Open Source implementation (snort-inline) uses snort with hooks into iptables • Relatively new technology – false positives can be a problem • Lots of CPU needed on busy networks WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  18. Sample Firewall Ruleset(client-only network) • Want to protect some PCs • Allow arbitrary outbound traffic • Clients need to be able to FTP, to download stuff! • Want to allow X11 traffic on campus • Inbound ping is OK • Won’t worry about anti-spoofing rules • Ignore rules involving the firewall itself WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  19. Active FTP (older Windows IE) Client makes control connection to port 21 Client picks an ephemeral port for data connection and tells server Server initiates connection from port 20 to client’s ephemeral port Passive FTP Client makes control connection to port 21 Server picks an ephemeral port for the data connection and tells the client Client initiates connection to server on ephemeral port FTPA difficult protocol to firewall Active FTP is difficult to firewall on the client side. Passive FTP is difficult to firewall on the server side. WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  20. Client-Only Networkipchains ruleset ipchains -p input deny ipchains -p forward accept ipchains -p output accept ipchains -A input -p tcp -i $ExtIF -s 129.97.0.0/16 -d $clientnet 6000 -j accept ipchains -A input -p tcp -i $ExtIF -s 0/0 -d $clientnet 113 -j reject ipchains -A input -p tcp -i $ExtIF -s 0/0 20 -d $clientnet 1024:65535 -j accept ipchains -A input -p udp -i $ExtIF -d $clientnet -j accept ipchains -A input -p icmp -i $ExtIF -d 0/0 0 3 8 -j accept Can you find the holes? WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  21. Client-Only Networkiptables ruleset iptables -p forward drop iptables -A forward -p tcp -i $IntIF -s $clientnet -d 0/0 -m state \ --state NEW,ESTABLISHED -j accept iptables -A forward -p udp -i $IntIF -s $clientnet -d 0/0 -m state \ --state NEW,ESTABLISHED -j accept iptables -A forward -p icmp -i $IntIF -s $clientnet -d 0/0 -m state \ --state NEW,ESTABLED,RELATED -j accept iptables -A forward -p tcp -i $ExtIF -s 129.97.0.0/16 -d $clientnet --dport 6000 \ -m state NEW -j accept iptables -A forward -p tcp -i $ExtIF -s 0/0 -d $clientnet -dport 113 \ -j reject --reject-with tcp-reset iptables -A forward -p tcp -i $ExtIF -s 0/0 --sport 20 -d $clientnet -m state \ --state ESTABLISHED,RELATED -j accept WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  22. Client-Only Networkiptables ruleset (continued) iptables -A forward -p tcp -i $ExtIF -s 0/0 -d $clientnet -m state \ --state ESTABLISHED -j accept iptables -A forward -p udp -i $ExtIF -s 0/0 -d $clientnet -m state \ --state ESTABLISHED -j accept iptables -A forward -i $ExtIF -p icmp --icmp-type 3 -s 0/0 --d $clientnet –m state \ --state NEW,ESTABLISHED,RELATED Did you understand that? WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  23. Client-Only Networkipfw ruleset ipfw add 10 check-state ipfw add 20 allow tcp from any 20 to $clientnet 1024-65535 \ keep-state ipfw add 30 reset tcp from any to $clientnet 113 ipfw add 40 deny tcp from any to $clientnet established ipfw add 50 allow ip from $clientnet to any keep-state ipfw add 60 allow tcp from 129.97.0.0/16 to $clientnet 6000 \ setup keep-state ipfw add 70 allow icmp from any to $clientnet icmptype 8 keep-state ipfw add 65534 deny any to any Rule 20 is really a stateless hack to allow active FTP. The keep-state is there for efficiency. Easy to read, eh? WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  24. Client-Only Networkpf ruleset (ipfilter like syntax) OpenBSD pf uses a config file (/etc/pf.conf) for the ruleset: rdr on $IntIF proto tcp from $clientnet to any port 21 -> 127.0.0.1 port 8021 pass in on $IntIF inet from $clientnet to any keep state block in on $ExtIF any to any pass in on $ExtIF inet proto tcp from any port = 20 to ($ExtIF) \ port > 49150 keep state pass in on $ExtIF inet proto icmp from any to $clientnet \ icmp-type echoreq keep state pass in on $ExtIF inet proto tcp from 129.97.0.0/16 to $clientnet \ port = 6000 keep state block return-rst in on $ExtIF inet proto tcp from any to $clientnet port = 113 Short and sweet (and secure) WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  25. More about pf • The redirect (rdr) rule redirects FTP traffic to an FTPproxy running from inetd on the firewall itself. In /etc/inetd.conf you’ll find the entry: • 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy • After editing the ruleset in /etc/pf.conf, run:pfctl –f /etc/pf.confto reload the ruleset. • pf implicitly looks at the state table before the ruleset WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  26. Firewall Requirements for Computer Science • Need to ensure that performance is not negatively impacted • We want to make things secure as possible for those machines under our control • Researchers need the ability to choose the level of protection they want • Deploying new technology takes time • Don’t want a single point of failure WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  27. Netscreen 500 • Gig Firewall Appliance (ASIC) • Interfaces support redundant connections • Stateful packet filtering • HTTPS/SSH mgmt interfaces • Supports the concept of security zones; each zone contains one or more subnets. We can define policies for traffic between zones. • Two devices can be put in Active/Active failover mode WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  28. Logical Network Diagram DCCoreNet 129.97.16.17 129.97.16.19 UnTrust FirewallCluster VSD 0 VSD 1 Trust 129.97.51.1 129.97.49.1 … 129.97.84.1 129.97.15.1 … Protected subnets aremanually balanced between twovirtual security devices (VSDs). CS Networks WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  29. Simplified Physical Connection Diagram exsw08 exsw18 IST (MC) Firewall 1 VSD0 master VSD1 slave Firewall 2 VSD1 master VSD0 slave X-over cables IST (Eng) Future connection VLAN Trunk (CS Nets) exsw19 Eng switches Non-CS/Untrusted Nets WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  30. More about the Netscreens • Any configuration change made to one firewall is propagated to the other within seconds • X-over cables are 100/fdx – used for managing the cluster (exchanging state info, heartbeat, alternate data path, etc...) • Definining policies is quite simple, via a web-based management interface. • When defining policies, need to be careful that ALL zones are considered! WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  31. Where we are with deployment • Teaching hosts are mostly divided correctly into proper subnets; ready for placing in security zones • Co-op student spent most of summer auditing and removing unused hostnames from non-teaching subnets – more work to be done in assigning hosts to zones • Teaching subnets to be moved behind firewall before 2005. It was supposed to be done in August 2004 but… WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  32. My life suddenly changed My son Alex was born two months early. WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  33. Firewall Performace Considerations • State table lookups are fast – need RAM • Minimize number of rules • OpenBSD pf supports a “quick” keyword – if packet matches rule, then stop processing. Rule ordering becomes important. • Minimize number of daemons running on firewall box • Obvious things like CPU, NIC, etc… • But what if that P4 3.8 Ghz just isn’t fast enough? WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  34. Get a second firewall!You’ll have to worry about… • Load balancing • Asymetric routing • state table synchronization • Multiple single points of failure • Management of multiple firewalls (configs, etc…) WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  35. OpenBSD Solution:pfsync and CARP • Functionality released in Spring 2004(OpenBSD 3.5) • CARP – Common Address Redundancy Protocol • CARP has an “arpbalance” feature for load balancing • Pfsync – a virtual network interface for exchanging state table info (dedicated NIC recommended) • http://www.countersiege.com/doc/pfsync-carp • http://www.openbsd.org/cgi-bin/man.cgi WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  36. If money was no object… Alteon Switched Firewall (ASF) • Two devices: Director (PC running CheckPoint) and Accelerator (appliance) • Scales to 6 Directors and 2 Accelerators • Up to 4.2 Gbps throughput, 500K sessions at wire-speed, 20K-100K connections per second • Rules evaluated by director, states managed by accelerator WatITis | Supporting UW’s Mission Through I.T. | December 7, 2004 | Building Network Firewalls

  37. The End Thanks for coming!

More Related