Watcher-History

Wide use of IPSETs.

In Watcher 1.3 the Watcher no longer places DROPs directly into the INPUT chain of the firewall with iptables commands.

The 'iptables' command locks the firewall (xtables in the  kernel) for a transaction and introduces wait-cycles for transactions of other processes like Watcher modules and dynloaders. That slows down Watcher's operation which is now consequently avoided by the use of IPSETs.

• This essentially inceases the tracking speed of the modules tremendously.
• Dynloaders and modules do their job completely transparent; i.e. the underlying firewall is entirely unaffected from IPSET updates and reloads.

Dynloaders and modules create their own IPSETs 'on-the-fly' when they start and use their dynloader and/or module name to drop in firewall DROPs. This is completely dynamic and transparent to the 'xtables' firewall managed by 'iptables'.

Benefits:

• Cleanups in the firewall after database expiration of the modules are much easier to accomplish than with the 'iptables' command.
  A database expiration in the module now takes only seconds.

The 'in firewall' part of the "Watcher-Report" was rewritten to view the state of IPSETs.

The upcoming 'Net Filter Tables' (NFT) firewall management system will be addressed in a future master release; e.g. Watcher 2.x planned for June 2022. (see the Watcher roadmap page)

New Watcher module "WatchWB" (WEB service intrusion detection & prevention)

Watcher 1.3 will come with a new module "WatchWB" for the web service. This completes the trilogy of protection tools needed by a usual 'root-server' or datacenter server in a DMZ.

The WatchWB module is the most complex module in the trilogy. This has several reasons:

1. A Web server can service multiple instances (vhosts/sites)
2. Each instance can run with a specific service software from a variety of CMS, Wiki, Shopping system or other kind of informational service behind such an instance.

The rule system in the WEB module needed some extention to honor this natural increase of demand. The normal 'filter' function was therefore extended  by rule-sets that are either:

• site specific ... or ...
• common (for all instances)

So the old rule "more specific before more common" still applies. But the *.rule files are now seen as site-specific rule-sets that have its own directory below ../rules with a directory 'Common' the hold the common rule-set with rules applicated for all instances after the site-specific rules were tracked..

This extended concept for the rule handling provides:

• multiple instances
• site-specific rules (Joomla, WordPress, Typo3, any shopping system, etc.)

in the WatchWB module.

A new database table 'affairs_by_ip is written by the WEB scanner in the module that tracks the instance and 'attack class' for resonable statistics, that shows 'which instance was attacked by what'.

Integration of SuSE Linux & Debian (and its offsprings like Ubuntu)

Release 1.3

For the field tests with state 'pending' I am looking for testers with the corresponding system.
Any kind of assistance is greatly appreciated and honored with a free subscription to the support area.
If you would like to assist drop a message through the 'Contact form' on the main page

                       https://comserve-it-services.de/en

Support is available in the support section  under https://watcher.comserve-it-services.de for registered users.

Note on 'ipset' in Debian/Ubuntu & SuSE distributions

Investigation of Linux distributions revealed that even newest SuSE and Debian based Linux distributions deliver IPSET versions 6.x with protocoll level '6'. This is pretty much out-dated and is taken as 'insufficient' in order to run Watcher. IPSET release 7.x with protocol level '7' is out for years now. Even the 'old-fashioned' CentOS-7 comes with an IPSET Rev. 7.1 at protocoll level '7'.