= How to integrate autofwd with Nagios = The [[http://www.digitalmages.com/projects/autofwd/|autofwd]] tool is a very simple, portable and effective solution to protect a server (or a PC) from brute force password attacks, usually attempting to break into the computer via sshd but, generally speaking, to force any local service via password guessing. Basically autofwd, upon detecting an attack, '''bans the offending IP''' (either v4 or v6) and then '''notifies the administrator''' with a mail message. This behaviour is normally enough but, if you have already in place a working Nagios monitoring service, you may want ''to notify the Nagios console about every ban and unban action carried by autofwd'', in order to centralize to the unified Nagios console these kind of alarms, too. In this post I will explain how to do this. In the following text I will assume that you already have a working installation of autofwd in place and that there is, on your network, a Nagios version 3 server, where a [[http://community.nagios.org/2009/06/11/nagios-setting-up-the-nsca-addon-for-passive-checks/|nsca]] process is listening for passive commands. === Step 1: install the nsca client part on the host where autofwd is running === You can [[http://exchange.nagios.org/directory/Addons/Passive-Checks/NSCA--2D-Nagios-Service-Check-Acceptor/details|download]] the source of nsca and compile it or, on a debian-derived linux distribution, you just enter in a terminal: '''apt-get install nsca''' and the work is done. Now you have the '''send_nsca''' executable installed somewhere in your file system and that's all we need from the nsca package. === Step 2: configure autofwd === If you haven't introduced any enhancement to your base autofwd installation, the operational part your actual autofwd.conf should look something like this: {{{ # Ban IPv4 Cmd: Command to execute to ban an IP Ban IPv4 Cmd: /sbin/iptables -I INPUT -s __IP__ -j DROP # Unban IPv4 Cmd: Command to execute to unban an IP Unban IPv4 Cmd: /sbin/iptables -D INPUT -s __IP__ -j DROP }}} The same applies for IPv6 so I wont copy it again. In order to let Nagios know that a banning/unbanning action has been performed, we have to operate in the Ban Cmd sections above, which can be modified as follows (pay attention to the absolute path of the commands and customize as necessary for your environment): {{{ #! #!/bin/sh # ban_check: wrapper to extend autofwd actions, alerting Nagios # To be run on the same host where autofwd is # # Requires: nsca package (for send_nsca) and a working Nagios server # # Author: Niccolo Avico (niccolo.avico@gmail.com) # # Usage: ban_check { ban4 | ban6 | unban4 | unban6 } # # ban4 (bans as an IPv4 address) # ban6 (bans as an IPv6 address) # unban4 (unbans as an IPv4 address) # unban6 (unbans as an IPv6 address) # TAG_IP=$2 USAGE="Usage: `basename $0` { ban4 | ban6 | unban4 | unban6 } " return_code=-1 NSCA_CONFIG=/etc/nagios/send_nsca.cfg # LOCAL_HOSTNAME corresponds to the name by which this host is known to Nagios LOCAL_HOSTNAME="HS-Rustica1" # NAGIOS_SERVER is where the Nagios console is running in your network NAGIOS_SERVER=10.1.0.2 # NAGIOS_SERVICE is the name by which Nagios knows autofwd NAGIOS_SERVICE="autofwd" if [ $# -ne 2 ]; then echo "${USAGE}" >&2 exit 1 fi # Exit if send_nsca package is not installed if [ -x /sbin/send_nsca ]; then echo "Missing package send_nsca." >&2 exit 4 fi case "$1" in ban4) iptables -I INPUT -s $TAG_IP -j DROP return_code=2 action="IPv4 ${TAG_IP} banned." ;; ban6) ip6tables -I INPUT -s $TAG_IP -j DROP return_code=2 action="IPv6 ${TAG_IP} banned." ;; unban4) iptables -D INPUT -s $TAG_IP -j DROP return_code=1 action="IPv4 ${TAG_IP} unbanned." ;; unban6) ip6tables -D INPUT -s $TAG_IP -j DROP return_code=1 action="IPv6 ${TAG_IP} unbanned." ;; *) echo "${USAGE}" >&2 exit 3 ;; esac # Now inform Nagios about this action: # pipe the service check info into the send_nsca program, which # in turn transmits the data to the nsca daemon on the central # monitoring server /usr/bin/printf "%s\t%s\t%s\t%s\n" "$LOCAL_HOSTNAME" "$NAGIOS_SERVICE" "$return_code" "$action" | /usr/sbin/send_nsca -H $NAGIOS_SERVER -c $NSCA_CONFIG exit $? }}} Please note that we want to send Nagios a ''CRITICAL'' (return_code=2) alarm when autofwd will ''ban'' an attacker and a ''WARNING'' (return_code=1) alarm when autofwd will ''unban'' it (if autofwd.conf allows to do so). Let's put the wrapper in a file called /etc/nagios/ban_check and make it executable. Before using it, you must customize the wrapper with the correct IP address of your Nagios server ($NAGIOS_SERVER) and put the Nagios short name for the host ($LOCAL_HOSTNAME), as it is defined in your Nagios console. === Step 4: configure Nagios for the autofwd service === Up to now we have prepared the ''client side'' of the integration. In order for Nagios to process autofwd actions and display them as alarms for you host, we now move onto the Nagios server and define a new Nagios service, called autofwd (as it is named in the wrapper); for it to work you can copy the following definitions in a new ''autofwd.cfg'' file. {{{ define hostgroup { hostgroup_name autofwd-servers alias Server equipped with autofwd } define service { hostgroup_name autofwd-servers service_description autofwd check_command return-ok ; always return OK use generic-service max_check_attempts 1 ; immediately put in HARD state active_checks_enabled 0 ; only passive checks passive_checks_enabled 1 is_volatile 1 ; EVERY check is an alarm check_freshness 0 ; don't check for stale state flap_detection_enabled 0 ; by definition it will flap CRITICAL/WARNING notification_options c,r notifications_enabled 1 notification_interval 0 } }}} For a further exaplanation of the parameters, please follow the [[http://nagios.sourceforge.net/docs/3_0/objectdefinitions.html|Nagios reference]] page. === Step 5: on the Nagios server, include the new service in your host definition === In the ''define host'' section of your Nagios configuration regarding the monitored host, add ''autofwd-servers'' to the list of hostgroups to which the host belongs. Example: {{{ define host{ host_name HS-Rustica1 alias POP ninux.org at Rustica hostgroups openwrt-servers, http-servers, ssh-servers, autofwd-servers active_checks_enabled 0 address 10.1.0.22 use generic-host contacts gilgamesh register 1 } }}} === Step 6: test === Restart the Nagios service and, if everything went ok, you should see in the web Nagios console a new service called ''autofwd'', listed with the other services checked for your host. To check that the communication between client and server works you can now monitor the Nagios log file for autofwd notifications; log into the Nagios server and just issue on a terminal: {{{ nagios-server:$ tail -f /var/log/nagios3/nagios.log | grep autofwd }}} Open another terminal and log into the monitored host. Issue a ban_check command about a fake detection: {{{ host:$ ban_check ban4 ''fake-ip'' }}} You should see immediately, from the Nagios log, a diagnostic message received from send_nsca, confirming that the command has been sent to the nagios server. In fact the first terminal should now display a PASSIVE CHECK notification about you host and the banning action just performed; at the same time the Nagios console shall put in a CRITICAL state the autofwd service for that host. If this is your case, CONGRATULATIONS: your integration from autofwd to Nagios is done! '''IMPORTANT NOTE:''' due to the behaviour of no volatile services in Nagios, this CRITICAL state will never be reset automatically by the system (and this is what we want, indeed): if nobody takes care of the alarm, the autofwd process will eventually ''unban'' the IP (if instructed to do so) and the service state will move from CRITICAL to WARNING. The only way to reset to OK that state is to issue a manual command to Nagios, submitting a passive service check from the web console. This policy should grant that no attack attempt to your host shall be underestimated or misnotified.