BOT - Tips and Tricks

This page shows you some Tips and Tricks for BOT administration:

Copy the BOT config from one IPCop to another one

Reduce Firewall-Log messages


ICMP-Types (Ping / Pong)

Copy the BOT config from one IPCop to another one

There are scenarios where it is necessary to copy the BOT config from one IPCop to another IPCop:

  • Replace an old IPCop installation with a new IPCop installation on different machines.
  • Copy the BOT config from a test machine to the production machine.
  • Prepare a swap machine with the production BOT config.
  • etc.

The BOT installation / deinstallation routine automatically saves and restores the config on (de-)installation. See Installation (especially section 'Uninstall BOT').

It is very simple to copy the BOT config from IPCop 'A' to IPCop 'B'. There are two ways to copy the files:

  • If you have BOT installed on IPCop 'B' uninstall first.
  • You uninstall (and immediately re-install) BOT on IPCop 'A' and the current config is stored in /var/tmp/bot_conf/<BOT_VERSION>.
  • You can now copy this directory to IPCop 'B'.
  • Because of the reinstall of BOT you have to enable BOT again on IPCop 'A'.
  • Or you create a directory /var/tmp/bot_conf/<BOT_VERSION> on IPCop 'B'. Make sure you replace the placeholder (<BOT_VERSION>) in the directory name with the BOT version which is installed on IPCop 'A'! The restore of the config on IPCop 'B' will only work correcly when the directory is named with the correct BOT version! For BOT version 2.3 the full path is '/var/tmp/bot_conf/2.3', for version 2.2.2 it was '/var/tmp/bot_conf/2.2.2' and so on.
  • Copy all files in /var/ipcop/fwrules from IPCop 'A' to /var/tmp/bot_conf/<BOT_VERSION> on IPCop 'B'.

The config is on IPCop 'B' but not yet loaded into BOT. There is one simple way to load the config into BOT (also see Installation, section 'Uninstall BOT' for a description of the save / restore mechanism):

  • REMINDER: If BOT is already installed on IPCop 'B' you have to uninstall BOT before copying the config from 'A' to 'B' otherwise the copied config will be overwritten when un-installing the previous BOT installation!
  • Install BOT on IPCop 'B' now. The config (that you have previously copied to /var/tmp/bot_conf/<BOT_VERSION>) will be restored on installation.

The config from IPCop 'A' is copied to IPCop 'B' now.

You have to verify the BOT config via the WebGUI and change the Admin MAC and the HTTPS port in BOT settings (if necessary).
The BOT config uses variables, e.g. if the 'Green Network' was 192.168.0.* on IPCop 'A' and is 10.0.0.* on IPCop 'B', BOT looks-up the current values of the variable 'Green Network' and uses 10.0.0.* now. You don't have to change the config to suit the settings of IPCop 'B'.


Reduce Firewall-Log messages

A standard IPCop installation logs every packet which is blocked by the (default) firewall rules. The idea behind this is to see what is blocked and get hints when something (maybe Port-Forwarding or External-Access) is not working as desired. You can see the blocked access attempts and will have an easier troubleshooting.

But now the problem: there are many unwanted packets which are blocked (hey that's why we have a firewall in the first place) and logged. This logging will make the firewall log grow very fast. On a default IPCop you will easily have more than 10000 log entries per day! This means two problems:

  • The logs you want to see for troubleshooting will be hidden by the many unwanted logentries.
  • Many firewall log entries means bigger logfile size and more needed storage. This is an issue on systems with limited storageplace, especially on CF-based systems where there is additionally the limited number of write-operations to the CF-card.

As the unwanted packets are mostly directed to only a few services, it's easy to reduce the log entries to a minimum. There are only a few firewall rules needed which block those traffic but don't log it. With those firewall rules applied the number of log entries can be reduced from over 10000 to under 100 per day!

So now to the practical part: which BOT rules are needed to reduce the firewall log.

The following example shows how to avoid the logging of NetBios and TCP 445 where all the skript-kiddies try their luck. First of all we create two new service groups:

  • Deny Group: This group contains services which shouldn't be logged on the red interface. For example the service 'microsoft-ds' which is TCP 445, this service shouldn't be blocked on all (including Green and Blue) interfaces as the IPCop WebGUI is running on this port and wouldn't be available anymore.
  • Deny everywhere: This group contains services which should be blocked on every interface. This group will contain NetBios services.

These two service groups will be used in some BOT deny rules. One rule with source interface 'Any' and service group 'Deny everywhere' and one rule with source interface 'Red' and service group 'Deny Group'. These rules should be in 'Other Network/Outside' and also in 'IPCop access'. Normaly it should be enough to have the rules in 'IPCop access', but I have nevertheless seen log entries on those services when 'Other Network/Outside' was missing. So when the services are blocked in 'Other Network/Outside' you will (should) not see those services in the firewall logs. When the rules are at the beginning of the rule sequence the packets will be blocked as soon as possible.

The new "reduce firewall log" rules are marked with a red rectangle in the next screenshot:

When you look into your firewall logs and see many hits on one service, you can add this service to one of the two deny service groups and the firewall logs will not contain those hits anymore.



If you want to use filesharing like Torrent or want to play onlinegames you need a special BOT rule. You need a special rule because every Torrent server can use a different port(-range) and many onlinegames use a bunch of different TCP and UDP ports. So when using BOT you would have to create a rule for every port or you would have to create a service group with all those ports. This will work but is time-consuming and complex.

A simpler (and less restricted) way is to allow all high ports (1024 - 65535). The Well Known Ports (0 - 1023) will still be under control of BOT, but you don't need a big service group or a lot of BOT rules. As long as you play onlinegames or use Torrent, you enable this special rule and afterwards you disable this rule and BOT will controll the whole portrange (0 - 65535) again.

Custom service (for high ports):

BOT Filesharing/Gaming rule (marked with a red rectangle):



ICMP-Types (Ping / Pong)

Allow Ping in BOT rules is easy but a bit tricky, you have to define a custom service with ICMP (and more restricted with ICMP-Types if wanted).

As an example we define two custom services with ICMP-Types 'echo-reply (pong)' and 'echo-request (ping)' and one service group with these two custom services.

Custom services:

Service group:

When you want to allow a PC to use Ping, you have to create a BOT allow rule and select the service group 'Ping Group'. For Ping to IPCop you have to select 'IPCop access', for Ping to Internet or Ping from Green to DMZ/Blue you have to select 'Other Network/Outside'. That's all, the PC should be able to use Ping now.


Tips 'n' Tricks last changed 21. March 2006

IPCop - The Bad Packets Stop Here

BlockOutTraffic - The Firewall WebGUI Addon for IPCop

  Created 2006 by dotzball | Design by wintermute