Web interface for iptables

# iptables -t nat -N test
# iptables -t nat -A test -p tcp -j REDIRECT --to-port 80
# iptables -t nat -A test -p tcp -j MASQUERADE
# iptables -t nat -A POSTROUTING -j test
iptables: Invalid argument. Run `dmesg' for more information.
# dmesg | tail -n 1
ip_tables: REDIRECT target: used from hooks POSTROUTING, but only usable from PREROUTING/OUTPUT
# iptables -t nat -A PREROUTING -j test
iptables: Invalid argument. Run `dmesg' for more information.
# dmesg | tail -n 1
ip_tables: MASQUERADE target: used from hooks PREROUTING, but only usable from POSTROUTING

This post is about the iptables program and the web interface for it.

Those who are not familiar with such a wonderful program like Iptables are addressed to the last two sections of the post.

Plot

http://iptadmin.confmgr.org/

Iptadmin - an attempt to simplify the work with the firewall in Linux. At the moment, this is a simple web interface that can work with only a few iptables options. BSD3.

Benefits of iptadmin:

• Displaying a list of rules is beautiful in a browser with numbering inside each chain. And in some places even with color backlighting. Instead of having to constantly type iptables -L -vn –line-numbers to control the rules.
• Ability to create and edit rules using the mouse cursor and checkboxes.
  
• Where possible, only the correct input options are offered. The situation described at the beginning of the post is warned.
  
• Automatically add option modules.
  
• Protection against creating a rule that prohibits access to the management interface over a network.
  
• Installing Iptadmin does not change anything or spoil Iptables rules. Iptadmin does not store any intermediate data on the system. At any time, you can use the familiar console interface or even remove Iptadmin.
  

Cons of the program regarding iptables:

• Another constantly working gluttonous demon. It requires several megabytes of memory to work. It can only be started during setup. But to start, and then stop the demon is extra body movements.
  
• A process with root rights listens over the network. The process is debugged, tested, statically typed, in a high-level language without pointers, with garbage collection. But it works under root and listens on the network port.
  
• So far, only a few of the most commonly used iptables options are supported. Any non-trivial rules will still have to be set from the console.
  

Are there any analogues?

There are similar programs. But a detailed comparative analysis was not conducted. Here are some links and small comments:

• Module for Webmin . It works at the iptables level. Supports all or almost all rule options. Breaks configuration files. Written in perl. http://doxfer.webmin.com/Webmin/LinuxFirewall .
  
• System-config-firewall from Red Hat. One of the best GUIs for iptables. Allows you to open / close ports, configure broadcasting. But everything is hidden from the user. Several rules are added to one checkmark (for example, when adding an interface to the “trusted” list). The program does not display nontrivial rules in any way. http://fedoraproject.org/wiki/SystemConfig/firewall
  
• Uncomplicated firewall + GUI for Ubuntu . Also a high-level interface, but it is worked out worse than in System-config-firewall. Before starting work, the warning “all manual changes will be lost”. http://gufw.tuxfamily.org/ .
  
• Shorewall . Abstractions over iptables. Everything is configured through text files. Written in perl. http://www.shorewall.net/
  
• Firewall Builder - IDE for developing firewall rules with translation in many formats, including iptables, ipfw, iron firewalls. Probably a great tool for huge infrastructures with dozens of firewalls. http://www.fwbuilder.org/
  

Afterword for those lucky enough not to know what iptables is.

One of the components of the kernel of the Linux operating system is the firewall. It allows you to perform many types of traffic filtering. In addition, the kernel has the ability to translate network addresses. For example, Linux-based network gateways are built to connect local networks to the Internet.

The user interface to the Linux firewall is Iptables. This is a command line program, it interacts with the user through a text terminal. When creating rules, you must remember the rules parameters by heart, or constantly keep the manual page open. Also iptables is no different with detailed input error messages. Some errors are only reported by kernel logging.

As is often the case with Linux subsystems, Iptables practically needs a separate specialist to configure (Other examples of components that are difficult to configure: PAM, Selinux, Policy kit).

Typical workflow when working with iptables

For example, we want to make DNAT from 192.168.1.1:80 to 192.168.0.3:8000 when accessing from the subnet 10.0.0.0/16:

# iptables -A POSTROUTING -s 10.0.0.0/16 -d 192.168.1.1 --dport 80 -j DNAT --to-destination 192.168.0.3:8000
iptables v1.4.7: unknown option `--dport'
Try `iptables -h' or 'iptables --help' for more information.

So iptables knows nothing about the --dport option, to use it you need to specify the -p tcp option.
And how could we forget?

# iptables -A POSTROUTING -s 10.0.0.0/16 -d 192.168.1.1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.3:8000
iptables: No chain/target/match by that name.

Iptables knows nothing about the POSTROUTING chain. How so? We re-read the name, spelling without errors.
A! It is necessary to specify the table "nat". By default, iptables uses the “filter” table.

# iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -d 192.168.1.1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.3:8000
iptables: Invalid argument. Run `dmesg' for more information

Now we need to read dmesg to find out what is wrong this time.

# dmesg | tail
[   44.855055] Bluetooth: BNEP filters: protocol multicast
[   44.891259] Bluetooth: SCO (Voice Link) ver 0.6
[   44.891262] Bluetooth: SCO socket layer initialized
[   45.021718] Bluetooth: RFCOMM TTY layer initialized
[   45.021726] Bluetooth: RFCOMM socket layer initialized
[   45.021728] Bluetooth: RFCOMM ver 1.11
[   93.795558] fuse init (API version 7.14)
[   93.823129] SELinux: initialized (dev fusectl, type fusectl), uses genfs_contexts
[   93.862287] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
[ 1912.405272] x_tables: ip_tables: DNAT target: used from hooks POSTROUTING, but only usable from PREROUTING/OUTPUT

Another mistake. DNAT works in the PREROUTING chain, not POSTROUTING. Finally, execute the command:

# iptables -t nat -A PREROUTING -s 10.0.0.0/16 -d 192.168.1.1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.3:8000
#

Hurrah! We did it. DNAT rule added.