Linux Firewalls: Attack Detection and Response with iptables, psad, and fwsnort
| A small or medium-size business might have reason to invest in a more elaborate firewall architecture. The remainder of the chapter focuses on a single example using the configuration from Figure 6.1, in which the DMZ sits between a dual-homed gateway firewall and an internal choke firewall. The gateway firewall separates both the DMZ and the LAN from the Internet. Its internal interface connects directly to the DMZ rather than to the private LAN. Public services are hosted from machines on the perimeter DMZ network, each with a separate bastion firewall and security policy of its own. The public servers may or may not have publicly visible interfaces, depending on how your public IP addresses are assigned. The choke firewall separates the DMZ from the LAN. Depending on the network hardware used in the DMZ, the traffic between the LAN and Internet may or may not "share a wire" with the DMZ. Unlike the firewall example in Chapter 4, this setup does not have a potential single point of failure. Services with different security policies can be hosted from different security zones within the internal networks. The main idea is to physically isolate the private LAN from the external gateway firewall machine through the use of an internal choke firewall. The perimeter network does not have to be a full network with its own servers; it's a conceptualization. The perimeter network could be implemented as simply as a crossover cable between the gateway's internal interface and the choke's external interface. Implementing a DMZ as a simple crossover cable might sound silly. It buys a small site two firewalls, just as a full perimeter network does. Two firewalls don't represent a single point of failure. Local LAN services are hosted on the choke machine or within the LAN itself rather than on the gateway host, and they are completely isolated from the gateway or the Internet. The setup in the remainder of the chapter uses a minimum of six sets of firewall rulesone each for the external and internal interfaces of both firewall machines, plus the forwarding rules on the two machines, which is where the bulk of the work is done. The conceptual difference between this example and the example in Chapter 4 is the addition of the DMZ perimeter networkthe new rules applied to the gateway's internal interface and to the choke firewall's external interface. On the detail level, the difference is also in the input and output rules because the gateway firewall offers no services itselfor a mere handful, at most. The forwarding rules for the two interfaces are mirror images of each other. Public servers on the DMZ network have their own individualized firewall rules as well. Public servers in the DMZ are usually specialized, dedicated, single-service machines. Their firewall rules are simple and highly restrictive to the particular services that they host. Additionally, the overhead of the antispoofing and high service port protection rules aren't needed because the gateway is providing this service. The choke firewall's symbolic constants and initial rules are largely identical to the gateway's. Because the gateway hosts no services, the input and output rules largely move to the FORWARD chain. The major emphasis of this chapter's example is on the choke's firewall rules and on the symmetry between the forwarding rules on the gateway and the choke. The example's rules will be very familiar by this point. For the most part, the rules from Chapter 4 are moving to the FORWARD chains on both firewalls. Symbolic Constants Used in the Firewall Examples
As with the firewall example in Chapter 4, the gateway's external interface is assigned to eth0, leading to the Internet. Just for the sake of confusion, I'm going to divide the address space. As shown in Table 6.4, the gateway's public interface remains with IP address 192.168.1.1.
The internal interface address will be 192.168.1.65 on etH1, leading to the perimeter DMZ network. The choke firewall machine's external interface address will be 192.168.1.126 on its eth0, leading to the perimeter DMZ network. The choke firewall machine's internal interface address will be 192.168.1.129 on etH1, leading to the private LAN. The address space available to the DMZ hosts is 192.168.1.66 to 192.168.1.125 because the DMZ will be in the 192.168.1.64/26 network. The broadcast address is 192.168.1.127. The address space available to the LAN hosts in the 192.168.1.128 network range is from 192.168.1.130 to 192.168.1.190. The broadcast address is 192.168.1.191. ADDITIONAL CONSTANTS FOR THE PUBLIC GATEWAY FIREWALL
The following constants are added to the gateway's firewall script to refer to the gateway's internal interface, the choke's IP address, and the network address block for the DMZ: DMZ_INTERFACE="eth1" # network interface to the DMZ DMZ_IPADDR="192.168.1.65" # DMZ IP address CHOKE_IPADDR="192.168.1.126" # choke firewall DMZ address DMZ_ADDRESSES="192.168.1.64/26" # DMZ IP address range DMZ_BROADCAST="192.168.1.127" # DMZ broadcast address LAN_ADDRESSES="192.169.1.128/26" # LAN IP address range LOCAL_ADDRESSES="192.168.1.0/24" # any local IP address
CONSTANTS FOR THE PRIVATE CHOKE FIREWALL
A firewall shell script is easier to read and maintain if symbolic constants are used for recurring names and addresses. The following constants either are used throughout the examples in this chapter or are universal constants defined in the networking standards: DMZ_INTERFACE="eth0" # network interface to the DMZ LAN_INTERFACE="eth1" # network interface to the LAN LOOPBACK_INTERFACE="lo" # however your system names it DMZ_IPADDR="192.168.1.126" # DMZ IP address GATEWAY_IPADDR="192.168.1.65" # gateway firewall - the router DMZ_ADDRESSES="192.168.1.64/26" # DMZ IP address range DMZ_NETWORK="192.168.1.64" # DMZ subnet base address DMZ_BROADCAST="192.168.1.127" # DMZ broadcast address LAN_IPADDR="192.168.1.129" # LAN IP address LAN_ADDRESSES="192.168.1.128/26" # LAN IP address range LAN_NETWORK="192.168.1.128" # DMZ subnet base address LAN_BROADCAST="192.168.1.191" # DMZ broadcast address LOOPBACK="127.0.0.0/8" # reserved loopback address range CLASS_A="10.0.0.0/8" # Class A private networks CLASS_B="172.16.0.0/12" # Class B private networks CLASS_C="192.168.0.0/16" # Class C private networks CLASS_D_MULTICAST="224.0.0.0/4" # Class D multicast addresses CLASS_E_RESERVED_NET="240.0.0.0/5" # Class E reserved addresses BROADCAST_src="/books/3/251/1/html/2/0.0.0.0" # broadcast source address BROADCAST_DEST="255.255.255.255" # broadcast destination address PRIVPORTS="0:1023" # well-known, privileged # port range UNPRIVPORTS="1024:65535" # unprivileged port range Constants not listed here are defined within the context of the specific rules that they are used with. Setting the Stage on the Choke Firewall
The following steps are identical to those in Chapter 4. The choke firewall's preamble is identical to the gateway's: # Enable broadcast echo Protection echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # Disable Source Routed Packets for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Enable TCP SYN Cookie Protection echo 1 > /proc/sys/net/ipv4/tcp_syncookies # Disable ICMP Redirect Acceptance for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done # Don't send Redirect Messages for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Drop Spoofed Packets coming in on an interface, which, if replied to, # would result in the reply going out a different interface. for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # Log packets with impossible addresses. for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
Removing Any Preexisting Rules from the Choke Firewall
The first thing to do when defining a set of filtering rules is to remove any existing rules from the rule chains. Otherwise, any new rules that you define will be added to the end of existing rules. Packets could easily match a preexisting rule before ever reaching the point in the chain you are defining from this point on. The following command flushes the rules of all three built-in filter table chainsINPUT, OUTPUT, and FORWARDat once. (User-defined chains are flushed, too, but none is used in this chapter.) This is the same as found on the gateway firewall built in previous chapters: # Flush any existing rules from all chains $IPT --flush $IPT -t nat --flush $IPT -t mangle --flush $IPT -X $IPT -t nat -X $IPT -t mangle -X
The chains are empty. You're starting from scratch. The system is in its default accept- everything policy state if the system has just booted. If the firewall is being reinitialized, the default policies are whatever they had been previously set to. Flushing the rules does not affect the default policies. Defining the Choke Firewall's Default Policy
The choke policy is to reject all traffic in either direction. To return an ICMP 3 error message, the REJECT target must be used. The easiest method is to end the chains with a general REJECT rule to catch anything that hasn't matched an ACCEPT rule. This results in meaningful error messages being delivered immediately, rather than forcing the local hosts to wait for a timeout. Note that this is different from the gateway's firewall where the default policy is to silently drop traffic using DROP. To create a known-good environment where the firewall script can be used to stop the firewall, the first default policy is to ACCEPT. This is the same policy setup as seen in previous chapters: $IPT --policy INPUT ACCEPT $IPT --policy OUTPUT ACCEPT $IPT --policy FORWARD ACCEPT $IPT -t nat --policy PREROUTING ACCEPT $IPT -t nat --policy OUTPUT ACCEPT $IPT -t nat --policy POSTROUTING ACCEPT $IPT -t mangle --policy PREROUTING ACCEPT $IPT -t mangle --policy OUTPUT ACCEPT Next, the bits to create the stop action are added. Again, these are the same as in previous chapters: if [ "$1" = "stop" ] then echo "Firewall completely stopped! WARNING: THIS HOST HAS NO FIREWALL RUNNING." exit 0 fi
Both firewalls drop or reject everything by default rather than accepting everything by default: # Set the default policy to reject on the choke firewall $IPT --policy INPUT REJECT $IPT --policy OUTPUT REJECT $IPT --policy FORWARD REJECT At this point, all network traffic is blocked. Enabling the Choke Machine's Loopback Interface
You need to enable unrestricted loopback traffic. This enables you to run any local network services that you choose, or that the system depends on, without having to worry about getting all the firewall rules specified: # Unlimited traffic on the loopback interface $IPT -A INPUT -i $LOOPBACK_INTERFACE -j ACCEPT $IPT -A OUTPUT -o $LOOPBACK_INTERFACE -j ACCEPT
Stealth Scans and TCP State Flags
Testing for common forms of TCP stealth scans is possible because iptables gives access to all the TCP state flags. The following rules block common stealth scan probes. None of the TCP state combinations tested for is a legal combination. Because specific interfaces aren't matched in the following input and forward rules, the rules apply to all interfaces. Again, the code is the same as for the gateway firewall: # All of the bits are cleared $IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP $IPT -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP # SYN and FIN are both set $IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP $IPT -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP # SYN and RST are both set $IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP $IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP # FIN and RST are both set $IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP $IPT -A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP # FIN is the only bit set, without the expected accompanying ACK $IPT -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP # PSH is the only bit set, without the expected accompanying ACK $IPT -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP # URG is the only bit set, without the expected accompanying ACK $IPT -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP
Using Connection State to Bypass Rule Checking
Specifying the state match for previously initiated and accepted exchanges enables you to bypass the firewall tests for the ongoing exchange. The initial client request remains controlled by the service's specific filters, however. The following code checks for established connections: $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Using the state module alone, INVALID will break protocols that use # bidirectional connections or multiple connections or exchanges, # unless an ALG is provided for the protocol. At this time, FTP is the # only protocol with ALG support. $IPT -A INPUT -m state --state INVALID -j LOG \ --log-prefix "INVALID input: " $IPT -A INPUT -m state --state INVALID -j DROP $IPT -A OUTPUT -m state --state INVALID -j LOG \ --log-prefix "INVALID output: " $IPT -A OUTPUT -m state --state INVALID -j DROP $IPT -A FORWARD -m state --state INVALID -j LOG \ --log-prefix "INVALID forward: " $IPT -A FORWARD -m state --state INVALID -j DROP
Source-Address Spoofing and Other Bad Addresses
This section establishes some filters based on source and destination addresses. These addres-ses will never be seen in a legitimate packet. At the packet-filtering level, one of the few cases of source-address spoofing that you can identify as a forgery with certainty is your own IP address. These rules deny incoming packets claiming to be from you: # Refuse spoofed packets pretending to be from you $IPT -A INPUT -s $DMZ_IPADDR -j DROP $IPT -A INPUT -s $LAN_IPADDR -j DROP $IPT -A FORWARD -s $DMZ_IPADDR -j DROP $IPT -A FORWARD -s $LAN_IPADDR -j DROP $IPT -A INPUT -i $DMZ_INTERFACE \ -s $LAN_ADDRESSES -j DROP
The preceding rules are redundant if you have activated the rp_filter kernel facility. It's good practice to define the rules explicitly. Likewise, the firewall rules drop packets that don't contain a local source address. Regardless, it's good practice to explicitly define a rule to implement RFC 2827, "Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing": $IPT -A FORWARD -i $DMZ_INTERFACE \ -s $LAN_ADDRESSES -j DROP $IPT -A FORWARD -i $LAN_INTERFACE \ -s ! $LAN_ADDRESSES -j DROP $IPT -A OUTPUT -o $DMZ_INTERFACE -s ! $DMZ_IPADDR -j DROP $IPT -A OUTPUT -o $LAN_INTERFACE -s ! $LAN_IPADDR -j DROP
We'll skip the rules from Chapter 4 that checked for private network source addresses. The gateway firewall is performing that function. The next sets of rules are primarily for completeness. Both of the firewall's default policies are to drop everything. As such, broadcast addresses are dropped by default and must be explicitly enabled when they are wanted: # Refuse malformed broadcast packets $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE \ -d $BROADCAST_SRC -j DROP $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE \ -d $BROADCAST_SRC -j DROP # Don't forward directed broadcasts $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE \ -d $DMZ_NETWORK -j DROP $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE \ -d $DMZ_BROADCAST -j DROP # Don't forward limited broadcasts in either direction $IPT -A FORWARD -d $BROADCAST_DEST -j DROP
Multicast is always sent over UDP. Whether or not you add rules to accept incoming multicast, the following rules block illegal multicast packets: $IPT -A INPUT -p ! udp -d $CLASS_D_MULTICAST -j DROP $IPT -A FORWARD -p ! udp -d $CLASS_D_MULTICAST -j DROP Filtering ICMP Control and Status Messages
When the connection state tracking is used, ICMP error messages are forwarded for existing connections, and incoming and outgoing messages are accepted. The error messages are RELATED messages. Otherwise, ICMP traffic would require explicit acceptance rules. ping's echo-request message type must be allowed explicitly, in any case. echo-request and echo-reply are diagnostic messages rather than error messages related to an ongoing exchange. Also of note regarding echo-request is that DHCP sometimes relies on echo-request to discover whether an address that is about to be assigned is already in use by a host on the local network. Rather than duplicating the ICMP rules from Chapter 4, I'll assume that you are using the state module. echo-request and time-exceeded do need special consideration, however. ECHO REQUEST (TYPE 8) AND ECHO REPLY (TYPE 0) MESSAGES
ping uses two ICMP message types. The request message, echo-request, is message Type 8. The reply message, echo-reply, is message Type 0. echo-request messages are not forwarded into the LAN from anywhere. External echo-request to the choke are allowed from only the gateway firewall: $IPT -A INPUT -i $DMZ_INTERFACE -p icmp --icmp-type echo-request \ -s $GATEWAY_IPADDR -j ACCEPT Some sites might choose to block outgoing echo-reply messages even if incoming echo-request messages are dropped. Some trojans, such as loki, use unsolicited echo-reply messages to carry covert login sessions in the packets' data area from your local hosts to remote servers: $IPT -A OUTPUT -o $DMZ_INTERFACE -p icmp --icmp-type echo-reply \ -d $GATEWAY_IPADDR -j ACCEPT $IPT -A FORWARD -o $DMZ_INTERFACE -p icmp --icmp-type echo-reply -j DROP
TIME EXCEEDED STATUS (TYPE 11) MESSAGES
ICMP message Type 11, time-exceeded, indicates a timeout conditionor, more accurately, that a packet's maximum hop count has been exceeded. On networks today, time-exceeded is mostly seen as the ICMP response to a TRaceroute request. Many people use traceroute to pinpoint a problem in the network. Additionally, TRaceroute is useful in network mapping and locating critical gateways. Whether or not you choose to use traceroute, it's a good idea to block outgoing time-exceeded messages. There are few legitimate reasons for someone to map your internal network, and plenty of hostile reasons to do so. It should be noted that some versions of traceroute, notably those on *nix platforms, use UDP as the transport mechanism rather than ICMP. If you need to allow any kind of incoming UDP traffic on the unprivileged ports, it's easier and more effective to block your outgoing response than it is to try to block the incoming requests. TRaceroute starts at UDP port 33434, by default, but the base port is settable by command-line option and optionally can use ICMP echo-request rather than UDP as well: $IPT -A OUTPUT -o $DMZ_INTERFACE -p icmp --icmp-type time-exceeded -j DROP $IPT -A FORWARD -o $DMZ_INTERFACE -p icmp --icmp-type time-exceeded -j DROP If new incoming UDP packets are dropped by default, your system won't return the ICMP Type 3 port-unreachable message that endpoint hosts return. Enabling DNS (UDP/TCP Port 53)
DNS relies on both UDP and TCP. Connection modes include regular client-to-server connections, server-to-server lookup traffic, and DNS zone transfers. It's unlikely that a residential site will host public DNS service or pay the fee to have a top-level public pointer to its name server, though Dynamic DNS services are changing this paradigm. Smaller businesses may or may not do so. It's common to hire a DNS service or to have the service provided by the ISP or ASP. Larger organizations usually do host publicly accessible name servers, as well as run local, private name servers internally. CLASSIC DNS SETUP FOR A LAN
Some sites need the additional sense of security that comes with a classic DNS setup that hides local hostssecurity through obscurity, if you will. The attraction of this setup is that sensitive, local, personal, and account information can be centrally stored in the internal DNS database. The idea is that a publicly visible host runs its own DNS server for the public. The server is configured as the authoritative source for the site, but the information is incomplete. The public name server knows nothing about internal machines. DNS clients on the public name server machine, if any, possibly don't use the local name server. Instead, /etc/resolv.conf on the public server points to an internal, private machine as the name server for the local clients. Incoming queries from the Internet are handled by the public DNS server. Local queries are handled by the internal DNS server. The internal server is also configured as the authoritative source for the site. In this case, the information is correct. Local queries, possibly queries from the public server's local clients, and queries from the private LAN are all handled by this internal, private DNS server. As shown in Figure 6.6, when the local server doesn't have the requested lookup information, it queries the public server, which, in turn, forwards the query to an external name server. Figure 6.6. Public dummy and private authoritative DNS name servers.
A similar configuration is the case shown in Figure 6.7. The public server claims to be authoritative for the entire site. It knows only about the DMZ servers and answers queries about them. The forwarding server knows about local hosts and answers local queries. Local machines are probably not publicly addressable from the Internet. Both servers are primary authorities for their local domain. The forwarding server may or may not have hard-coded DNS information about hosts in the DMZ. Figure 6.7. Authoritative public and private DNS name servers.
In the case in Figure 6.8, both servers hold the same DNS LAN database. Local hosts are visible to the Internet. The secondary, public server gets its information about the LAN from the primary server. Figure 6.8. Secondary public and primary internal DNS name servers.
The primary could be the primary for both the LAN and the DMZ. On the other hand, it could be the primary for the LAN, and the DMZ server could be the primary for the DMZ. It's possible for DNS servers to be both primary and secondary servers for different domains at the same time. In practice, larger sites may have multiple domain spaces and public and private name servers for load sharing and service reliability. One server is the primary server for each domain. The rest are secondary servers that refresh and update their databases, as needed, by requesting zone transfers from the primary. In the following examples, the public DNS servers are running in the DMZ, and a private server is running on the choke firewall machine. There is no requirement that the site be configured this way. A public server could be hosted on the gateway. The private server could be on some other host in the LAN. This would in fact be the recommended approach because it's never a good idea to run extra services on the firewall machine. As the site's network architecture becomes larger and more formal, it becomes more likely that the DMZ servers will be dedicated to hosting a single service. The gateway functions only as a filter and a router. All services are moved to the DMZ or the LAN. GATEWAY CONFIGURATION FOR A PUBLIC DMZ NAME SERVER
The DMZ contains the public name servers. One possible configuration is to have all local DNS clients use the private name server running on the choke machine. If the choke server can't service a query, it forwards the request to one of the public servers, which, in turn, queries designated remote servers or the root name servers, in the most general case. The gateway firewall forwards DNS traffic between the public servers in the DMZ and remote servers, as well as incoming lookup requests from the Internet. For this example, you must define a DNS_SERVER constant, and the DMZ servers use the standard DNS client/server protocols: # DNS name server (53) - requests to remote servers # ------------------------------------------------- $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p udp \ -s $DNS_SERVER --sport $UNPRIVPORTS --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $DNS_SERVER --sport $UNPRIVPORTS --dport 53 \ -m state --state NEW -j ACCEPT # DNS name server (53) - requests from remote clients # --------------------------------------------------- $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p udp \ --sport $UNPRIVPORTS -d $DNS_SERVER --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport $UNPRIVPORTS -d $DNS_SERVER --dport 53 \ -m state --state NEW -j ACCEPT
Naturally, the single pair of generic rules is required to forward ESTABLISHED and RELATED TRaffic. CHOKE DMZ CONFIGURATION AS A PRIVATE NAME SERVER
The choke hosts the private name server in this example. (The server, or servers, could just as easily run in the LAN itself or in a separate local server network.) LAN clients use the private name server. If the choke server can't service a query from its DNS cache, it forwards the request to the public server running in the DMZ. The private DNS server receives client queries from the client programs running on machines in the LAN. In this example, requests from DMZ clients go to the private server so that they have access to DNS information about LAN clients: # DNS LAN clients to private server (53) # -------------------------------------- $IPT -A INPUT -i $LAN_INTERFACE -p udp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $LAN_IPADDR --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A INPUT -i $LAN_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $LAN_IPADDR --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A INPUT -i $DMZ_INTERFACE -p udp \ -s $DMZ_ADDRESSES --sport $UNPRIVPORTS \ -d $DMZ_IPADDR --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A INPUT -i $DMZ_INTERFACE -p tcp \ -s $DMZ_ADDRESSES --sport $UNPRIVPORTS \ -d $DMZ_IPADDR --dport 53 \ -m state --state NEW -j ACCEPT The TCP rule handles both large DNS responses and zone-transfer requests from local secondary name servers. The private DNS server sends recursive server requests to the public DNS server for queries that the choke server can't resolve. When using this code, don't forget to define a DNS_SERVER constant as well: # DNS caching & forwarding name server (53) # ---------------------------------------- $IPT -A OUTPUT -o $DMZ_INTERFACE -p udp \ -s $DMZ_IPADDR --sport 53 \ -d $DNS_SERVER --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p udp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $DNS_SERVER --dport 53 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $DNS_SERVER --dport 53 \ -m state --state NEW -j ACCEPT
In this example, the forwarding name server is assumed to be configured as a slave to the public server. I always include the standard UDP client rules as a precaution. Filtering the AUTH User Identification Service (TCP Port 113)
The ident or AUTH user identification service provides the username associated with the connection. This is a historic protocol not used widely on the Internet anymore. You don't need to run the AUTH service but it's common to send a REJECT or TCP RST for AUTH requests. REJECTING AUTH REQUESTS
The following rule blocks AUTH requests at the gateway by using REJECT rather than DROP so that the requests get a TCP RST right away rather than being blocked silently: $IPT -A INPUT -i $EXTERNAL_INTERFACE -p tcp \ --dport 113 -j REJECT
Email (TCP SMTP Port 25, POP3 Port 110, IMAP Port 143)
Mail is typically handled by a central SMTP server. As a workable example, this section is based on the assumption that a machine in the DMZ is the local mail gateway and mail host. Local clients will retrieve incoming mail from the mail host using its local POP3 or IMAP server. It's equally likely that the mail server in the DMZ is no more than a relay agent and SPAM filter, and incoming mail would be forwarded from the mail relay in the DMZ to a mail server in the private LAN for access by local users. Two common approaches to client and server email combinations are described in this section:
FORWARDING MAIL THROUGH THE GATEWAY (TCP PORT 25)
When you relay outgoing mail through a remote gateway server, your client mail program sends all outgoing mail to your ISP's mail server. Your ISP acts as your mail gateway to the rest of the world. Your system doesn't need to know how to locate the mail destinations. The ISP mail gateway serves as your relay. In this example, your site is hosting its own mail server. Your local server is responsible for collecting your outgoing mail, doing the DNS lookup on the destination hostname, and relaying the mail to its destination. Your client mail program points to your local SMTP server rather than to a remote server. If you are relaying outgoing mail as an SMTP server and are receiving mail as an SMTP client, you provide all your own mail services. Your local sendmail daemon is configured to relay outgoing mail to the remote destination hosts itself, as well as collect and possibly deliver incoming mail. For these examples, don't forget to define a constant for the MAIL_SERVER, such as this: MAIL_SERVER="192.168.1.10" The first rule enables you to relay outgoing mail and is applied to the gateway firewall: $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $MAIL_SERVER --sport $UNPRIVPORTS --dport 25 \ -m state --state NEW -j ACCEPT
The next rule enables you to receive incoming mail and is also applied to the gateway firewall: $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport $UNPRIVPORTS -d $MAIL_SERVER --dport 25 \ -m state --state NEW -j ACCEPT Finally, the gateway might generate mail to local hosts or to some central administrative server: $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS -d $MAIL_SERVER --dport 25 \ -m state --state NEW -j ACCEPT CHOKE SMTP CLIENT CONFIGURATION
This rule set enables you to forward mail from LAN machines and send mail from the choke firewall itself. When using this code, don't forget to define a MAIL_SERVER constant: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $MAIL_SERVER --dport 25 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $MAIL_SERVER --dport 25 \ -m state --state NEW -j ACCEPT
RETRIEVING MAIL AS A POP CLIENT THROUGH THE CHOKE FIREWALL (TCP PORT 110)
How you receive mail depends on your situation. If you run your own local mail server, you can collect incoming mail directly on your Linux machine. If you retrieve your mail from your ISP account, you may or may not retrieve mail as a POP or IMAP client, depending on how you've configured your ISP email account, and depending on the mail-delivery services that the ISP offers. In this example, incoming mail is delivered to the local mail server. LAN clients retrieve their mail from the local mail host using POP. The mail host also functions as a POP server. This rule is applied to the choke firewall, and you would need to define the constant for the POP3 server as POP_SERVER if you use this code: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $POP_SERVER --dport 110 \ -m state --state NEW -j ACCEPT RETRIEVING MAIL AS AN IMAP CLIENT THROUGH THE CHOKE FIREWALL (TCP PORT 143)
Connecting to an IMAP server is another common means of retrieving mail from a mail host. The following example demonstrates the firewall rules necessary to retrieve mail from an IMAP server running in the DMZ. The next rule forwards client connections from the LAN to the IMAP server running on the mail host in the DMZ and is applied to the choke firewall with the IMAP_SERVER constant predefined: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $IMAP_SERVER --dport 143 \ -m state --state NEW -j ACCEPT Accessing Usenet News Services (TCP NNTP Port 119)
Usenet news is accessed over the NNTP protocol running on top of TCP through service port 119. Reading news and posting articles are handled by your local news client. A non-ISP site isn't likely to host a news server for the outside world. Even hosting a local news server is unlikely for a small site. For the site that represents the rare exception, the server rule should be configured to allow incoming connections from only a select set of external clients or external networks. A local public server would run on a machine in the DMZ, and the gateway would forward incoming NNTP connections to the local NNTP server machine. GATEWAY NNTP CONDUIT AND SERVER DMZ CONFIGURATIONS
The server rule allows local client connections to your ISP's news server. Both reading news and posting articles are handled by this rule set: $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $NEWS_SERVER --dport 119 \ -m state --state NEW -j ACCEPT
If a local news server is running on a machine in the DMZ, offering public service to select remote clients, a set of server rules allowing remote clients to connect to this machine's NNTP port is defined: DMZ_NEWS_SERVER="192.168.1.70" $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s <my.news.clients> --sport $UNPRIVPORTS \ -d $DMZ_NEWS_SERVER --dport 119 \ -m state --state NEW -j ACCEPT
If the local news server provides public Usenet newsgroups as well as local newsgroups, the local server requires a news feed from a remote server. The local server retrieves articles as a client to the remote server. The following rule allows access to a remote news server acting as a news feed: NEWS_FEED="<my.remote.news.feed>" $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $DMZ_NEWS_SERVER --sport $UNPRIVPORTS \ -d $NEWS_FEED --dport 119 \ -m state --state NEW -j ACCEPT
CHOKE NNTP CLIENT DMZ CONFIGURATIONS
The next rule allows local clients to access remote news servers in either the DMZ or on the Internet and would require a NEWS_SERVER constant to be defined: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $NEWS_SERVER --dport 119 \ -m state --state NEW -j ACCEPT Telnet (TCP Port 23)
Some types of equipment, such as lower-end routers and other networking gear, allow only telnet connections for configuration. Therefore, you may find yourself forced to use it when you'd rather use a more secure protocol such as SSH. The rules here allow LAN access to the DMZ machines using telnet. The DMZ hosts aren't allowed to connect to hosts in the LAN. The choke firewall is allowed telnet access to the LAN, however. You should not allow incoming telnet connections from remote sites; rather, you should use SSH to connect into the DMZ and then use telnet from the DMZ if you are absolutely forced to use telnet. These rules are applied to the choke firewall for telnet: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $DMZ_ADDRESSES --dport 23 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $DMZ_ADDRESSES --dport 23 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $LAN_INTERFACE -p tcp \ -s $LAN_IPADDR --sport $UNPRIVPORTS \ -d $LAN_ADDRESSES --dport 23 \ -m state --state NEW -j ACCEPT
SSH (TCP Port 22)
The client and server rules here demonstrate three separate approaches to SSH. In practice, non-ISP sites would probably limit the external addresses to a select subset, particularly because both ends of the connection should be configured to recognize each individual user account. sshd can use TCPWrappers with access lists in /etc/hosts.allow and /etc/hosts.deny. GATEWAY SSH CONFIGURATION
The first rule allows local connections from the choke machine to an sshd server running on the gateway. All of these rules are applied on the gateway firewall: $IPT -A INPUT -i $DMZ_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS \ -d $DMZ_IPADDR --dport 22 \ -m state --state NEW -j ACCEPT The next rule forwards connections from LAN clients to any remote server: $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 22 \ -m state --state NEW -j ACCEPT
The last rule forwards connections from a selected remote client address to a specific local server: $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s <selected remote host> --sport $UNPRIVPORTS \ -d <selected local host> --dport 22 \ -m state --state NEW -j ACCEPT CHOKE SSH CONFIGURATION
The first rule allows local connections from the choke machine to sshd servers running in the DMZ, including the gateway firewall host: $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $DMZ_ADDRESSES --dport 22 \ -m state --state NEW -j ACCEPT
The next rule forwards connections from LAN clients to any remote server: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 22 \ -m state --state NEW -j ACCEPT
The last rule forwards connections from a selected remote client address to a specific local host, which, in this case, resides in the LAN: $IPT -A FORWARD -i $DMZ_INTERFACE -o $LAN_INTERFACE -p tcp \ -s <selected remote host> --sport $UNPRIVPORTS \ -d <selected LAN host> --dport 22 \ -m state --state NEW -j ACCEPT FTP (TCP Ports 21 and 20)
FTP has two modes for exchanging data between a client and a server: normal data channel port mode and passive data channel mode. Port mode is the default mechanism when using the FTP client program and connecting to a remote FTP site. Passive mode is the mechanism used when connecting to an FTP site through a web browser. Occasionally, you might encounter an FTP site that supports only one mode. Two approaches to client and server FTP combinations are described in this section:
GATEWAY AS CONDUIT TO REMOTE FTP SERVERS
It's almost a given that most sites will want FTP client access to remote file repositories. The first section allows internal hosts to connect to remote FTP servers. The following rules allow outgoing FTP client connections from the choke host and the LAN machines. The constants are those used on the gateway: # Outgoing FTP Client Request # --------------------------- $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 21 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport 21 \ -m state --state NEW -j ACCEPT
The ip_conntrack_ftp module takes care of the port or passive mode data connection as part of the RELATED state. Specific rules for the data connection aren't required. The two pairs of data channel connection request rules are included here for the sake of completeness: # Port Mode Data Channel Responses # --------------------------------------- $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport 20 -d $LAN_ADDRESSES --dport $UNPRIVPORTS \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport 20 -d $CHOKE_IPADDR --dport $UNPRIVPORTS \ -m state --state NEW -j ACCEPT # Passive Mode Data Channel Responses # ----------------------------------- $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport $UNPRIVPORTS \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport $UNPRIVPORTS \ -m state --state NEW -j ACCEPT
The choke's client rule is included in the upcoming section "Choke as Conduit and Client to an FTP Server." FTP SERVER IN DMZ, CHOKE, LOCAL HOSTS, AND REMOTE HOSTS AS CLIENTS
This section defines rules to allow incoming client requests using FTP. GATEWAY AS CONDUIT TO AN FTP DMZ SERVER
On the gateway, the next rule forwards incoming FTP client connections from any remote machine to the server in the DMZ. When using this code, note that it requires a constant of DMZ_FTP_SERVER to be defined: $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport $UNPRIVPORTS -d $DMZ_FTP_SERVER --dport 21 \ -m state --state NEW -j ACCEPT CHOKE AS CONDUIT AND CLIENT TO AN FTP SERVER
The following rules allow outgoing FTP client connections from the LAN and the choke machine to an FTP server anywhere. The choke's rules don't refer to the DMZ specifically. The first rule forwards outgoing FTP client connections from any LAN machine to any server: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 21 \ -m state --state NEW -j ACCEPT The second rule allows FTP client access from the choke host itself: $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS --dport 21 \ -m state --state NEW -j ACCEPT
Web Services
Web services generally are based on the HTTP protocol. Several higher-level communication protocols are used for special purposes, including a special protocol for web proxy and cache access (webcache on TCP port 8080 in /etc/services), and SSL and TLS for secure access (https on TCP port 443 in /etc/services). The squid web proxy uses TCP port 3128 by default (squid on TCP port 3128 in /etc/services). Four approaches to client and server web combinations are described in this section:
THE GATEWAY AS A CONDUIT FOR LOCAL WEB CLIENTS
The first section of the following code allows local hosts to connect to web servers running on remote hosts. On the gateway, the following rules forward local client connections from the choke machine, as well as from machines on the private LAN behind the choke firewall: $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT
THE CHOKE AS A FORWARDER AND WEB CLIENT
The choke acts as both a forwarder and a client in this example. The following rules forward local client connections from the LAN and also allow client connections from the choke itself: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT
A PUBLIC WEB SERVER IN THE DMZ; THE CHOKE, LAN, AND REMOTE HOSTS AS CLIENTS
In this example, the site hosts a public web server in the DMZ. The gateway is a bidirectional conduit, allowing public access to the local server, as well as continuing to allow local access to remote sites using the rules presented in the preceding section. These rules apply to the gateway and would require a predefined constant of DMZ_WEB_SERVER: $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport $UNPRIVPORTS -d $DMZ_WEB_SERVER --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $EXTERNAL_INTERFACE -o $DMZ_INTERFACE -p tcp \ --sport $UNPRIVPORTS -d $DMZ_WEB_SERVER --dport 443 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $CHOKE_IPADDR --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT
The choke's rules remain the same as they were in the preceding section. A WEB PROXY IN THE DMZ; THE GATEWAY AS A CONDUIT; CHOKE AND LAN AS CLIENTS
Although it's possible to offer public web service from an internal LAN server, it isn't usually done because of the greater potential for security breaches with misconfigured servers and CGI scripts, and the tendency to isolate private information from public information. That is, sites that host both a private, internal website and a public website usually run multiple web servers on different machines in different LANs. A more common scenario would be to host the public website from a host on the perimeter network. In the case of a very small personal or business home site, one possibility is to run a public server on the gateway machine. (Hosting a public web server on the firewall host would otherwise be considered a dangerous idea.) Possibly, a second, private proxy web server runs on an internal machine. In this situation, the public server may or may not offer SSL service. The internal web server offers proxy service. The private server isn't accessible from the gateway machine. The proxy server in this example could run in the LAN, but there wouldn't be an "example" because the firewall rules on both the gateway and the choke would remain the same as in the first web section. Placing the proxy web server in the DMZ or on the choke host demonstrates the difference between the client-side rules and the server-side rules. From the gateway's perspective, the internal web proxy appears to be a web client initiating connections to remote servers. This example requires a constant of DMZ_WWW_PROXY: $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $DMZ_WWW_PROXY --sport $UNPRIVPORTS --dport 80 \ -m state --state NEW -j ACCEPT $IPT -A FORWARD -i $DMZ_INTERFACE -o $EXTERNAL_INTERFACE -p tcp \ -s $DMZ_WWW_PROXY --sport $UNPRIVPORTS --dport 443 \ -m state --state NEW -j ACCEPT
The choke's rules must account for the port that the web proxy is bound to, thus the WEB_PROXY_PORT constant in this example. From the choke's perspective, the local web proxy appears to be a server running on a port other than TCP port 80, as these rules show: $IPT -A FORWARD -i $LAN_INTERFACE -o $DMZ_INTERFACE -p tcp \ -s $LAN_ADDRESSES --sport $UNPRIVPORTS \ -d $DMZ_WWW_PROXY --dport $WEB_PROXY_PORT \ -m state --state NEW -j ACCEPT $IPT -A OUTPUT -o $DMZ_INTERFACE -p tcp \ -s $DMZ_IPADDR --sport $UNPRIVPORTS \ -d $DMZ_WWW_PROXY --dport $WEB_PROXY_PORT \ -m state --state NEW -j ACCEPT
Choke as a Local DHCP Server (UDP Ports 67 and 68)
DHCP provides network configuration information to hosts. We often think of DHCP mostly in terms of assigning IP addresses, but it also can provide information such as your network mask and MTU, the address of the first-hop router, name server addresses, and the domain name. Although you should never send DHCP server messages to the Internet (with the notable exception of your gateway that might need to contact your ISP's DHCP server), some people run a private DHCP server to assign IP addresses to local machines. DHCP can be useful not only for assigning IP addresses on a larger LAN with many machines, but also for very small personal home LANs. In fact, some people with a single standalone system sometimes run the DHCPD server locally if they carry a laptop computer between home and work. If the work environment assigns IP addresses dynamically, using DHCP at home makes transporting the laptop between networks easier. Additionally, some networked printers and wireless devices can or do use DHCP to discover their IP address when they come online. For this example, the dhcpd server is running on the choke machine, providing dynamic IP address assignment for machines on the private LAN: $IPT -A INPUT -i $LAN_INTERFACE -p udp \ -s $BROADCAST_SRC --sport 68 \ -d $BROADCAST_DEST --dport 67 -j ACCEPT $IPT -A OUTPUT -o $LAN_INTERFACE -p udp \ -s $BROADCAST_SRC --sport 67 \ -d $BROADCAST_DEST --dport 68 -j ACCEPT $IPT -A OUTPUT -o $LAN_INTERFACE -p udp \ -s $LAN_IPADDR --sport 67 \ -d $BROADCAST_DEST --dport 68 -j ACCEPT $IPT -A INPUT -i $LAN_INTERFACE -p udp \ -s $BROADCAST_SRC --sport 68 \ -d $LAN_IPADDR --dport 67 -j ACCEPT $IPT -A OUTPUT -o $LAN_INTERFACE -p udp \ -s $LAN_IPADDR --sport 67 \ -d $LAN_ADDRESSES --dport 68 -j ACCEPT $IPT -A OUTPUT -o $LAN_INTERFACE -p udp \ -s $LAN_IPADDR --sport 67 \ -d $LAN_ADDRESSES --dport 68 -j ACCEPT $IPT -A INPUT -i $LAN_INTERFACE -p udp \ -s $LAN_ADDRESSES --sport 68 \ -d $LAN_IPADDR --dport 67 -j ACCEPT
Logging
Logging dropped packets on the internal interfaces is a good idea, even if the LAN is a relatively trusted environment. Logging is a major tool when debugging firewall problems and understanding communication protocols, both in cases in which different vendors have not strictly adhered to the protocol standards and in cases in which you don't know just what the protocol is. Application protocol information is often difficult to find or is incomplete because network-application writers usually are thinking in terms of an unfiltered, open network. If all traffic were allowed between the private LAN and the choke machine, logging still might be enabled on a port-specific basis or for broadcast traffic. However, although allowing all local traffic is easier in the short term for trusted environments, it can make debugging more difficult when packets are then dropped by the forwarding rules or by the gateway's firewall rules. |
Категории