Shorewall users - Jul 2003 - Fwd: HOWTO: Temporary dynamic blocking with Shorewall and Portsentry

Hi,

Is there any special configuration that needs to be
done to shorewall in order to have port sentry able to
work as described here?  I would like to use this
feature with my setup, but do not know shorewall very
extensively yet, I actually just installed it a week
ago and just got it up and running ;-)

Thanks.

Bryan H.
> 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
> 
> # 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@simpaticus.com
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

On Thu, 2003-07-17 at 01:01, Bryan H wrote:
> Is there any special configuration that needs to be
> done to shorewall in order to have port sentry able to
> work as described here?  I would like to use this
> feature with my setup, but do not know shorewall very
> extensively yet, I actually just installed it a week
> ago and just got it up and running ;-)
It is all explained below.  The "special" configuration is the
redirect
of traffic from the ports you want to monitor to the port on which
portsentry is listening.

Ed
> 
> Thanks.
> 
> Bryan H.
> 
> > 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
> > 
> > # 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@simpaticus.com
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
http://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm
-- 
http://www.shorewall.net       Shorewall, for all your firewall needs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url :
http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030716/3708e34a/attachment.bin

At 7/17/2003 01:23 +0800, Ed Greshko wrote:
>On Thu, 2003-07-17 at 01:01, Bryan H wrote:
>
> > Is there any special configuration that needs to be
> > done to shorewall in order to have port sentry able to
> > work as described here?  I would like to use this
> > feature with my setup, but do not know shorewall very
> > extensively yet, I actually just installed it a week
> > ago and just got it up and running ;-)
>
>It is all explained below.  The "special" configuration is the
redirect
>of traffic from the ports you want to monitor to the port on which
>portsentry is listening.
Note that you can set portsentry to listen on any port you like. I selected 
49999 as a port on which nothing usually listens, so that even if 
portsentry fails connection requests will not find the expected daemon 
listening (even if said daemon is installed and functioning). Defense in 
depth, with independent layers.

For example, at home I run a squid proxy on port 3128, with the rule 
"accept loc fw 3128" allowing access to it. Access from the Internet, 
however, is redirected to Portsentry since no one on the outside should be 
trying to use my ISDN line as a proxy server.


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

> It is all explained below.  The "special"
> configuration is the redirect
> of traffic from the ports you want to monitor to the
> port on which
> portsentry is listening.
So does that basically say that in
/etc/shorewall/rules I would add the REDIRECT and port
number to any ports that I want monitored.  For
instance, if I wanted port 80, 443, 993, 25, and 22
monitored for malitious activity, the REDIRECT would
point them through PortSentry and monitor them, and
block any ip''s that are doing things they shouldn''t? 
I just want to be clear that all I need to say is what
ports to monitor in /etc/shorewall/rules and that''s
basically it?  Thanks for the help.

Bryan Heusmann

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

On Wed, 16 Jul 2003, Bryan H wrote:
> So does that basically say that in
> /etc/shorewall/rules I would add the REDIRECT and port
> number to any ports that I want monitored.  For
> instance, if I wanted port 80, 443, 993, 25, and 22
> monitored for malitious activity, the REDIRECT would
> point them through PortSentry and monitor them, and
> block any ip''s that are doing things they shouldn''t?
> I just want to be clear that all I need to say is what
> ports to monitor in /etc/shorewall/rules and that''s
> basically it?  Thanks for the help.
Yes, that''s basically it...as far as shorewall is concerned.

But, you need to pay attention to the whole document that started all of
this....

The blocking/unblocking is done via the script supplied in the document
and is all covered in the "comments" section of the script.  Please
read
the comments.

Ed

-- 
SARS - The only virus not spread by Outlook
http://www.shorewall.net/  for all your firewall needs

At 7/17/2003 12:16 +0800, Ed.Greshko@greshko.com wrote:
>On Wed, 16 Jul 2003, Bryan H wrote:
>
> > So does that basically say that in
> > /etc/shorewall/rules I would add the REDIRECT and port
> > number to any ports that I want monitored.  For
> > instance, if I wanted port 80, 443, 993, 25, and 22
> > monitored for malitious activity, the REDIRECT would
> > point them through PortSentry and monitor them, and
> > block any ip''s that are doing things they shouldn''t?
>
>Yes, that''s basically it...as far as shorewall is concerned.
>
>But, you need to pay attention to the whole document that started all of
>this....
>
>The blocking/unblocking is done via the script supplied in the document
>and is all covered in the "comments" section of the script. 
Please read
>the comments.
Please note that this setup will block ANY connections to one of those 
ports (not just "people doing things they shouldn''t"). One
single packet or
connection request hits a "hostile" port and BAM!, that IP goes into a
black hole for five days.

If you''re going to consider port 80 hostile, make sure that this is on
a
computer where no valid user would _ever_ try to look at a web page from 
that machine.


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

On Wed, 16 Jul 2003 22:34:04 -0600, Rodolfo J. Paiz <rpaiz@simpaticus.com>
wrote:

> If you''re going to consider port 80 hostile, make sure that this
is on a
> computer where no valid user would _ever_ try to look at a web page from 
> that machine.
I personally wouldn''t consider port 80 hostile unless you can tolerate 
large set of blackholed IP addresses; there are an unbelievable number of 
web crawlers out there...

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Thu, 2003-07-17 at 07:54, Rodolfo J. Paiz wrote:
> On the other hand, when I have a standalone web server 4000 miles away from
> me in a dedicated data center which has done nothing but serve web pages 
> for the last two years, I consider anyone approaching my 3128 (squid), 1080
> (socks proxy), 1433 (MS SQL server), or 23 (telnet) ports to be definitely 
> hostile and worth blocking immediately.
I agree.

One more comment about the HOWTO -- people should watch the number of
blacklisted IP addresses ("shorewall show dynamic") and if it grows
large, consider changing the 5-day blocking interval to something more
on the order of an hour.

Every packet entering the firewall (on *any* interface) is checked
against every dynamically blacklisted host. That makes a large set of
blacklisted hosts quite expensive.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

At 7/17/2003 08:00 -0700, Tom Eastep wrote:
>I agree.
>
>One more comment about the HOWTO -- people should watch the number of
>blacklisted IP addresses ("shorewall show dynamic") and if it
grows
>large, consider changing the 5-day blocking interval to something more
>on the order of an hour.
For the sake of reference, the seven servers on which I run this system 
rarely accumulate more than 60 hosts in the blacklist. That''s how the 
five-day period evolved, as a concern over not blocking too many people. 
The key to happiness is really to clearly define those ports on which you 
are willing to block even the slightest sign of activity, and only block 
those. That way you keep the false positives down to a minimum.

One hour is too short, since when we started out we tried very short 
intervals and found that frequently both the machines and humans who were 
portscanning or probing a block of IP addresses were still in activity, so 
that led to multiple blocks and more vulnerability. I''d say the minimum
recommended is roughly one day, such that the attacker has time to hang up 
his dial-up connection and move elsewhere.

If enabled, the bottom part of the /root/bin/portsentry.temp.block script 
will send a very brief message to the list admin noting each block as it 
happens, and the total number of hosts blocked at that particular point in 
time.
>Every packet entering the firewall (on *any* interface) is checked
>against every dynamically blacklisted host. That makes a large set of
>blacklisted hosts quite expensive.
Agreed, both in terms of time required to process all those rules for each 
_valid_ request as well as of being unreachable by a significant number of 
people.


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

At 7/17/2003 09:18 -0600, Rodolfo J. Paiz wrote:
>At 7/17/2003 08:00 -0700, Tom Eastep wrote:
>For the sake of reference, the seven servers on which I run this system 
>rarely accumulate more than 60 hosts in the blacklist. That''s how
the
>five-day period evolved, as a concern over not blocking too many people. 
>The key to happiness is really to clearly define those ports on which you 
>are willing to block even the slightest sign of activity, and only block 
>those. That way you keep the false positives down to a minimum.
As a follow-up, and in support of Tom''s earlier argument, I just
checked
the httpd logs for one of my servers. This is a development box, on which 
really no one but me should be looking at web pages, so this is the kind of 
box on which someone might decide to block port 80. This would be a BIG 
MISTAKE.

Although the list of blocked hosts almost never hits even 30 IP addresses 
(given my current selection of ports), in the last month I have received 
approximately 2,400 web requests for "default.ida",
"root.exe", or
"cmd.exe". Note these are not _all_ the requests I received, just
those
from a quick search for virii. All of these are Windows worms and harmless 
to me, so that even though I have a web server running on that box they do 
not represent a danger. But if anyone had port 80 marked as hostile,
they''d
be blocking OVER 80 HOSTS A DAY, totalling 400-500 over 5 days.

This is the danger of false positives or blocking the wrong ports.


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

On Thu, 2003-07-17 at 08:18, Rodolfo J. Paiz wrote:
> 
> For the sake of reference, the seven servers on which I run this system 
> rarely accumulate more than 60 hosts in the blacklist.
Still, making every packet in and out (again I emphasize that it is
every packet, not just those that are connection requests) run a
gauntlet of 60 extra rules seems like it would have a measureable effect
on performance unless you have a very fast CPU in your firewall.

-Tom 
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

At 7/17/2003 09:01 -0700, Tom Eastep wrote:
>Still, making every packet in and out (again I emphasize that it is
>every packet, not just those that are connection requests) run a
>gauntlet of 60 extra rules seems like it would have a measureable effect
>on performance unless you have a very fast CPU in your firewall.
Either a fast CPU, or a low-traffic site. <grin> Of course, the block 
interval can be changed in about two seconds, so knocking it down to three 
days or two is trivial.

I see your point, though. It would be interesting to run some tests on 
performance with 60 or so hosts blocked, then 30, then none, and see if I 
can detect a difference. Do you think it might show up in ping times, or 
should I find something that measures completion time for an HTTP request, 
or what?


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

On Thu, 2003-07-17 at 09:26, Rodolfo J. Paiz wrote:
> At 7/17/2003 09:01 -0700, Tom Eastep wrote:
> >Still, making every packet in and out (again I emphasize that it is
> >every packet, not just those that are connection requests) run a
> >gauntlet of 60 extra rules seems like it would have a measureable
effect
> >on performance unless you have a very fast CPU in your firewall.
> 
> Either a fast CPU, or a low-traffic site. <grin> Of course, the block
> interval can be changed in about two seconds, so knocking it down to three 
> days or two is trivial.
> 
> I see your point, though. It would be interesting to run some tests on 
> performance with 60 or so hosts blocked, then 30, then none, and see if I 
> can detect a difference. Do you think it might show up in ping times, or 
> should I find something that measures completion time for an HTTP request, 
> or what?
Let''s hold off until I start work on 1.4.7 -- I have some ideas that
can
improve the cost of blacklisting.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 17 Jul 2003 09:41:50 -0700 Tom Eastep <teastep@shorewall.net> wrote....
 
> Let''s hold off until I start work on 1.4.7 -- I have some ideas
that can
> improve the cost of blacklisting.
	Do you dream these ideas in your few minutes of sleep a day?? ;) Great
support, constant updates, continued forward movement with the project...
Hats of to you Tom! (It''s a bit early in the day for a
''toast'' ;)

--- 
Homer Parker                  /"\ ASCII Ribbon Campaign
                              \ / No HTML/RTF in email
http://www.homershut.net       x  No Word docs in email
telnet://bbs.homershut.net    / \ Respect for open standards

"Bill Gates reports on security progress made and the challenges
ahead."
-- Microsoft''s Homepage, on the day an SQL Server bug crippled large
   sections of the Internet.


 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030717/3de1240b/attachment.bin

At 7/17/2003 09:41 -0700, Tom Eastep wrote:
>Let''s hold off until I start work on 1.4.7 -- I have some ideas
that can
>improve the cost of blacklisting.
OK. When is 1.4.6 going to be released?


-- 
Rodolfo J. Paiz
rpaiz@simpaticus.com

On Thu, 2003-07-17 at 09:58, Rodolfo J. Paiz wrote:
> At 7/17/2003 09:41 -0700, Tom Eastep wrote:
> >Let''s hold off until I start work on 1.4.7 -- I have some
ideas that can
> >improve the cost of blacklisting.
> 
> OK. When is 1.4.6 going to be released?
Next week some time.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

One more suggestion about the HOWTO -- the dynamic black list isn''t
automatically restored after a "shorewall restart" (or "shorewall
stop;
shorewall start") unless a "shorewall save" is done. Might be
worth
adding that to portsentry.temp.block:

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

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net