ComServe IT-Services Think IT, Plan IT, Do IT!

Nav view search


New in Watcher 1.2 (engl.)

The modularization in Watcher 1.x opened pathways to other improvements. In particular better separation of service relation could be worked out.

Login and mail attacks have practically nothing to do with one another.

For instance '(Distributed) Denial of Service' (DDoS/DoS) are practically not subject for the 'login' (SSHD) service. On the other hand the mail service (MTA) is subject of 'SPAM spreaders' but not a way to bring the system under control by attackers by gaining 'super-user access'. In between there are mailbox attacks. By break-in into mailbox accounts attackers searching for alternate ways to spread SPAM by abusing legal mail user's mailboxes and have a perfect way to hide behind a legal way to spread SPAM, SCAM & PHISHING mail. So there are quite different intentions behind each type of attack.

Dynamic rule system for modules ...

Different attack types go to different services that provide completely different log-messages on the system through the system logger (rsyslog or syslog-ng).

For instance SSHD provides specific messages that are going to the "auth.*" facilities in the system logger, whereas the MTA service (e.g. PostFix) logs to the "mail.*" facilties of the system logger with its specific messaging style.

Until Watcher 1.1 all rules of a specific module were hard-coded in the module's code and were related to the specific messaging of the particular service. Namely: SSHD, PostFix & DBmail - in our case.

The drawback was, that adding and/or changing a rule needed to change the 'rule section' in the module's code to be prepared for other message output - in particular for the mail service (MTA; Postfix) and mailbox services (DBmail, DoveCot, Exim,...)

Once a rule was coded it was nailed to the specific message output that a certain service provides to the system logger.

To overcome this restriction all rules were outsourced into a module's sub-directory 'rules' and split into separate and number-prefixed files with the extention '.rule'.

[root@vmd28527 WatchMX]# tree rules/
├── 100-NXDOMAIN.rule
├── 110-NXDOMAIN-TLS.rule
├── 120-NXDOMAIN-SSL.rule
├── 150-Host.rule-disabled
├── 170-NOQUEUE.rule
├── 180-SSL-frauds.rule
├── 300-MB-pass.rule
├── check-all-rules
├── check-rule
├── superflous_map
├── Template-rule
└── Test


Now all rule files 'XXX-<rule name>' can now be configured for a specific service (PostFix, Exim, Qmail, ...) that is in use on a particular system. The number prefix allows to level the order of the rule, since sometimes the order of the rule counts; i.e. a more specific rule must come before more common rule.

 Wrong! Right!
Pattern=": Failed login for"
[ ........ rule decision ........ ]
Pattern=": Failed login for root"
[ ........ rule decision ........ ]
Pattern=": Failed login for root"
[ ........ rule decision ........ ] 
Pattern=": Failed login for"
[ ........ rule decision ........ ]

You may place multiple rules in a single *.rule file. But regardless whether single rules are kept in separate files or multiple similar rules are collected in just one rule file the "more specific before more common" rule applies when writing rules.

Anyway. This way the rules for a specific system with specific services can be adapted to all thinkable circumstances.

For more detailed explanations see the manual on modules.

ipsets ...

'iptables' is fairly old but is still a common standard in particular on older/existing systems.

Unfortunately 'iptables' has a few drawbacks  relating to the ordering of firewall rules which turns out troublesome if it comes to deleting a firewall rule dynamically.

So with Watcher 1.2 the use of 'ipset' was introduced.

Modules no longer fire DROPs with iptables rules into the firewall:

$IPTABLES  -I INPUT -s $IP  -j DROP ...  


Instead the module fires the DROP into an 'ipset' that was prepared by the Watcher master:

ipset -exist add tarpit  $IP timeout xxx  ... below $MAX_AFFAIRS
(timed as 'affairs * timeout value'; i.e. increasing with each "affair")
ipset -exist add custody  $IP  ... after the DROP was recorded in the database

This keeps the order of iptables rules static, since the iptables rules are not re-indexed with every inject of a DROP rule.

The result is a much better performance for DROP actions.


Utility scripts "Blacklist" & "Whitelist" ...

With introduction of IPSETs the management of individual blacklisting and whitelisting became essentially easier.

In order to (re)load your individual  'whitelist' and 'blacklist' files manually (or by CRON) after changes were made to them the two utility scripts:

  • Blacklist
  • Whiteliste

are now provided in the Watcher MASTER_PATH for Watcher administrators.


Note, that the individual 'blacklist' & 'whitelist' files are not automatically provided by the Watcher system preparation.
There are *-sample files in the MASTER_PATH, that can be copied and modified to your needs.

It is recommended, that at least a whitelist file should be provided which outlines the IP address of the local machine!

Having made changes to the blacklist or whitelist file run the corresponding utility script to have the related firewall entries updated.

    # ./Blacklist
... or ...
    # ./Whitellist

The scripts do not take an argument as they pick the corresponding 'blacklist' & 'whitelist' files automacically to refresh a related IPSET without any need to restart the entire Watcher.

[root@vmd28527 Watcher]# iptables -nL INPUT | head
Chain INPUT (policy ACCEPT)
target prot opt source destination 
DROP   all -- match-set highjackers src
DROP   all -- match-set custody src
DROP   all -- match-set tarpit src
DROP   all -- match-set blacklist src
ACCEPT all -- match-set whitelist src
DROP   all -- /* nixspam */
DROP   all -- /* nixspam */
DROP   all -- /* nixspam */ 

... and so on ...


If you may want to check the changes or the state of individual whitelisting & blacklisting you can check with the ipset command:

[root@vmd28527 Watcher]# ipset list blacklist
Name: blacklist
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 1528
References: 2
Number of entries: 12




Dieses System verwendet Cookies, weil das für den Betrieb eines Online-Shops unverzichtbar ist. Ich verstehe, dass Cookies auf meinem Computer Notizen über den Kontakt mit der besuchten WEB-Seite(n) hinterlegen und akzeptiere dies.