GKrellM iptables Support

The patch provides two more graphs with each inet krell. The default is still the hit graph, coming from the same source. The next is the packet count graph. The last is the byte count graph. Pressing the left mouse button on the graph moves through labelled and unlabelled versions of each. The middle mouse button brings up the associated hourly data graph for each.

With the 2.2.7 patch, pressing shift mouse button 1 moves backwards through the graphs, pressing control mouse button 1 moves through the graphs keeping the same extra info (text information display) intact and skipping the others. Pressing control shift mouse button 1 moves backward through the graphs in the same fashion as control mouse button 1.

Hits, packets, and bytes are scaled to engineering units to save screen room.

The configuration screen has an additional check box called outbound. If you want to monitor your surfing load on the internet connection, you might make a data point that has port 80 and 443 specified, data range unchecked, and outbound checked. If you want to monitor the load your website puts on the internet connection, you would have a similar rule set, but the outbound would be unchecked. Appropriate iptables rules to go along with these GKrellM rules would include:

#Inbound

$IPT -A INPUT   -p tcp  -s 0/0  --sport $UPRT   -d $BOX --dport 80      -i $IF  -m state --state NEW,ESTABLISHED        -j ACCEPT       # HTTP
$IPT -A OUTPUT  -p tcp  -s $BOX --sport 80      -d 0/0  --dport $UPRT   -o $IF  -m state --state ESTABLISHED            -j ACCEPT

$IPT -A INPUT   -p tcp  -s 0/0  --sport $UPRT   -d $BOX --dport 443     -i $IF  -m state --state NEW,ESTABLISHED        -j ACCEPT       # HTTPS
$IPT -A OUTPUT  -p tcp  -s $BOX --sport 443     -d 0/0  --dport $UPRT   -o $IF  -m state --state ESTABLISHED            -j ACCEPT

#Outbound

$IPT -A OUTPUT  -p tcp  -s $BOX --sport $UPRT   -d 0/0  --dport 80      -o $IF  -m state --state NEW,ESTABLISHED        -j ACCEPT       # Surf
$IPT -A INPUT   -p tcp  -s 0/0  --sport 80      -d $BOX --dport $UPRT   -i $IF  -m state --state ESTABLISHED            -j ACCEPT

$IPT -A OUTPUT  -p tcp  -s $BOX --sport $UPRT   -d 0/0  --dport 443     -o $IF  -m state --state NEW,ESTABLISHED        -j ACCEPT       # SSL-Surf
$IPT -A INPUT   -p tcp  -s 0/0  --sport 443     -d $BOX --dport $UPRT   -i $IF  -m state --state ESTABLISHED            -j ACCEPT

The sysdeps/linux.c code matches the firewall rule set chains information. Remote and local ports are assigned based on whether you are on the INPUT or OUTPUT chain so the outbound tests in the monitor work correctly. FORWARD and USER chains are arbitrarily chosen to be input style chains for port remote/local assignment.

If the rule set doesn't specify ports, then the range will be 0 to 65535.

The iptables information is not modified. It would have been handy to just zero the counts so you could just track changes, but that would have been impolite, so it tracks its own history. The first time a rule is read, its history is saved and its information is sent on to the monitoring process. After that, information is only passed out of the iptables analyzer if the packet or byte count changes for the same chain/ target/ line/ and local and remote target port. When running the server version, this reduces the load somewhat for infrequently used rules.

The server will try to automatically start a new history chain if the firewall is reloaded. This does take additional RAM, so it is best to not be making massive changes to the firewall. This also permits multiple rules to exist to describe access to a particular service, while maintaining separate history of bytes and packets for each.

When the data reaches the monitor, it goes through a similar analysis to that of the hit counters. If the rule ends up matching a definition, then the byte and packet counts are updated.

As of 2.2.7, the patches to the configuration screen also allow you to rename the krells and will track the Hit, Packet Count, or Byte Count by prefixing an H-, P-, or B- to the label of the krell. This frees up more space in the display area itself. Finally, this patch also includes the ability to specify an interface such as all, ppp0, eth0, eth1, etcetera for matching in the rule set.

There are some special port numbers that have been added:

  • -1 is used if you want to monitor rules with QUEUE targets.
  • -2 is used if you want to monitor rules with RETURN targets.
  • -3 is used if you want to monitor rules with DROP targets.
  • -4 is used if you want to monitor rules with LOG targets.

2.2.7 also adds the following special port numbers:

  • -5 is used for NEW packets.
  • -6 is used for RELATED packets.
  • -7 is used for ESTABLISHED packets.
  • -8 is used for ESTABLISHED/RELATED packets.

These can be used in addition to any specific port monitoring that may be requested.

The software attempts to account for generic type portions of rules and not allow those to interfere with services running in the unprivileged port area. If the port set is 0:65535 or 1024:65535, then your data point range on the krell must match for the data to be counted. Otherwise, the data will be counted toward your krell if their is an intersection in the range of the port specified and the krell specification. This may require more processing than now exists as well, but seems to work OK so far.

The first hit on a rule in the monitor is never recorded, as it can be an arbitrarily high initial value. It simply starts its own history log for the krell. After that, differences are tracked into the minute and hour totals.

Issues with the existing inet operation with GKrellM

GKrellM is a useful monitoring tool for many operating systems. The only spot where I found it somewhat lacking was its support for internet monitoring.

  • The active connections system file was only scanned periodically. Connections that came and went at a quicker rate than the specified scanning interval were missed completely.
  • Lowering the minimum scan interval led to some interaction problems with some operating systems, and still didn't solve the dropped connection problem.
  • If you wanted to dynamically view the load a particular service was placing on your internet connection, there was no way to measure this when a single persistent connection could generate random loads and perhaps be kept alive for long periods of time.
  • The file provides only TCP information.

There are many other TCP/IP monitoring tools that can provide these statistics. However, I was interested in adding these features into GKrellM as an option. To get the source data for the krells, the byte and packet count outputs from iptables are monitored. Using the firewall output instead of relying on a snapshot of a dynamic system file guarantees that the load can be accurately measured, assuming, of course, that the firewall is always enabled. Since the firewall is always monitoring packets and bytes, the inet update frequency can be drastically reduced if needed.

Root privilege warning

iptablesrestricts the listing function, used to gather the byte and packet count information, to the root user to ensure that the rule set is not visible to unauthorized users. If you want to try out these patches, you must be comfortable running either gkrellm or its server gkrellmd process as the root user. If you don't use gkrellmd, then only the root user would see any packet or byte count information while running gkrellm. Other users would just see flat-line displays as the iptables program gives empty output for them. If you use gkrellmd and run it as root, then any user with access to gkrellm could monitor traffic on any port a
firewall rule specified. Each installation must decide whether the monitoring information is sufficiently useful to open up root access to gkrellmd or run gkrellm as root. I saw no particular risk for this at my installation:

  • I run the server gkrellmd process, unadorned by third party plug-ins.
  • gkrellmd connections are limited to the host it is running on by configuration.
  • Should there be some problem I don't know about in its configuration processing directives, firewalls don't allow access to the port on the server or at the external interface anyway.
  • Data being passed on the network from gkrellmd to the monitoring gkrellm process is encrypted via SSH tunnelling to prevent the rule set from leaking via any unexpected network traffic sniffing.
  • My environment is such that the system allowed to monitor the server process has no un-trustworthy users.

I don't claim that the above list is all encompassing of the security issues adding iptables support to GKrellM. If anyone would like to raise any other issues, feel free to send some feedback to me via my website contact form.

Other issues about using the patch

There are other issues in using this patch. The packet and byte count information is supplied as 64-bit values. The existing GKrellM software makes use of 32-bit ints to track its information. Since larger sites than mine could have peak loads that swamp out a 32-bit signed value in the byte count or perhaps the packet count for some really wild site, I have changed the internals of the charting features of GKrellM to use 64-bit values.

I have had some discussions with the author of GKrellM about this. He mentioned the possibility of pre-scaling the output from the byte and packet counts as a way to keep the 32-bit API intact, along with the attendant risk of having more quiet periods of service usage zeroed if a peak load was encountered that was out of the 32-bit range. I felt that it was better at this point to provide the patch as a full 64-bit service, rather than adding a pre-scaling feature to debug, but as the software matures, other options may become available. My personal preference would be to configure the internal krells as 64-bit, with their own set of subroutines to access and store the data values and replace the 32-bit subroutines with wrappers that transfer the data values to and from their larger internal counterparts. The inet routines (or others needing 64-bits) could then call these internal routines directly.

Regardless of the future path GKrellM and this patch take, currently this patch makes an API change which could break other charting plugins. I have tried to cast the other spots in the software that store, report, save, or restore data to work with the 64-bit ints, but may have missed something.

The packet and byte count operations require the use of iptables as the firewall tool. Other firewalls have similar reporting features. If anyone would like to pass along their specifics, I might try to add them as an option.

The iptables support is only in the sysdeps/linux.c module, but could be cut and pasted with perhaps a binary location change to any other O/S listed that provides the required features. Other earlier versions of iptables may not provide the same data formatting.

The function can only provide information about rules that exist in the firewall. It is common to group several rules together to make a smaller rule set. Where rules are grouped, only aggregate information is available. If you want to see specific service information, you must make separate rules for each inbound service and its return data feed and each outbound service and its reply. Increased numbers of rules can increase the firewall maintenance cost and does have a slight impact on performance. On the other hand, if you are running a site that has huge loads, you probably have dedicated
computers for each service anyway, so each computer's firewall rule set is probably not that big to start with. Of course, you probably have some nice monitoring packages as well so won't be interested in this feature for GKrellM.

If you are running virtual services such as virtual hosts with Apache, that are sorted out based on information in the packets rather than specific IP addresses or ports, there is no way to sort out loads to particular virtual services. You resolution is limited to the port accesses through the firewall.

The existing user configuration files have additional information for the inet monitors and graphs.

Wish list

A bi-directional check box might be handy to monitor all inbound and outbound web traffic on a single krell.

There are now six graphs to configure instead of two. It would be nice to eventually have the visual aspects of the internet krell split apart from the scaling information in the dialog so that you could configure line styles, inversions, split and split ratios once for all graphs. Alternatively, an apply to all check box with appropriate callbacks would be handy.

2.2.7 update - I added callbacks to all the graphs that should set all graphs to react similarly to your changes.

Other changes

With the 2.2.7 patch there are some other changes to the mail code and x11 code simply to take care of complaints of signedness in the compilation process. There is a scaling fix that is done and some changes to the hour chart interface to try to handle transparent backgrounds better in the internet charts.

2.2.9 provides a clean patch where some of these issues have been resolved in the core code.

If you are interested, all the patches are available at GKrellM Patches. Use the password gkrellm to access the download page.