Date: Wed, 16 Jul 2003 09:26:50 -0600
To: shorewall-users@lists.shorewall.net
From: "Rodolfo J. Paiz"
Subject: [Shorewall-users] HOWTO: Temporary dynamic blocking with Shorewall
	and Portsentry

Hi, all:

This is just a note and suggestion, not a question; but I really like this 
system and thought it might be useful to others so I decided to share. Hope 
it helps someone, and comments or suggestions are always welcome.

         1. Overview: Shorewall accepts traffic on ports that I consider 
"hostile" (i.e. ports on which I would NEVER expect to see connections) and 
redirects them to a single high port on which Portsentry is listening. 
Portsentry in turn uses a custom shell script to block the offending IP 
address (using the "shorewall drop" command) and schedule an "at" job for 5 
days later unblocking the offender (using the "shorewall allow" command). 
This ensures that I don't end up with 2000 rules in iptables or get blocked 
off from a large portion of the Net; also, since most hacks are attempted 
from dial-up connections, permanent blocking serves no real purpose anyway.

         2. The relevant rules from /etc/shorewall/rules:

# Redirect certain "hostile" ports (ones we don't use and where probes are
# immediately considered to be hostile in nature) to port 49999 where
# Portsentry is configured to block the attacking IP addresses. Note that
# addresses which are blocked will be dynamically unblocked five days later.
#
# PORTSENTRY.
REDIRECT        net     49999           tcp     23
REDIRECT        net     49999           tcp     110
REDIRECT        net     49999           tcp     111
REDIRECT        net     49999           udp     111
REDIRECT        net     49999           tcp     143
REDIRECT        net     49999           tcp     515
REDIRECT        net     49999           tcp     1080
REDIRECT        net     49999           tcp     1433
REDIRECT        net     49999           tcp     1434
REDIRECT        net     49999           tcp     3128
REDIRECT        net     49999           tcp     12345
REDIRECT        net     49999           tcp     27374

         3. The relevant lines from /etc/portsentry/portsentry.conf:

TCP_PORTS="49999"
UDP_PORTS="49999"
BLOCK_TCP="2"
KILL_RUN_CMD_FIRST = "1"
KILL_RUN_CMD="/root/bin/portsentry.temp.block $TARGET$ $PORT$"
SCAN_TRIGGER="0"

         4. Set up portsentry to run in "standard mode" for both TCP and 
UDP. Do NOT use the advanced or stealth modes.

         5. My shell script to drop and then later allow the attacking IP 
address:

#!/bin/bash

# portsentry.temp.block
# Rodolfo J. Paiz <rpaiz@simpaticus.com>
# version 2003.07.01

# Usage: portsentry.temp.block <bad_ip> <bad_port>

# portsentry.temp.block is a small script intended to be run by portsentry
# when its sensors are triggered. It uses iptables (more specifically, it
# uses the dynamic blacklisting capabilities of Shorewall) to deny all
# access to the server from the attacking host. Then, a set time interval
# later, the block is removed.
#
# This script can also be run directly if desired, although this is not a
# common form of usage.
#
# Experience shows that most attacks come from dial-up IP addresses, so
# blocking them permanently gives no real benefit, and removing them
# keeps our blocking table from becoming huge.

# Set appropriate variables (easy to customize on different systems).
DROP_INTERVAL_DAYS=5
HOSTNAME="Apollo"
NOTIFY_EMAIL="rpaiz@simpaticus.com"

# Get the attacker's IP address and probed port from the command
# parameters. DO NOT CHANGE THIS!
BAD_IP=$1
BAD_PORT=$2

# Block the bad guy.
/sbin/shorewall drop $1
/sbin/shorewall save

# Unblock him X days after midnight tonight.
echo "/sbin/shorewall allow $1" | at midnight + $DROP_INTERVAL_DAYS days

# Mail me a note to notify me of each block.
# TEMPORARILY ENABLED.

echo "Portsentry has blocked $BAD_IP (`host $BAD_IP`) on `date`, \
from now until $DROP_INTERVAL_DAYS days from midnight tonight. At this \
point `at -l | wc -l` hosts are blocked ." | mail -s "$HOSTNAME: \
Portsentry blocked $BAD_IP on $BAD_PORT" $NOTIFY_EMAIL

         6. Test the system!!! Make sure it works properly!!!


-- 
Rodolfo J. Paiz
rpaiz at simpaticus.com