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 is a post about the iptables program and about the web interface for it.



Those who are not familiar with such a wonderful program as 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.

')

The advantages that Iptadmin gives:

• The display of the list of rules is beautiful in the browser, numbered within each chain. And in some places even with highlight color. 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.
  
  
• Automatic addition of module options.
  
  
• Protection against creating a rule that denies access to the management interface over the network.
  
  
• Installing Iptadmin does not change anything and does not spoil the Iptables rules. Iptadmin does not store any intermediate data on the system. At any time, you can use the familiar console interface or delete Iptadmin altogether.
  
  

The disadvantages of the program are relative to iptables:

• Another constantly working voracious demon. Requires the order of several megabytes of memory. You can run only at the time of setup. But to start and then stop the demon is an extra gesture.
  
  
• The process with the rights of the root listens on the network. The process is debugged, tested, statically typed, in a high-level language without pointers, with garbage collection. But he works under the root and listens to 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 a few links and small comments:

• Module for webmin . Works at the level of iptables. Supports all or almost all rule options. Breaks configuration files. Written in perl. http://doxfer.webmin.com/Webmin/LinuxFirewall .
  
  
• Red Hat System-config-firewall . One of the best GUI for iptables. Allows you to open / close ports, configure broadcast. But everything is hidden from the user. Several rules are added to one tick (for example, when adding an interface to the "trusted" list). Nontrivial rules the program does not display in any way. http://fedoraproject.org/wiki/SystemConfig/firewall
  
  
• Uncomplicated firewall + GUI for Ubuntu . It is also a high-level interface, but it is worked out worse than in System-config-firewall. Before the start of the warning, "all manual changes will be lost." http://gufw.tuxfamily.org/ .
  
  
• Shorewall . Abstractions over iptables. Configures everything through text files. Written in perl. http://www.shorewall.net/
  
  
• Firewall Builder - IDE for developing firewall rules with broadcasting 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 Linux kernel is a firewall. It allows you to perform many types of traffic filtering. In addition, the kernel has the ability to broadcast 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 the iptables program. This is a command line program, it interacts with the user through a text terminal. When creating rules, you must remember by heart the parameters of the rules, or keep the manual page open at all times. Also, iptables is not distinguished by detailed input error messages. Some errors are displayed only by means of kernel logging.



As is often the case with Linux subsystems, an individual specialist is almost always needed to configure Iptables (Other examples of complex components are: 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 must 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 by letter, sort of without errors.

BUT! 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 # 

Hooray! We did it. DNAT rule added.