• Choose a category
• All
• Classic-Fiction

$IPTABLES -A OUTPUT -p tcp --dport 43 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 80 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 443 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp --dport 4321 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

### default OUTPUT LOG rule

$IPTABLES -A OUTPUT -o ! lo -j LOG --log-prefix "DROP " --log-ip-options

--log-tcp-options

In accordance with our policy requirements, at ❼ we'll assume that connections initiated from the firewall itself will be to download patches or software over FTP, HTTP, or HTTPS; to initiate outbound SSH and SMTP connections; or to issue DNS or whois queries against other systems.

The FORWARD Chain

So far the rules we have added to the iptables filtering policy strictly govern the ability of packets to interact directly with the firewall system. Such packets are either destined for or emanate from the firewall operating system and include packets such as connection requests to the SSH daemon from internal systems or locally initiated connections to external sites to download security patches.

Now let's look at the iptables rules that pertain to packets that do not have a source or destination address associated with the firewall, but which nevertheless attempt to route through the firewall system. The iptables FORWARD chain in the filter table provides the ability to wrap access controls around packets that are forwarded across the firewall interfaces:

###### FORWARD chain ######

echo "[+] Setting up FORWARD chain..."

### state tracking rules

$IPTABLES -A FORWARD -m state --state INVALID -j LOG --log-prefix "DROP INVALID "

--log-ip-options --log-tcp-options

$IPTABLES -A FORWARD -m state --state INVALID -j DROP

$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

### anti-spoofing rules

$IPTABLES -A FORWARD -i eth1 -s ! $INT_NET -j LOG --log-prefix "SPOOFED PKT "

$IPTABLES -A FORWARD -i eth1 -s ! $INT_NET -j DROP

### ACCEPT rules

❽ $IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET --dport 21 --syn -m state --state

NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET --dport 22 --syn -m state --state NEW

-j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET --dport 25 --syn -m state --state NEW

-j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET --dport 43 --syn -m state --state NEW

-j ACCEPT

$IPTABLES -A FORWARD -p tcp --dport 80 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp --dport 443 --syn -m state --state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET --dport 4321 --syn -m state --state

NEW -j ACCEPT

$IPTABLES -A FORWARD -p udp --dport 53 -m state --state NEW -j ACCEPT

$IPTABLES -A FORWARD -p icmp --icmp-type echo-request -j ACCEPT

### default log rule

$IPTABLES -A FORWARD -i ! lo -j LOG --log-prefix "DROP " --log-ip-options

--log-tcp-options

Similar to the rules of the OUTPUT chain, at ❽ FTP, SSH, SMTP, and whois connections are allowed to be initiated out through the firewall, except that such connections must originate from the internal subnet on the subnet-facing interface (eth1). HTTP, HTTPS, and DNS traffic is allowed through from any source because we need to allow external addresses to interact with the internal web- and DNS servers (after being NATed; see the following section, "Network Address Translation").

Network Address Translation

The final step in the construction of our iptables policy is to enable the translation of the non-routable 192.168.10.0/24 internal addresses into the routable external 71.157.X.X address. This applies to inbound connections to the web- and DNS servers from external clients, and also to outbound connections initiated from the systems on the internal network. For connections initiated from internal systems, we'll use the source NAT (SNAT) target, and