Is using a blacklist in iptables a good strategy?

Is using a blacklist in iptables a good strategy?

[David Leangen]

Hello,

I don't know why, but I'm getting a little fed up with break-in attempts
happening every single day.

Do I just have to accept this as a fact of life?


I started keeping a list of IP addresses that I'm just going to
blacklist, but this does not seem like a maintainable solution. For now,
I'm just adding lines like so:

  ...
  -A INPUT -s xxx.xxx.xxx.xxx -j BLACKLIST
  ...
  -A BLACKLIST -j DROP
  ...

What is common practice?


Is it possible to blacklist any packets that come from a server from a
given country?


Thanks for the advice!
Dave

Re: Is using a blacklist in iptables a good strategy?

[Dave Strydom]

yes there is:

http://people.netfilter.org/peejix/geoip/howto/geoip-HOWTO-2.html

it's a geoip patch for iptables, allows you to block entire countries,
or you can allow connections from only certain countries.

Dave

==================

On 11/29/05, David Leangen <netfilter@leangen.net> wrote:
>
> Hello,
>
> I don't know why, but I'm getting a little fed up with break-in attempts
> happening every single day.
>
> Do I just have to accept this as a fact of life?
>
>
> I started keeping a list of IP addresses that I'm just going to
> blacklist, but this does not seem like a maintainable solution. For now,
> I'm just adding lines like so:
>
>   ...
>   -A INPUT -s xxx.xxx.xxx.xxx -j BLACKLIST
>   ...
>   -A BLACKLIST -j DROP
>   ...
>
> What is common practice?
>
>
> Is it possible to blacklist any packets that come from a server from a
> given country?
>
>
> Thanks for the advice!
> Dave
>
>
>
>

Re: Is using a blacklist in iptables a good strategy?

[Łukasz Hejnak]

David Leangen napisa³(a):
> Hello,
Hi :]
> I don't know why, but I'm getting a little fed up with break-in attempts
> happening every single day.
don't we all?
> Do I just have to accept this as a fact of life?
sadly yes.
but there are better and worse ways of preventing them..
> I started keeping a list of IP addresses that I'm just going to
> blacklist, but this does not seem like a maintainable solution. For now,
well I think this is a bad way of doing this, I had such a blacklist 
once.. now for _some_ IP's I've got it also, but I decided to only block 
the IPs that I can see in my logs really often, that's more than 2,3 
days in a row
The thing is: ip spoofing, redirecting, zombie machines etc
So by blocking a single IP or an IP range You can just by accident block 
off someone that really would use Your server..

My current way of doing this is using the ipt_recent
so now I only block the 'strage connections' for some time,
the less common get blocked for 4 minutes, the more common (port 22 for 
example) are blocked for an hour..
Apart from blocking I also tarpit them, so I guess this is anoying to 
try to scan my host, even though it of course is possible,
it takes a long time ;]

here's some copy/paste from my current ipt rule set
the ssh port used in the below config is 42156
it's good to have a high port ssh, as then most of the default scans for 
22 don't do anything, and so do brute force attacks have a problem to 
what port to try, apart from that, brute force attacks are handled here 
in a more specific way

# First a 'BigTime' chain, for those that there's no hope for ;]
$ipt -N bigtime
$ipt -A bigtime -p tcp -j TARPIT
$ipt -A bigtime -j DROP

# second a 'byebye' chain for those that are supposed to get logged once
$ipt -N byebye
# log the source ip of the packet, as well as compare it's fingerprint
# to a set of fingerprints for different OS's, so often I know
# not only the IP, but also the more or less accurate OS version
$ipt -A byebye -p tcp -m osf --log 1 --smart
$ipt -A byebye -j LOG --log-level debug --log-prefix "Bugger byebye: "
$ipt -A byebye -p tcp -j TARPIT
$ipt -A byebye -j DROP

# now here's a chain for the SSH_Brute_Foce check
# notice below, as everything that enters this chain is
# tagged with 'SSH' name
$ipt -N SSH_Brute_Force
# let me from my home pc in
$ipt -A SSH_Brute_Force -s $MyIP -j ACCEPT
# if less than three times the packet got here (3 login try's)
# let him trough
$ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 3 -j ACCEPT
# if this is the fourth attempt within the last 60s then go to byebye,
# where it is logged
$ipt -A SSH_Brute_Force -m recent ! --rcheck --name SSH --seconds 60 
--hitcount 4 -j byebye
$ipt -A SSH_Brute_Force -m recent --name SSH --update
# each next attempt will be tarpited/droped
$ipt -A SSH_Brute_Force -p tcp -j TARPIT
$ipt -A SSH_Brute_Force -j DROP

# and last but not least, a rule for everything else that hits
# the firewall and should not (not existing services)
# the list of interesting porst here (I don't service those outside,
# and nobody should hit them)
porty="20 21 22 23 42 53 137 138 139 143 412 1026 1027 1028 1029 1030 
1080 1433 4899 8080 10000 15118"
# notice below, as everything that enters this chain is
# tagged with 'abuggeri' name
$ipt -N buggerin
# my IP goes trough :]
$ipt -A buggerin -i eth0 -s $MyIP -j ACCEPT
# now all of those bad PORTs are re-tagged with the name 'abuggerti'
for port in $porty; do
     $ipt -A buggerin -p tcp --dport $port -m recent --set --name abuggerti
     $ipt -A buggerin -p udp --dport $port -m recent --set --name abuggerti
done
# if the abuggerti appear any more than one in a hour,
# they go directly to the BigTime chain
$ipt -A buggerin -m recent --rcheck --name abuggerti --seconds 3600 
--hitcount 2 -j bigtime
# else they're logged
$ipt -A buggerin -m recent --rcheck --name abuggerti -p tcp -m osf --log 
1 --smart
$ipt -A buggerin -m recent --rcheck --name abuggerti -j LOG --log-level 
debug --log-prefix "BigtimeI: "
$ipt -A buggerin -m recent --name abuggerti --update
# and then they go to BigTime
$ipt -A buggerin -m recent --rcheck --name abuggerti -j bigtime
# as for other ports, they are logged and blocked for 4 minutes
$ipt -A buggerin -m recent ! --rcheck --name abuggeri --seconds 240 
--hitcount 2 -j byebye
$ipt -A buggerin -m recent --name abuggeri --update
$ipt -A buggerin -p tcp -j TARPIT
$ipt -A buggerin -j DROP


# now as for the NEW SSH packets, let's tag it with 'SSH'
$ipt -A INPUT -p tcp --dport 42156 -m state --state NEW -m recent --set 
--name SSH
# and send all of those 'SSH' to SSH_Brute_Force
$ipt -A INPUT -m recent --rcheck --name SSH -j SSH_Brute_Force

# these two are on the end of the firewall, they redirect anything
# that was not let trough (tag it with 'abuggeri') to the buggerin chain
$ipt -A INPUT -m recent --set --name abuggeri
$ipt -A INPUT -m recent --rcheck --name abuggeri -j buggerin


hope this helps :]

All of this was inspired by the 'SSH Brute Force discussion' at netfiler
the main branch of this thread is started here
(It was in May afterall.. ahh.. time flys..)
https://lists.netfilter.org/pipermail/netfilter/2005-May/060299.html
and another one here:
https://lists.netfilter.org/pipermail/netfilter/2005-May/060578.html

and there are some more in June and July

--
Best wishes
£ukasz Hejnak

RE: Is using a blacklist in iptables a good strategy?

[David Leangen]

Guys,


> > I'm getting a little fed up with break-in attempts happening every 
> > single day.

> My current way of doing this is using the ipt_recent
> so now I only block the 'strage connections' for some time...
> here's some copy/paste from my current ipt rule set


> http://people.netfilter.org/peejix/geoip/howto/geoip-HOWTO-2.html
> 
> it's a geoip patch for iptables, allows you to block entire countries,
> or you can allow connections from only certain countries.


Thanks for the great tips!

Dave

Re: Is using a blacklist in iptables a good strategy?

[Nick Drage]

On Tue, Nov 29, 2005 at 05:21:15 +0900, David Leangen wrote:

> I don't know why, but I'm getting a little fed up with break-in
> attempts happening every single day.
> 
> Do I just have to accept this as a fact of life?

What sort of attacks are these?  Are they against services you're
running or just port scans and similar?

-- 
deviants are sacrificed to increase group solidarity
Jenny Solzer

RE: Is using a blacklist in iptables a good strategy?

[David Leangen]

> > I don't know why, but I'm getting a little fed up with break-in
> > attempts happening every single day.
> >
> > Do I just have to accept this as a fact of life?
>
> What sort of attacks are these?  Are they against services you're
> running or just port scans and similar?

Well, generally they are mostly port scans and similar.

These have been going on for some time, but it seems that there are an
increasing number of attempts to break into my system via port 22.

Re: Is using a blacklist in iptables a good strategy?

[Brent Clark]

David Leangen wrote:
>>>I don't know why, but I'm getting a little fed up with break-in
>>>attempts happening every single day.
>>>
>>>Do I just have to accept this as a fact of life?
>>
>>What sort of attacks are these?  Are they against services you're
>>running or just port scans and similar?
> 
> 
> Well, generally they are mostly port scans and similar.
> 
> These have been going on for some time, but it seems that there are an
> increasing number of attempts to break into my system via port 22.

Hi

I too have been having the same problems, etc, but what I did was a range of things for e.g.

My working hours about between 7am and 6pm, so what I did was have two scripts, one open port 22 script and one close 22
script (and a few other like ftp etc)

so in my crontab I have the following:

0 6 * * 1-6 root sh -c /root/FIREWALL.OPEN > /dev/null 2>&1
59 16 * * 1-6 root sh -c /root/FIREWALL.CLOSE > /dev/null 2>&1

The other thing is, I run debian, for my adduser.conf, I set it so

mail:~# cat /etc/adduser.conf

# /etc/adduser.conf: `adduser' configuration.
# See adduser(8) and adduser.conf(5) for full documentation.

# The DSHELL variable specifies the default login shell on your
# system.
DSHELL=/bin/false

So yeah you can have the password, but you cant ssh in with that account.

If a user needs to have a shell access look at things like bash with the --restricted (the other is rbash) option, other 
wise there is chroot.

And then last, but not least is Grant Taylor's brilliant netfilter / ssh brute force stopper.

$IPT -N SSH_Brute_Force
$IPT -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set --rsource -j SSH_Brute_Force
$IPT -A SSH_Brute_Force -s $myipaddress -j ACCEPT
$IPT -A SSH_Brute_Force -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j ACCEPT
$IPT -A SSH_Brute_Force -j LOG --log-prefix "SSH Brute Force Attempt:  "
$IPT -A SSH_Brute_Force -p tcp -j DROP

A while ago I was at a security conference, and the speaker, said security needs to be like an onion (layers).
The more layers (obsticles), the better.

HTH

Kind Regards
Brent Clark

Re: Is using a blacklist in iptables a good strategy?

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 29 Nov 2005, David Leangen wrote:

>
> Hello,
>
> I don't know why, but I'm getting a little fed up with break-in attempts
> happening every single day.
>
> Do I just have to accept this as a fact of life?
>
>
> I started keeping a list of IP addresses that I'm just going to
> blacklist, but this does not seem like a maintainable solution. For now,
> I'm just adding lines like so:
>
>  ...
>  -A INPUT -s xxx.xxx.xxx.xxx -j BLACKLIST
>  ...
>  -A BLACKLIST -j DROP
>  ...
>
> What is common practice?


A default deny policy is the default best defense.

>
>
> Is it possible to blacklist any packets that come from a server from a
> given country?
>

Layered security might be your friend here, tcpd has these capabilities to 
aid iptables, consider:



# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
* * * *
*
# Explicit refusal.  No reason for any of these domains to be 
connecting... 
*
# * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 
* * * *
*
ALL:

\
         .aero .biz .coop .edu .info .int .museum .name  .ac .ad .ae .af .ag .ai \
         .al .am .an .ao .aq .ar .as .at .au .aw .az .ba .bb .bd .be .bf .bg .bh \
         .bi .bj .bm .bn .bo .br .bs .bt .bv .bw .by .bz .ca .cc .cd .cf .cg .ch \
         .ci .ck .cl .cm .cn .co .cr .cs .cu .cv .cx .cy .cz .de .dj .dk .dm .do \
         .dz .ec .ee .eg .eh .er .es .et .eu .fi .fj .fk .fm .fo .fr .ga .gb .gd \
         .ge .gf .gg .gh .gi .gl .gm .gn .gp .gq .gr .gs .gt .gu .gw .gy .hk .hm \
         .hn .hr .ht .hu .id .ie .il .im .in .io .iq .ir .is .it .je .jm .jo .jp \
         .ke .kg .kh .ki .km .kn .kp .kr .kw .ky .kz .la .lb .lc .li .lk .lr .ls \
         .lt .lu .lv .ly .ma .mc .md .mg .mh .mk .ml .mm .mn .mo .mp .mq .mr .ms \
         .mt .mu .mv .mw .mx .my .mz .na .nc .ne .nf .ng .ni .nl .no .np .nr .nu \
         .nz .om .pa .pe .pf .pg .ph .pk .pl .pm .pn .pr .ps .pt .pw .py .qa .re \
         .ro .ru .rw .sa .sb .sc .sd .se .sg .sh .si .sj .sk .sl .sm .sn .so .sr \
         .st .su .sv .sy .sz .tc .td .tf .tg .th .tj .tk .tm .tn .to .tp .tr .tt \
         .tv .tw .tz .ua .ug .uk .um .uy .uz .va .vc .ve .vg .vi .vn .vu .wf .ws \
         .xxx .ye .yt .yu .za .zm .zr .zw                                       \

         : SPAWN (/usr/local/wrappers/tcpdmsg ALL_DENY %a %c %n %s %u)&         \
         : twist /usr/bin/cat /usr/local/wrappers/ALL_DENY.message


Now this has to be included not only on the firewall, but on hosts that 
are accessible externally as well, and that might come as a painful way to 
work such an issue, unless one really understands that layered securtity 
can come at a cost and require a few cycles to implimnet, and that 
layering does not mean the firewall does it all and all other systems 
stand alone or merely rely upon the firewall, and have some securityy 
implimented on them as well.


Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFDlzvDst+vzJSwZikRAseOAKClgbJFoDPI/iJqISbU5RZRN4CC8ACgkO6B
18BSbrmJo+jFf9RsEo+UGrg=
=JARI
-----END PGP SIGNATURE-----