Red Hat Firewall -iptables HowTwo

FORWARD and NAT Rules

This forwarding of network traffic can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker’s machine act as a node on your LAN.

To prevent this, iptables provides routing and forwarding policies that can be implemented to prevent abnormal usage of network resources.

The FORWARD chain allows an administrator to control where packets can be routed within a LAN. For example, to allow forwarding for the entire LAN (assuming the firewall/gateway is assigned an internal IP address on eth1), use the following rules:

~]# iptables -A FORWARD -i eth1 -j ACCEPT

~]# iptables -A FORWARD -o eth1 -j ACCEPT

This rule gives systems behind the firewall/gateway access to the internal network. The gateway routes packets from one LAN node to its intended destination node, passing all packets through its eth1 device.

By default, the IPv4 policy in Red Hat Enterprise Linux kernels disables support for IP forwarding. This prevents machines that run Red Hat Enterprise Linux from functioning as dedicated edge routers. To enable IP forwarding, use the following command as the root user:

~]# sysctl -w net.ipv4.ip_forward=1

net.ipv4.ip_forward = 1

This configuration change is only valid for the current session; it does not persist beyond a reboot or network service restart. To permanently set IP forwarding, edit the /etc/sysctl.conf file as follows:

Locate the following line:

net.ipv4.ip_forward = 0

Edit it to read as follows:

net.ipv4.ip_forward = 1

As the root user, run the following command to enable the change to the sysctl.conf file:

~]# sysctl -p /etc/sysctl.conf

net.ipv4.ip_forward = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.default.accept_source_route = 0

[output truncated]

 Postrouting and IP Masquerading

Accepting forwarded packets via the firewall’s internal IP device allows LAN nodes to communicate with each other; however they still cannot communicate externally to the Internet.

To allow LAN nodes with private IP addresses to communicate with external public networks, configure the firewall for IP masquerading, which masks requests from LAN nodes with the IP address of the firewall’s external device (in this case, eth0):

~]# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

This rule uses the NAT packet matching table ( -t nat) and specifies the built-in POSTROUTING chain for NAT ( -A POSTROUTING) on the firewall’s external networking device ( -o eth0).

POSTROUTING allows packets to be altered as they are leaving the firewall’s external device.

The -j MASQUERADE target is specified to mask the private IP address of a node with the external IP address of the firewall/gateway.


2.8.5.2. Prerouting

If you have a server on your internal network that you want make available externally, you can use the -j DNAT target of the PREROUTING chain in NAT to specify a destination IP address and port where incoming packets requesting a connection to your internal service can be forwarded.

For example, if you want to forward incoming HTTP requests to your dedicated Apache HTTP Server at 172.31.0.23, use the following command as the root user:

~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to 172.31.0.23:80

This rule specifies that the nat table use the built-in PREROUTING chain to forward incoming HTTP requests exclusively to the listed destination IP address of 172.31.0.23.

If you have a default policy of DROP in your FORWARD chain, you must append a rule to forward all incoming HTTP requests so that destination NAT routing is possible. To do this, use the following command as the root user:

~]# iptables -A FORWARD -i eth0 -p tcp –dport 80 -d 172.31.0.23 -j ACCEPT

This rule forwards all incoming HTTP requests from the firewall to the intended destination; the Apache HTTP Server behind the firewall.

DMZs and IPTables

You can create iptables rules to route traffic to certain machines, such as a dedicated HTTP or FTP server, in a demilitarized zone ( DMZ). A DMZ is a special local subnetwork dedicated to providing services on a public carrier, such as the Internet.

For example, to set a rule for routing incoming HTTP requests to a dedicated HTTP server at 10.0.4.2 (outside of the 192.168.1.0/24 range of the LAN), NAT uses the PREROUTING table to forward the packets to the appropriate destination:

~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \
  --to-destination 10.0.4.2:80

With this command, all HTTP connections to port 80 from outside of the LAN are routed to the HTTP server on a network separate from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network.

If the HTTP server is configured to accept secure connections, then port 443 must be forwarded as well.


 Malicious Software and Spoofed IP Addresses

More elaborate rules can be created that control access to specific subnets, or even specific nodes, within a LAN. You can also restrict certain dubious applications or programs such as trojans, worms, and other client/server viruses from contacting their server.

For example, some trojans scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking terminology).

Since there are no legitimate services that communicate via these non-standard ports, blocking them can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers.

The following rules drop all TCP traffic that attempts to use port 31337:

~]# iptables -A OUTPUT -o eth0 -p tcp –dport 31337 –sport 31337 -j DROP

~]# iptables -A FORWARD -o eth0 -p tcp –dport 31337 –sport 31337 -j DROP

You can also block outside connections that attempt to spoof private IP address ranges to infiltrate your LAN.

For example, if your LAN uses the 192.168.1.0/24 range, you can design a rule that instructs the Internet-facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range.

Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address to the external-facing device (eth0) is rejected automatically.

~]# iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

IPTables and Connection Tracking

You can inspect and restrict connections to services based on their connection state. A module within iptables uses a method called connection trackingto store information about incoming connections. You can allow or deny access based on the following connection states:

  • NEW — A packet requesting a new connection, such as an HTTP request.
  • ESTABLISHED — A packet that is part of an existing connection.
  • RELATED — A packet that is requesting a new connection but is part of an existing connection. For example, FTP uses port 21 to establish a connection, but data is transferred on a different port (typically port 20).
  • INVALID — A packet that is not part of any connections in the connection tracking table.

You can use the stateful functionality of iptables connection tracking with any network protocol, even if the protocol itself is stateless (such as UDP). The following example shows a rule that uses connection tracking to forward only the packets that are associated with an established connection:

~]# iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

 IPv6

The introduction of the next-generation Internet Protocol, called IPv6, expands beyond the 32-bit address limit of IPv4 (or IP). IPv6 supports 128-bit addresses, and carrier networks that are IPv6 aware are therefore able to address a larger number of routable addresses than IPv4.

Red Hat Enterprise Linux supports IPv6 firewall rules using the Netfilter 6 subsystem and the ip6tables command. In Red Hat Enterprise Linux 6, both IPv4 and IPv6 services are enabled by default.

The ip6tables command syntax is identical to iptables in every aspect except that it supports 128-bit addresses. For example, use the following command to enable SSH connections on an IPv6-aware network server:

~]# ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 –dport 22 -j ACCEPT

For more information about IPv6 networking, refer to the IPv6 Information Page at http://www.ipv6.org/.

Packet Filtering

The Linux kernel uses the Netfilter facility to filter packets, allowing some of them to be received by or pass through the system while stopping others. This facility is built in to the Linux kernel, and has three built-in tables or rules lists, as follows:

  • filter — The default table for handling network packets.
  • nat — Used to alter packets that create a new connection and used for Network Address Translation ( NAT).
  • mangle — Used for specific types of packet alteration.

Each table has a group of built-in chains, which correspond to the actions performed on the packet by netfilter.

The built-in chains for the filter table are as follows:

  • INPUT — Applies to network packets that are targeted for the host.
  • OUTPUT — Applies to locally-generated network packets.
  • FORWARD — Applies to network packets routed through the host.

The built-in chains for the nat table are as follows:

  • PREROUTING — Alters network packets when they arrive.
  • OUTPUT — Alters locally-generated network packets before they are sent out.
  • POSTROUTING — Alters network packets before they are sent out.

The built-in chains for the mangle table are as follows:

  • INPUT — Alters network packets targeted for the host.
  • OUTPUT — Alters locally-generated network packets before they are sent out.
  • FORWARD — Alters network packets routed through the host.
  • PREROUTING — Alters incoming network packets before they are routed.
  • POSTROUTING — Alters network packets before they are sent out.

Every network packet received by or sent from a Linux system is subject to at least one table. However, a packet may be subjected to multiple rules within each table before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address, or set of addresses, when using a particular protocol and network service. The following image outlines how the flow of packets is examined by the iptables subsystem:

 

By default, firewall rules are saved in the /etc/sysconfig/iptables or /etc/sysconfig/ip6tables files.

The iptables service starts before any DNS-related services when a Linux system is booted. This means that firewall rules can only reference numeric IP addresses (for example, 192.168.0.1). Domain names (for example, host.example.com) in such rules produce errors.

Regardless of their destination, when packets match a particular rule in one of the tables, a target or action is applied to them. If the rule specifies anACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROPtarget, that packet is refused access to the system and nothing is sent back to the host that sent the packet. If a rule specifies a QUEUE target, the packet is passed to user-space. If a rule specifies the optional REJECT target, the packet is dropped, but an error packet is sent to the packet’s originator.

Every chain has a default policy to ACCEPTDROPREJECT, or QUEUE. If none of the rules in the chain apply to the packet, then the packet is dealt with in accordance with the default policy.

The iptables command configures these tables, as well as sets up new tables if necessary.