The topology in Figure 15-1 serves as a basis for the labs in this chapter. This is a generic example featuring a five-interface firewall/NAT gateway, as follows:
-
The first interface is a special segment inhabited by protocols that cannot coexist with NAT.
-
The second interface features an Ethernet crossover link to a screening access router.
-
The third interface represents a demilitarized zone (DMZ) with RFC 1918 addresses.
-
Finally, two internal interfaces with RFC 1918 address pools complete the picture.
The assumption is that this setup serves a fairly large corporate network. Suppose, for example, we have acquired a /24 address block from our upstream ISP, either a provider aggregate or a PI address block (does not really matter). This prefix is routed toward the firewall. Likewise, the firewall defaults toward the access router, which by itself defaults to the upstream provider.
Note that Figure 15-1 demonstrates two different ways to dynamically map client requests to either an outside address pool (n:m) or a single interface address (n:1 = masquerading). The DMZ design offers great flexibility: 1:1 static mappings, port forwarding, and load balancing can be utilized in a combined fashion.
NAT gateways are an additional hop in an IP packet's path. Therefore, they alter the Time To Live (TTL). Depending on the implementation, NAT gateways always use the same pool of port numbers for multiplexing connections. These are either predetermined at compile time or can be altered via sysctl or user-space configuration such as with ipfilter (ipf). Therefore, if you want to better camouflage your NAT gateway, taking care of a good random distribution of multiplexing ports and an unaltered TTL does not leave an investigator much evidence to detect a NAT gateway.
On the other hand, if you are in the role of an auditor, look for patterns in the high-port range for evidence of NAT conversion. Usually NAT is an integrated function of modern commercial or open-source firewalls, so do not reveal the existence of a firewall by politely rejecting packets by returning ICMP information; instead, just silently discard probes and attacks. The less information you reveal, the more difficult it is for attackers to gather useful information to penetrate defenses. Also keep in mind that the checksum of several headers has to be recomputed by the NAT gateway.
Lab 15-1: OpenBSD ipfilter
This lab (as detailed in Example 15-1) features a masquerading n:1 mapping scenario commonly found in small office/home office (SOHO) broadband and dial-up scenarios, for which a subscriber gets only one address from the service provider. The external addresses of SOHO devices such as broadband routers usually are deployed via Dynamic Host Configuration Protocol (DHCP). DHCP serves internal segments or VLANs, too.
Therefore, it is recommended that you use interface descriptors or shell variables rather than IP addresses in firewall/NAT configuration files wherever possible. You will also find examples for many-to-many configurations (NAT pools), port relaying, application proxies, and load balancing in this configuration (comments inline).
Example 15-1. OpenBSD ipfilter (ipf) NAT Configuration
[root@ganymed:~#] cat /etc/ipnat.rules
#########################################################################
# NAT/PAT Generic Configuration #
# Gernot Schmied, March 2003 #
# This configuration example assumes that the network is 20.20.20.0/24. #
#########################################################################
# #
# To get information, try "ipnat -lsv" #
# Manually start via "ipnat -CF -f /etc/ipnat.rules" #
# To clear and flush, try "ipnat -CF" #
# #
#########################################################################
#OUTSIDE="ne5"
#INSIDE ="ne3"
#DMZ ="ne4"
#NONAT ="ne2"
################################################################
### application proxies (always place before portmap rules!) ###
################################################################
# active ftp #
map ne5 192.168.1.0/24 -> ne5/32 proxy port ftp ftp/tcp
map ne5 192.168.2.0/24 -> ne5/32 proxy port ftp ftp/tcp
# H.323 proxy support #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 1720 h323/tcp
# RealAudio #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 7070 raudio/tcp
# IPsec Proxy #
map ne5 192.168.1.0/24 -> ne5/32 proxy port 500 ipsec/udp
#######################################
### dynamic NAT (many-to-one = n:1) ###
#######################################
map ne5 192.168.1.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> ne5/32 # for ICMP
map ne5 192.168.2.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> ne5/32 # for ICMP
map ne5 192.168.14.0/24 -> ne5/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> ne5/32 # for ICMP
# alternative #
#map ne5 192.168.1.0/24 -> ne5/32 portmap tcp/udp auto
#map ne5 192.168.1.0/24 -> ne5/32 # for ICMP
###################################################
### working with NAT pools (many-to-many = n:m) ###
###################################################
#map ne5 192.168.7.0/24 -> 20.20.20.0/24 portmap tcp/udp 60000:65535
#map ne5 192.168.7.0/24 -> 20.20.20.0/24
# exclude from NAT pool #
#map-block ne5 192.168.2.18/32 -> 20.20.20.0/24 ports 64
###############################################
### static NAT entries (one-to-one = bimap) ###
###############################################
# Do not forget to set static routes when necessary
# e.g. "route add 211.11.117.65 192.168.2.65"
# There is no need to manually establish corresponding static ARP entries;
# however, in combination with some ill-behaving access devices,
# this is always a nice workaround.
# e.g. "arp -s 211.11.117.65 00:d0:ba:4c:a5:c0"
#bimap ne5 211.11.117.65/32 -> 192.168.2.65/32
# or alternatively #
# bimap ne5 211.11.117.64/27 -> 192.168.2.64/27
#######################################
### NAT Load Balancer (round-robin) ###
#######################################
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.3 port 8000 tcp round-robin
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.4 port 8000 tcp round-robin
#rdr ne5 211.111.111.2/32 port 80 -> 192.168.2.5 port 8000 tcp round-robin
Example 15-2 presents status information of the NAT configuration of Example 15-1 in action.
Example 15-2. OpenBSD NAT Operation Output
[root@ganymed:~#] ipnat -l
List of active MAP/Redirect filters:
map ne5 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> 0.0.0.0/32
map ne5 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> 0.0.0.0/32
map ne5 192.168.14.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> 0.0.0.0/32
List of active sessions:
MAP 192.168.1.1 34240 <- -> 211.111.111.2 61761 [195.34.133.149 80]
MAP 192.168.1.1 34239 <- -> 211.111.111.2 61760 [213.229.60.9 80]
MAP 192.168.1.1 34238 <- -> 211.111.111.2 61759 [138.22.167.21 80]
MAP 192.168.1.1 34237 <- -> 211.111.111.2 61758 [205.156.51.200 80]
MAP 192.168.1.1 34236 <- -> 211.111.111.2 61757 [213.229.60.100 110]
MAP 192.168.1.1 34235 <- -> 211.111.111.2 61756 [213.229.60.100 110]
MAP 192.168.1.1 34234 <- -> 211.111.111.2 61755 [213.229.60.100 110]
MAP 192.168.1.1 34233 <- -> 211.111.111.2 61754 [213.229.60.100 110]
MAP 192.168.1.1 34232 <- -> 211.111.111.2 61753 [213.46.255.2 110]
MAP 192.168.1.1 32895 <- -> 211.111.111.2 61752 [195.34.133.10 53]
MAP 192.168.1.1 32894 <- -> 211.111.111.2 61751 [195.34.133.10 53]
MAP 192.168.1.1 32893 <- -> 211.111.111.2 61745 [195.34.133.10 53]
MAP 192.168.1.1 32892 <- -> 211.111.111.2 61744 [195.34.133.10 53]
MAP 192.168.1.1 32890 <- -> 211.111.111.2 61738 [195.34.133.10 53]
MAP 192.168.1.1 32889 <- -> 211.111.111.2 61737 [195.34.133.10 53]
MAP 192.168.1.1 32888 <- -> 211.111.111.2 61731 [195.34.133.10 53]
[root@ganymed:~#] ipnat -lv
List of active MAP/Redirect filters:
map ne5 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.1.0/24 -> 0.0.0.0/32
map ne5 192.168.2.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.2.0/24 -> 0.0.0.0/32
map ne5 192.168.14.0/24 -> 0.0.0.0/32 portmap tcp/udp 60000:65535
map ne5 192.168.14.0/24 -> 0.0.0.0/32
List of active sessions:
MAP 192.168.1.1 34240 <- -> 211.111.111.2 61761 [195.34.133.149 80]
age 299 use 0 sumd 0xc586/0xc586 pr 6 bkt 0/60 flags 1
ifp ne5 bytes 5157 pkts 19
MAP 192.168.1.1 34239 <- -> 211.111.111.2 61760 [213.229.60.9 80]
age 299 use 0 sumd 0xc586/0xc586 pr 6 bkt 89/38 flags 1
ifp ne5 bytes 12208 pkts 27
MAP 192.168.1.1 34238 <- -> 211.111.111.2 61759 [138.22.167.21 80]
age 254 use 0 sumd 0xc586/0xc586 pr 6 bkt 46/122 flags 1
ifp ne5 bytes 2129 pkts 11
MAP 192.168.1.1 34237 <- -> 211.111.111.2 61758 [205.156.51.200 80]
age 255 use 0 sumd 0xc586/0xc586 pr 6 bkt 20/80 flags 1
ifp ne5 bytes 8635 pkts 33
MAP 192.168.1.1 34236 <- -> 211.111.111.2 61757 [213.229.60.100 110]
age 227 use 0 sumd 0xc586/0xc586 pr 6 bkt 100/49 flags 1
ifp ne5 bytes 1515 pkts 24
MAP 192.168.1.1 34235 <- -> 211.111.111.2 61756 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 98/47 flags 1
ifp ne5 bytes 1264 pkts 20
MAP 192.168.1.1 34234 <- -> 211.111.111.2 61755 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 96/45 flags 1
ifp ne5 bytes 2481 pkts 30
MAP 192.168.1.1 34233 <- -> 211.111.111.2 61754 [213.229.60.100 110]
age 226 use 0 sumd 0xc586/0xc586 pr 6 bkt 94/43 flags 1
ifp ne5 bytes 1280 pkts 20
MAP 192.168.1.1 34232 <- -> 211.111.111.2 61753 [213.46.255.2 110]
age 220 use 0 sumd 0xc586/0xc586 pr 6 bkt 75/24 flags 1
ifp ne5 bytes 1539 pkts 22
MAP 192.168.1.1 32895 <- -> 211.111.111.2 61752 [195.34.133.10 53]
age 992 use 0 sumd 0xcabe/0xcabe pr 17 bkt 93/32 flags 2
ifp ne5 bytes 1150 pkts 10
MAP 192.168.1.1 32894 <- -> 211.111.111.2 61751 [195.34.133.10 53]
age 940 use 0 sumd 0xcabe/0xcabe pr 17 bkt 91/30 flags 2
ifp ne5 bytes 198 pkts 2
MAP 192.168.1.1 32893 <- -> 211.111.111.2 61745 [195.34.133.10 53]
age 940 use 0 sumd 0xcab9/0xcab9 pr 17 bkt 89/18 flags 2
ifp ne5 bytes 480 pkts 4
MAP 192.168.1.1 32892 <- -> 211.111.111.2 61744 [195.34.133.10 53]
age 580 use 0 sumd 0xcab9/0xcab9 pr 17 bkt 87/16 flags 2
ifp ne5 bytes 198 pkts 2
MAP 192.168.1.1 32890 <- -> 211.111.111.2 61738 [195.34.133.10 53]
age 580 use 0 sumd 0xcab5/0xcab5 pr 17 bkt 83/4 flags 2
ifp ne5 bytes 464 pkts 4
MAP 192.168.1.1 32889 <- -> 211.111.111.2 61737 [195.34.133.10 53]
age 220 use 0 sumd 0xcab5/0xcab5 pr 17 bkt 81/2 flags 2
ifp ne5 bytes 182 pkts 2
MAP 192.168.1.1 32888 <- -> 211.111.111.2 61731 [195.34.133.10 53]
age 220 use 0 sumd 0xcab0/0xcab0 pr 17 bkt 79/117 flags 2
ifp ne5 bytes 464 pkts 4
List of active host mappings:
192.168.1.1 -> 0.0.0.0 (use = 16 hv = 32)
[root@ganymed:~#] ipnat -s
mapped in 34077 out 34425
added 1763 expired 1746
no memory 0 bad nat 0
inuse 17
rules 6
wilds 0
Lab 15-2: FreeBSD ipfw+natd
The user-space FreeBSD application natd(8) requires both the ipfw and the ipdivert sockets in the kernel configuration (options IPFIREWALL, options IPDIVERT). In addition, the following settings must be in /etc/rc.conf, as shown in Example 15-3).
Example 15-3. FreeBSD natd Requirements
gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="en5" # Indicates which interface to forward packets through
# (the interface connected to the Internet).
natd_flags=" –l –m –u –f /etc/natd.conf"
The FreeBSD natd supports traditional NAT and port/protocol/address redirection. Consult the man page natd(8) for further operational details. Example 15-4 presents a short example of port relaying.
Example 15-4. FreeBSD natd Example for Redirects
-redirect_port tcp 192.168.1.2:6667 6667
-redirect_port tcp 192.168.1.3:80 80
-redirect_port tcp 192.168.1.4:2000-3000 2000-3000
-redirect_address 192.168.1.2 128.1.1.2
-redirect_address 192.168.1.3 128.1.1.3
-redirect_proto encap 192.168.1.4
Lab 15-3: BSD Packet Filter (pf)
The pf packet filter is OpenBSD's native packet-inspection, stateful firewall, and NAT engine. It recently was ported to other BSD operating systems. Because it was inspired by ipfilter and works similarly, it is not discussed in detail here. For further information, consult the sources (especially the pf FAQ) in the "Recommended Reading" section at the end of this chapter.
Lab 15-4: Linux NAT (iptables)
The firewall/NAT engine for the 2.4 and 2.6 Linux kernels is iptables/netfilter. Because of the large number of features available, only a short example of IP masquerading on PPP links is presented in Example 15-5 (which is quoted from the iptables NAT tutorial).
Example 15-5. Linux iptables Masquerading Example
# Load the NAT module. (This pulls in all the others.)
modprobe iptable_nat
# In the NAT table (-t nat), append a rule (-A) after routing
# (POSTROUTING) for all packets going out ppp0 (-o ppp0), which says to
# masquerade the connection (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# Turn on IP forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward
NAT-Hostile Protocols
Because of their intrinsic operation, NAT gateways in the communication path of certain protocols might disturb their inner working. Good examples are H.323/SIP, FTP, end-to-end IPSec, and peer-to-peer applications. Unfortunately, these problems often are caused by inconsiderate application development and easily could have been avoided (RFC 3235, "Network Address Translator (NAT)—Friendly Application Design Guidelines"). In the case of H.323, this can be compensated easily by application level gateway (ALG) mappings of modern firewall engines (for example, Cisco PIX Firewall) or the use of H.323 gatekeepers/proxies.
Keep in mind that stateful NAT and stateful inspection firewall issues are related and often intertwined. Special pains are applications that use random ports.
0 comments:
Post a Comment