Shorewall users - Mar 2002 - Automatically generating blackhole list

Jens,

----- Original Message -----
From: "Jens" <jens@pacificsun.ca>
To: <shorewall-users@shorewall.net>
Sent: Wednesday, March 27, 2002 10:11 AM
Subject: [Shorewall-users] Automatically generating blackhole list

> I was looking over my Shorewall log today and noticed an awful lot of
tries
> on port 27374. This seems to be a popular port for trojan programs. It
> occured to me that it might be a good idea to have a program that
> automatically builds a list of source addresses to blacklist. I wonder if
> anyone has seen/written such a program.
I believe that Steve Cowles has such a program.
>
> On a different note, netbios chatter is dropped by the
/etc/shorewall/common
> script but only for udp. I get tcp messages as well - is there any reason
for
> not including tcp in the drop rules in /etc/shorewall/common ?
I guess because I''ve never seen any TCP netbios chatter :-) Copy
common.def
to common and modify common to your heart''s content.
>
> I am a little confused about the purpose of /etc/shorewall/common - what
was
> the reason for seperating these rules from the standard rules file ? If I
> include dropping tcp netbios messages, should this happen in the rules
file
> or the common file ?
>
Because with the common chain, I get one question a year from someone like
you. Without the common chain, I would get 200 questions a month asking me
"What is this attack???!!!!!" and "Why is my log filling up with
these????".

The common chains allows you to silently suppress individual connection
requests while still including a log level in your policies.

-Tom

On Wed Mar 03/27/02, 2002 at 10:11:55AM -0800, Jens
wrote:
> I was looking over my Shorewall log today and noticed an awful lot of tries
> on port 27374. This seems to be a popular port for trojan programs.
Yes, it''s a popular little trojan:

http://www.robertgraham.com/pubs/firewall-seen.html

Sub7 Trojan:

http://www.robertgraham.com/pubs/firewall-seen.html#subseven
> It occured to me that it might be a good idea to have a program that 
> automatically builds a list of source addresses to blacklist. I wonder if 
> anyone has seen/written such a program.
If you''re even considering automatically blackholing host addresses
that
send to you on this port, consider the following:

Option 1: This is a very stupid script kiddie with a fixed address.
He''s
dumb enough to be poking hosts he does not already 0wn for a trojan he
did not install, from a fixed and known address. Is he likely to get
anywhere? Blackholing him may give you some satisfaction, but little else
-- he''s not going to get in. :)*

Option 2: This is a slightly less stupid script kiddie, with a dynamic
address of some sort -- if he''s not a complete moron, it''s a
dialup.
This means that you''re blackholing every poor schmuck from the same
ISP,
eventually -- ISP dial-up pools are only so large, he may get a fairly
large percentage of the ISP dialup pool to do these scans before he is
kicked off. Does this really buy you anything?

Option 3: This is a deliberately spoofed address. It''s non-trivial to
spoof TCP, but in this instance, it can be completely blind -- he needs
no response packets to make this a _very_ effective denial of service.
Spoof a single packet from, e.g. 192.41.162.30, and imagine the fun you
can have...**

* Unless, of course, you''re still running an old SSH, or some other
trivially exploitable remote-root hole...

** Some may recognize this address right off the bat. Now imagine that
you spoof another 12 packets. :)

I''m just trying to say, you should think _very_ hard about
automatically
blackholing adresses.

-- 
Greg White

On Thu Mar 03/28/02, 2002 at 06:21:22AM -0800, Jens
wrote:
> On March 27, 2002 11:51 pm, Greg wrote:
> > Option 3: This is a deliberately spoofed address. It''s
non-trivial to
> > spoof TCP, but in this instance, it can be completely blind -- he
needs
> > no response packets to make this a _very_ effective denial of service.
> > Spoof a single packet from, e.g. 192.41.162.30, and imagine the fun
you
> > can have...**
> >
> > * Unless, of course, you''re still running an old SSH, or some
other
> > trivially exploitable remote-root hole...
> >
> > ** Some may recognize this address right off the bat. Now imagine that
> > you spoof another 12 packets. :)
> 
> Ok, I bite .... what are you talking about ?
gregw@frodo:~$ dnsname 192.41.162.30
l.gtld-servers.net

I just picked a random GTLD server. Now imagine that he also spoofs the
other twelve GTLD servers as well. .com, .net, and .org domains stop
resolving, and start expiring from your cache if they''re already there.
Wackiness ensues. :)

I chose a GTLD server, as it''s generally easy to spot a root server
address -- it''s in a file on your system, to prime your DNS cache, and
lots of people recognize some or all of them on sight. Not so many would
know GTLD servers, I imagined.
> > I''m just trying to say, you should think _very_ hard about
automatically
> > blackholing adresses.
> 
> I seem to get a large number of probes from individual addresses over
longer
> periods of time so as to suggest a compromised system on a cable connection
> or fixed ip. I think I would monitor the process quite closely .....
I have personally blackholed certain hosts in this manner, for some
networks. I never automate the process, to ensure that attacks like the
above can''t be done to me. I''ve always manually audited the
logs (Sub7
probes are always logged in my installs) for hosts which repeatedly
probe for such things. That said, you''ve inspired me to try to hack
something Perlish together, which improves and automates the logging
process...and maybe sends root a mail which says, "Maybe it''s time
to
blackhole host ''192.168.1.2'', he''s trying a lot of
Sub7..."

-- 
Greg White

Jens wrote:
> On March 28, 2002 08:23 am, you wrote:
>
> > That said, you''ve inspired me to try to hack
> > something Perlish together, which improves and automates the logging
> > process...and maybe sends root a mail which says, "Maybe
it''s time to
> > blackhole host ''192.168.1.2'', he''s trying a
lot of Sub7..."
>
> Steve Cowles <Steve@SteveCowles.com> has passed on his scripts to me
for
> automating this process. I haven''t worked my way thru them yet but
you might
> want to start there rather than from scratch.
>
> An interesting side idea, rather than blackholing on IP address, how about
> blackholing on mac addresses - does this stay the same on dialup users ?
It stays the same for nearly everything - MAC addresses are only valid on the
local segment.  You never see the client''s real MAC address, only the
one from
your local router/switch/whatever.

I think what Greg is saying is is this: You are trying to find quick fixes
where there are none.  You need to secure your firewall through good rules and
policies, and keeping it up-to-date with security patches, not by finding new
ways to blacklist people.

If shorewall had a facility to automatically add blacklist entries, and then
expire them after, say, 30 minutes (a-la certain Windows firewalls), that would
be more practical.  (Tom is happy to accept patches, i hear.  :-)

Paul
http://paulgear.webhop.net

On Thu Mar 03/28/02, 2002 at 09:16:17AM -0800, Jens
wrote:
> Steve Cowles <Steve@SteveCowles.com> has passed on his scripts to me
for
> automating this process. I haven''t worked my way thru them yet but
you might
> want to start there rather than from scratch.
> 
> An interesting side idea, rather than blackholing on IP address, how about 
> blackholing on mac addresses - does this stay the same on dialup users ?
Filtering on the MAC address from the internet side is useless -- you
don''t know what his MAC is, and you never see it. Only his
ISP''s router
sees it. You see the MAC address of your own upstream router. :) 
> 
> Jens
> 
> PS.: I tried to email this directly but alas, your address doesn''t
work :(
The address I post with is the address I''m subscribed to the list with
-- if this address did not work, I wouldn''t have gotten this email
either.

I suspect you''re being bitten by a BIND bug, caused by the incredible
lameness of the .ca servers. It''s a long story, and I''m
working on it.

-- 
Greg White

Although I agree with Paul and Greg''s comments on the practicality of
running an automated blacklist program, I use the program I developed just
so that I can read my apache logfiles without wading through 90%
Nimda/CodeRed bull$hit. 

FWIW: Being on Verizon''s DSL Network (4.0.0.0/8) can create a rather
large
amount of Ninda/Code Red probes from infected systems. I was seeing nimda
probes every 5 minutes or so. In fact, in one month, my automated update
program added over 250+ ip''s from the 4.0.0.0/8 network. I am now at
400+
entries. 

With the above in mind, using an automated approach to blacklisting
ip''s has
allowed me to view my apache logfiles for those annoying robot probes that
ignore my robots.txt file. 

Steve Cowles

I''ve been wanting a utility like this for some time.  To me, the ideal
solution would be something that you could configure:

1)log to watch
2)pattern to look for
3)frequency  (# of occurances within a certain amount of time)
4)offender info to look for  (ip, mac, etc.)
5)shorewall action to take  (blacklist, close a port, traffic shaping?)
5)time to live  (after this expires, changes are undone)

  Then you could set it so that maybe one type of violation results in a 10
minute ban for a single ip, while some other type of violation results in a
weeklong ban for an entire subnet.  By setting the frequency, you could have
a sort of flood control too, or maybe you just don''t want to ban
someone
until they''ve probed your webserver 100 times in a row.

  I agree that an auto blacklisting system would be questionable without
some sort of time to live option for the changes it makes.  Well those are
my thoughts anyway, whatever that''s worth.


Sincerely,
Jim Hubbard
______________________________________________________

> -----Original Message-----
> From: Jim Hubbard [mailto:jimh@dyersinc.com]
> Sent: Thursday, March 28, 2002 2:02 PM
> To: shorewall-users@shorewall.net
> Subject: RE: [Shorewall-users] Automatically generating blackhole list
> 
> 
>   I''ve been wanting a utility like this for some time.  To 
> me, the ideal solution would be something that you could
> configure:
> 
> 1)log to watch
> 2)pattern to look for
> 3)frequency  (# of occurances within a certain amount of time)
> 4)offender info to look for  (ip, mac, etc.)
> 5)shorewall action to take  (blacklist, close a port, traffic 
> shaping?)
> 5)time to live  (after this expires, changes are undone)
>
Excellent requirements for creating a useful blacklisting program. I''m
sure
you''ll agree that implemeting items 3 & 6 would require a major
programming
effort. Especially if your wanting real-time scanning verus polled.

Have you taken a look at BigBrother? http://www.bb4.com/features.html
It''s
not Tivoli, but the basic architecture your wanting has already been
developed.

BTW: There are many bigbrother users that have contributed to writing
plugins to tie into bigbrother. I use the the bigbrother MRTG plugin so that
I can test network utilization values and be notified if a threshold has
been exceeded. Worth a look at least. I saw a few logfile based plugins.
Checkout: http://www.deadcat.net

Steve Cowles

> 1)log to watch
> 2)pattern to look for
> 3)frequency  (# of occurances within a certain amount of time)
> 4)offender info to look for  (ip, mac, etc.)
> 5)shorewall action to take  (blacklist, close a port, traffic shaping?)
> 6)time to live  (after this expires, changes are undone)
>
>
> Excellent requirements for creating a useful blacklisting
> program. I''m sure
> you''ll agree that implemeting items 3 & 6 would require a
major
> programming
> effort. Especially if your wanting real-time scanning verus polled.
>
I have yet to try my hand at programming anything in linux yet.  I wish I
could help, because I think I understand how the program should work,
it''s
just that I don''t know where to begin.  I guess it''s time to
get off my ass
and learn perl.  Maybe the system could use a cron job to undo a change when
time to live is up?
>
> Have you taken a look at BigBrother? http://www.bb4.com/features.html
It''s
> not Tivoli, but the basic architecture your wanting has already been
> developed.
>
> Steve Cowles
The last time this idea was batted around, someone also suggested Swatch.
I''ve never used either one, but from what I''ve read, Swatch
already does the
"monitor logfile > take action when pattern is matched" part. 
Maybe all
that''s needed then would be Swatch or BigBrother plus a few scripts to
add
and remove entries from the Shorewall config files and create cron jobs.

Jim Hubbard