Firewalls and VPNs Chapter 7 Introduction to Advanced Firewall Terminology

1
Firewalls and VPNsChapter 7Introduction to
Advanced Firewall Terminology

• Dr. Richard W. Tibbs
• Edward B. Oakes

2
Chapter 7 Objectives

• Use advanced firewall concepts and terminology,
  including rules, policies, chains.
• Manage iptables/netfilter using the iptables
  command line utility.
• Implement rules, policies, and blacklisting in
  Shorewall.
• Recognize the uses of stateful and stateless
  rules in a LEAF firewall.
• Take advantage of LEAF firewall services
  available on the internal network.

3
IPTables

• iptables L chain
• iptables L chain n
• iptables L chain n -v
• iptables L chain n -line-numbers

4
IPTables

• iptables -L net2fw
• Chain net2fw (1 references)
• target prot opt source destination
  
• ACCEPT all -- anywhere anywhere state
  RELATED,ESTABLISHED
• ACCEPT tcp -- 192.168.2.99 anywhere tcp
  dptssh
• ACCEPT tcp -- 192.168.2.28 anywhere tcp
  dptssh
• ACCEPT icmp -- anywhere anywhere icmp
  echo-request
• ACCEPT tcp -- 192.168.2.99 anywhere tcp
  dptwww
• ACCEPT tcp -- 192.168.2.28 anywhere tcp
  dptwww
• net2all all -- anywhere anywhere

5
A Definition of a Rule

• a specification
• of some combination of protocol, IP address, and
  TCP or UDP header information that identifies a
  class of packets
• a target,
• which can be a direct action or a reference to
  another set of rules
• optionally,
• the state of a connection
• optionally,
• the content of a packet

6
Stateful Rules TCP State

• Iptables rules support state information by the
  characteristics
• new,
• established,
• related, and
• invalid.

7
New

• The new characteristic refers to a new
  connection. How would iptables determine whether
  a connection is new or established? New TCP
  connections get an initial sequence number (ISN)
  by generating a random number and setting the SYN
  bit in the TCP header. It is easy for a firewall
  to use the TCP header information to detect new
  versus established TCP connections.

8
Established

• The established characteristic refers to an
  existing connection. For TCP, this would be a
  sequence of TCP headers with no SYN or FIN bits
  set. TCP uses sequence numbers to establish the
  order of TCP segments. Since sequence numbers
  should be increasing for each successive segment,
  it is possible to predict the next sequence
  number in an established TCP connection.

9
Related

• The related characteristic is the case where two
  or more connections are associated with a single
  application.
• For example File Transfer Protocol (FTP) uses two
  TCP connectionsport numbers 20 for data transfer
  and 21 for requests (i.e., the control channel).
• Another example of related TCP connections is Web
  server design. To increase responsiveness,
  multiple TCP connections are opened from a single
  Web page hit, perhaps transferring each image
  with an individual TCP connection.
• How would a firewall detect these connections are
  related?
• They would all bear the same source and
  destination IP addresses.
• In the case of FTP, the well known ports 20 and
  21 should be found for one end of each
  connection.
• In the case of Web pages, the multiple
  connections should all have well-known port 80
  directed toward the web server application.

10
Invalid

• Finally, the invalid characteristic matches any
  invalid combination of TCP flags. Several
  combinations of TCP flags are invalid. A few of
  these are
• SYN and FIN bits set in the same header
• SYN and RST
• ACK and RST
• In another such combination all flags are set.
  This is invalid due to the cases cited above.
  This type of TCP header is sometimes called the
  Christmas Tree attack.

11
RFCs 1948 and 1337

• TCP Sequence numbers need protection
• If they can be predicted, TCP connections can be
  hijacked.
• The method of determining sequence number in RFC
  793 was too simple

12
RFC 793
Initial Sequence Numbers To avoid confusion we
must prevent segments from one incarnation of a
connection from being used while the same
sequence numbers may still be present in the
network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all
knowledge of the sequence numbers it has been
using. When new connections are created, an
initial sequence number (ISN) generator is
employed which selects a new 32-bit ISN. The
generator is bound to a (possibly fictitious)
32-bit clock whose low order bit is incremented
roughly every 4 microseconds. Thus, the ISN
cycles approximately every 4.55 hours. Since we
assume that segments will stay in the network no
more than the Maximum Segment Lifetime (MSL) and
that the MSL is less than 4.55 hours we can
reasonably assume that ISN's will be unique.
13
RFC 793

• The idea expressed in RFC 793 is to allow initial
  sequence numbers for new connections to be
  generated by the approximately four microsecond
  updates of the system clock.
• This translates into 250,000 increments each
  second. A new connection arising at some random
  time in any second therefore obtains an
  approximately random initial sequence number.
• However, this has an obvious flaw as described in
  RFC 1948 (Bellovin, 1996), confirmed by others,
  which allows a hacker to guess the next sequence
  number.

14
RFC 1948

• Most systems including Linux have implemented RFC
  1948 and segmented the ISN numbers across the
  32-bit ISN range to insure that the ISN from one
  connection yields little or no information about
  the ISN for another connection.

15
RFC 1337

• Most systems implement RFC 1337
• However, it may be necessary to modify a file in
  the directory /proc/sys/net/ipv4. This directory
  contains several files and one of these is files
  is tcp_syncookies, which if set to the single
  character 0 indicates RFC 1337 is not to be
  implemented.
• By issuing the following command you can turn on
  RFC 1337 effects
• echo 1 gt tcp_syncookies
• You will have to reboot after this command, or
  issue the command
• /etc/rc.d/init.d/network restart

16
What is a SYN cookie?

• The feature that guarantees immunity from SYN
  floods relates to the common internet term
  cookie. A cookie is most commonly associated
  with web servers making practical improvements to
  the experience of client computers using web
  browsers.
• According to the Computer Incident Advisory
  Capability (CIAC, http//www.ciac.org/ciac/bulleti
  ns/i-034.shtml)
• Cookies are short pieces of data used by web
  servers to help identify web users. The popular
  concepts and rumors about what a cookie can do
  has reached almost mystical proportions,
  frightening users and worrying their managers.

17
SYN Cookies contd

• On the other hand, the SYN flood attack has been
  observed since 1996 by CERT (http//www.cert.org/a
  dvisories/CA-1996-21.html).
• A number of commercial firewalls, including
  Cisco, Checkpoint and other products used SYN
  cookies as a means of defeating SYN floods.

18
SYN Cookies contd

• Let us pose this question
• How would a single web server, say amazon.com,
  uniquely identify each web client, considering a
  single user may have multiple web browsers open
  at any time, or multiple users may be connected
  through a Network Address Translation (NAT)
  device?

19
SYN Cookies contd

• The solution to this problem is to produce a
  small, fixed length item called a cookie that
  takes a variable amount of information, at a
  minimum
• The Web Servers IP address and well-known port
  number.
• The client web browsers IP address and ephemeral
  port number.
• Optionally, for e-commerce support, a user
  password, e.g. to support online banking or
  access to credit card account information.

20
SYN Cookies contd

• The reader should recognize these items as the
  requirements for a hash function.
• That is in fact what cookies are, some unique way
  to identify a particular user.
• One of the benefits of cookies is that the user,
• if authenticated to online banking,
• does not have to re-authenticate on every new web
  page.

21
Cookies are for Web servers

• but how would they help defeat SYN flood
  attacks?
• SYN flood scenario
• By repeating many times, server is exhausted of
  resources.
• If the client is an attacker and never sends the
  final ACK to complete the three-way handshake,
  then the result is the so-called half-open
  connection.
• If the server waits sometimes as long as 5
  minutes while allocating the TCB, memory
  resources will eventually fill to capacity.
• This results in denial of service.

Client Server SYN, ISN
-----------------------? (server receives
SYN) (client receives SYN,ACK)
?------------------- (SYN, ACK, ISN) (Never
sends final ACK) Server waits
22
SYN Cookies

• SYN cookies are and idea generated by Daniel J.
  Bernstein and Eric Schenk at the University of
  Toronto in 1996
• (see the email correspondence at
  http//cr.yp.to/syncookies/archive).
• This was in response to incidents of SYN flooding
  in the early 1990s.
• By the late 1990s the problem was essentially
  solved.
• The final result in most operating systems was
  the use of an MD5 hash function of the bulleted
  list below, including an arbitrary secret

• The Web Servers IP address and well-known port
  number.
• The client web browsers IP address and
  ephemeral port number.
• Optionally, for e-commerce support, a user
  password, e.g. to support online banking or
  access to credit card account information.

23
SYN Cookies Complete

• The way SYN cookies work is that the Server sends
  back a SYN,ACK,ISN using the hash function
  mentioned previously for the ISN.
• The server does not allocate TCB resources until
  the originating client ACKs to complete the three
  way handshake.
• The final ACK in the three-way handshake contains
  both ISNs, one from the client the ISN field,
  while the acknowledgment field of this ACK
  segment contains the servers ISN.
• Therefore, the server does not need to save any
  state information about the connection, since the
  server can reverse the MD5 hash and have all the
  state information necessary to set up the TCB.

24
Policies

• The iptables facility implements many additional
  actions, called targets, beyond accept, reject,
  and deny.
• Using the iptables command line, an example of a
  simple iptables command is
• iptables -P FORWARD DROP

25
Policy and Forward Chain

• The iptables L FORWARD command will allow you to
  view the existing FORWARD policy.
• iptables -L FORWARD
• Chain FORWARD (policy DROP)
• target prot opt source destination
  
• DROP !icmp -- anywhere anywhere
  state INVALID
• eth0_fwd all -- anywhere anywhere
  
• eth1_fwd all -- anywhere anywhere
  
• Reject all -- anywhere anywhere
  
• reject all -- anywhere anywhere

26
Chains

• A chain is a sequence of rules that is associated
  with a location in the packet filtering process
  shown in Figure 7.2.
• Chains are so named because they refer to a
  series of statements, such as iptables rules.
  Statements in a chain are order-dependent.
• A central concept in firewalls, as with router
  ACLs, is the first-matching rule concept,
• That is, the first rule (as created by an
  iptables command) that matches a packet will have
  the appropriate action or target applied.

27
Shorewall Policy File

• The source and destination columns in the figure
  are called zones. Each zone corresponds to a
  general area
• loc refers to the local network being protected
• net corresponds to the Internet
• vpn1 refers to a virtual private network
• all refers to all traffic.

28
Figure 7.1
29
LimitBurst
30
Figure 7.2 Linux with IPTABLES
31
Table 7.1

• Iptables table functions,
• chains,
• chain Functions
• and typical applications

32
Figure 7.3 /etc/shorewall/zone
33
Figure 7.4 The /etc/shorewall/interface file

• Related ZONEs to INTERFACEs
• Note norfc1918 option will block private IPs on
  that interface

34
Figure 7.5 Shorewall /etc/shorewall/rules file
35
Figure 7.5 Entries Explained

• For DNS to work with DNSCache
• ACCEPT fw net tcp 53
  
• ACCEPT fw net udp 53
• ACCEPT loc fw udp 53
  
• ACCEPT loc fw tcp 53
• Note Rules are NOT Transitive
• Therefore,
• accept loc fw TCP 53
• accept fw net TCP 53 does not mean
• accept loc net TCP 53

36
Fig. 7.5 Contd

• The target options in the Shorewall rules file
  are called actions and are slightly more
  limited than with the iptables command.
• The available targets are
• accept,
• drop,
• reject,
• redirect,
• dnat,
• continue and
• log.

37
Explaining DNAT

• Suppose you wanted to run Mail, Web, DNS or other
  servers inside your firewall?
• DNAT (Destination NAT) forwards packets from the
  NET to your public IP to your private IP inside
  the firewall.
• DNAT net loc192.168.1.2 tcp http
  
• DNAT net loc192.168.1.2 tcp imap
  
• DNAT net loc192.168.1.2 tcp smtp
  
• DNAT net loc192.168.1.2 tcp domain
  
• DNAT net loc192.168.1.2 udp domain

38
Figure 7.6 Stateful commands and command ordering

• For special cases.