ssh attack profile - Slackware

This is a discussion on ssh attack profile - Slackware ; Hi there, Other day I posted about ssh firewall protection -- since then decided it was over the top and much simplified the rules, removing the simple port knock access as being a silly encumbrance (do it right, or not ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: ssh attack profile

  1. ssh attack profile

    Hi there,

    Other day I posted about ssh firewall protection -- since then decided
    it was over the top and much simplified the rules, removing the simple
    port knock access as being a silly encumbrance (do it right, or not at
    all -- port knock needs to be non-replayable). So an 'attack' looks
    too simple:

    03:46:35 JLE:inpkay ssh TCP 20122 -> 22 (ssh) TTL=115 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    ....
    07:29:45 JLE:inpkay ssh TCP 52457 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:47 JLE:inpkay ssh TCP 52573 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:50 JLE:inpkay ssh TCP 52721 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:53 JLE:inp:reject - TCP 52840 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:53 JLE:inp:reject - TCP 52857 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:53 JLE:inp:reject - TCP 52871 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:54 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:29:57 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree
    07:30:03 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    206.221.191.215 (US:United States) -> deltree

    (Pretty printer is sf4sf from: http://bugsplatter.id.au/firewall/)

    This is the third similar profile I've noticed in the firewall log, there's
    the initial contact, then some minutes or hours later there's the probe that
    results in attacker being cut off and 'jailed' -- to be jailed simply means
    further packets from the offending IP are dropped for some long time (hours)
    until IP goes quiet.

    This is with rules similar to those on Robby W's page:
    http://rlworkman.net/conf/firewall/sshattacks

    I'm still considering whether to ban ssh attackers for 'life', as I have a
    repeat offender pinging the box today -- grepping their IP through the log
    produces some interesting info (well this is new to me, haven't opened ssh
    to the world before

    Oct 6 10:30:07 deltree sshd[17131]: Did not receive identification string from 82.66.33.122
    Oct 6 10:34:01 deltree sshd[17379]: Invalid user fluffy from 82.66.33.122
    Oct 6 10:34:04 deltree sshd[17415]: Invalid user admin from 82.66.33.122
    Oct 6 10:34:06 deltree kernel: JLE:inp:drop jailed IN=ppp0 OUT= MAC= SRC=82.66.33.122
    Oct 7 07:25:09 deltree kernel: JLE:inpkay ping IN=ppp0 OUT= MAC= SRC=82.66.33.122

    So the French fluffy-admin checked that my box is back online today.

    While I write this, another ssh probe from Japan follows the same pattern,
    initial contact at 07:41:04 followed by probe at 07:50:31 and jailed by
    07:50:38 -- I'm liking this firewall ssh access method.

    Usernames seen: fluffy admin test guest webmaster Ovidiu staff sales recruit

    Grant.
    --
    http://bugsplatter.id.au/

  2. Re: ssh attack profile

    Grant wrote:
    > Oct 6 10:30:07 deltree sshd[17131]: Did not receive identification string from 82.66.33.122
    > Oct 6 10:34:01 deltree sshd[17379]: Invalid user fluffy from 82.66.33.122
    > Oct 6 10:34:04 deltree sshd[17415]: Invalid user admin from 82.66.33.122
    > Oct 6 10:34:06 deltree kernel: JLE:inp:drop jailed IN=ppp0 OUT= MAC= SRC=82.66.33.122
    > Oct 7 07:25:09 deltree kernel: JLE:inpkay ping IN=ppp0 OUT= MAC= SRC=82.66.33.122
    >
    > So the French fluffy-admin checked that my box is back online today.
    >
    > While I write this, another ssh probe from Japan follows the same pattern,
    > initial contact at 07:41:04 followed by probe at 07:50:31 and jailed by
    > 07:50:38 -- I'm liking this firewall ssh access method.
    >
    > Usernames seen: fluffy admin test guest webmaster Ovidiu staff sales recruit
    >
    > Grant.
    >

    Ya know, this is exactly the sort of crap that DenyHosts is really good
    at taking care of? Take a look at http://denyhosts.sourceforge.net.

  3. Re: ssh attack profile

    Grant wrote:
    > Hi there,
    >
    > Other day I posted about ssh firewall protection -- since then decided
    > it was over the top and much simplified the rules, removing the simple
    > port knock access as being a silly encumbrance (do it right, or not at
    > all -- port knock needs to be non-replayable). So an 'attack' looks
    > too simple:
    >
    > 03:46:35 JLE:inpkay ssh TCP 20122 -> 22 (ssh) TTL=115 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > ...
    > 07:29:45 JLE:inpkay ssh TCP 52457 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:47 JLE:inpkay ssh TCP 52573 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:50 JLE:inpkay ssh TCP 52721 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:53 JLE:inp:reject - TCP 52840 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:53 JLE:inp:reject - TCP 52857 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:53 JLE:inp:reject - TCP 52871 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:54 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:29:57 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    > 07:30:03 JLE:inp:drop jail TCP 52885 -> 22 (ssh) TTL=51 SYN ->ppp0
    > 206.221.191.215 (US:United States) -> deltree
    >


    **snip**

    Try fail2ban.. works wonders, but you will get these no matter what you
    do and is more than likely a script running. Just make sure you don't
    have easily guessed passwords and configure ssh to only accept SSHv2
    connections and not allow root to ssh in remotely.

    -Matt

  4. Re: ssh attack profile

    Grant wrote:

    > [some stuff]


    I chose the easy path, blocking whole nets of offenders. Use a
    different port for ssh. And whole countries are blocked, nothing but
    crap comes creeping out of asia anyway.

    That combo does the trick for me.

    Now, what do you suggest to cope with a standard port listening postfix
    being battered by evildoers? :-)

    S.

  5. Re: ssh attack profile

    Hallo, Grant,

    Du meintest am 07.10.08:

    > Other day I posted about ssh firewall protection -- since then
    > decided it was over the top and much simplified the rules, removing
    > the simple port knock access as being a silly encumbrance (do it
    > right, or not at all -- port knock needs to be non-replayable). So
    > an 'attack' looks too simple:


    > 03:46:35 JLE:inpkay ssh TCP 20122 -> 22 (ssh) TTL=115
    > SYN ->ppp0 206.221.191.215 (US:United States) -> deltree
    > ...
    > 07:29:45 JLE:inpkay ssh TCP 52457 -> 22 (ssh) TTL=51
    > SYN ->ppp0 206.221.191.215 (US:United States) -> deltree


    [...]

    I use a bundle of measures:

    a)
    PermitRootLogin without-password

    in "/etc/ssh/sshd_config"

    b) a list of IP address ranges for "iptables"

    # einzelne Netzbereiche komplett blocken
    while read IP Rest
    do
    Block=${IP%%#*}
    test "$Block" || continue
    $IPTABLES_BIN -t filter -A INPUT -p tcp -s $Block --dport 0:1024 -j reject_fkt
    $IPTABLES_BIN -t filter -A INPUT -p udp -s $Block --dport 0:1024 -j reject_fkt
    done < /etc/Schule/vollblock


    c) the following lines for "iptables" which cut the connection after 4
    tries within 60 seconds:


    WAN=ippp+ ppp+
    # or whatever makes the connection to the WAN
    for Interf in $WAN; do
    $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
    -m recent --set --name SSH
    $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
    -m recent --rcheck --seconds 60 --hitcount 4 --rttl --name SSH \
    -j REJECT --reject-with tcp-reset
    $IPTABLES_BIN -A INPUT -i $Interf -p tcp --dport 22 -m state --state NEW \
    -j ACCEPT
    done

    # Florian Frank in der "linuxmuster"-Mailingliste, 17. Sept. 2005
    # pro Absender-IP max. 3 Verbindungsanfragen pro Minute; blockt Skript-Kiddies
    # "rcheck" statt "update": Sven Geggus, 22. Sept. 05,
    # de.comp.os.unix.networking.misc

    Viele Gruesse
    Helmut

    "Ubuntu" - an African word, meaning "Slackware is too hard for me".


  6. Re: ssh attack profile

    On Tue, 07 Oct 2008 16:13:20 +0200, Simon Sibbez wrote:

    >Grant wrote:
    >
    >> [some stuff]

    >
    >I chose the easy path, blocking whole nets of offenders. Use a
    >different port for ssh. And whole countries are blocked, nothing but
    >crap comes creeping out of asia anyway.
    >
    >That combo does the trick for me.
    >
    >Now, what do you suggest to cope with a standard port listening postfix
    >being battered by evildoers? :-)


    Same as what I'm doing for sendmail offenders from TW, block by CIDR

    Grant.
    --
    http://bugsplatter.id.au/

  7. Re: ssh attack profile

    On Tue, 07 Oct 2008 07:08:18 -0400, Thomas Ronayne wrote:

    >Grant wrote:
    >> Oct 6 10:30:07 deltree sshd[17131]: Did not receive identification string from 82.66.33.122
    >> Oct 6 10:34:01 deltree sshd[17379]: Invalid user fluffy from 82.66.33.122
    >> Oct 6 10:34:04 deltree sshd[17415]: Invalid user admin from 82.66.33.122
    >> Oct 6 10:34:06 deltree kernel: JLE:inp:drop jailed IN=ppp0 OUT= MAC= SRC=82.66.33.122
    >> Oct 7 07:25:09 deltree kernel: JLE:inpkay ping IN=ppp0 OUT= MAC= SRC=82.66.33.122
    >>
    >> So the French fluffy-admin checked that my box is back online today.

    ....
    >Ya know, this is exactly the sort of crap that DenyHosts is really good
    >at taking care of? Take a look at http://denyhosts.sourceforge.net.


    I already have a system in place to do similar thing -- just a matter
    of collecting data and deciding what to do next. tcpwrappers is not
    the answer when servers are running standalone, but I have a deny list
    in the firewall does lockout.

    Grant.
    --
    http://bugsplatter.id.au/

  8. Re: ssh attack profile

    On Wed, 08 Oct 2008 02:22:18 +1100, Grant wrote:

    > On Tue, 07 Oct 2008 16:13:20 +0200, Simon Sibbez
    > wrote:
    >
    >>Grant wrote:
    >>
    >>> [some stuff]

    >>
    >>I chose the easy path, blocking whole nets of offenders. Use a different
    >>port for ssh. And whole countries are blocked, nothing but crap comes
    >>creeping out of asia anyway.
    >>
    >>That combo does the trick for me.
    >>
    >>Now, what do you suggest to cope with a standard port listening postfix
    >>being battered by evildoers? :-)

    >
    > Same as what I'm doing for sendmail offenders from TW, block by CIDR
    >
    > Grant.


    just wondering does TW stand for taiwan ?

  9. Re: ssh attack profile

    Grant wrote:

    > tcpwrappers is not the answer when servers are running standalone, ...


    Unless the server in question is linked with TCP_Wrapper at build-time
    (assuming the capability exists in the server).

    I TCP_Wrap stand-alone daemons, such as sshd, sendmail, and others.
    I've been doing it for years.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  10. Re: ssh attack profile

    On 07 Oct 2008 16:01:48 GMT, goarilla wrote:

    >
    >just wondering does TW stand for taiwan ?


    Yes.
    --
    http://bugsplatter.id.au/

  11. Re: ssh attack profile

    goarilla wrote:
    > just wondering does TW stand for taiwan ?


    Yes it does: see for instance the GeoIP database, as distributed
    by MaxMind.
    www.maxmind.com/download/geoip/database
    --
    ************************************************** *****************
    ** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
    ** e-mail: E.J.M.Hartman@tudelft.nl, fax: +31-15-278 7295 **
    ** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
    ************************************************** *****************

  12. Re: ssh attack profile

    On Tue, 7 Oct 2008 17:40:30 +0000 (UTC), Sylvain Robitaille wrote:

    >Grant wrote:
    >
    >> tcpwrappers is not the answer when servers are running standalone, ...

    >
    >Unless the server in question is linked with TCP_Wrapper at build-time
    >(assuming the capability exists in the server).
    >
    >I TCP_Wrap stand-alone daemons, such as sshd, sendmail, and others.
    >I've been doing it for years.


    So that's different from slack compiled versions? Anyway, I run a deny
    list in the firewall, so perhaps roughly the same effect?

    Grant.
    --
    http://bugsplatter.id.au/

  13. Re: ssh attack profile

    Grant wrote:

    >>I TCP_Wrap stand-alone daemons, such as sshd, sendmail, and others.
    >>I've been doing it for years.

    >
    > So that's different from slack compiled versions?


    I don't know. I'd have to check the appropriate slackbuild scripts.

    > Anyway, I run a deny list in the firewall, so perhaps roughly the same
    > effect?


    I'm normally configured for default-deny (except perhaps for Sendmail on
    mx servers), so potentially not the same effect (though the same might
    be possible). The logs look different (I have log-monitoring software
    trained on the TCP_Wrappers log format), and it just feels "easier" to
    me to configure TCP_Wrappers. Probably because the syntax is more
    human-readable (and allows for FQDN/domain-names, for example) than
    iptables/ipchains/ipfwadm.

    --
    ----------------------------------------------------------------------
    Sylvain Robitaille syl@alcor.concordia.ca

    Network and Systems analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  14. Re: ssh attack profile

    On Tue, 7 Oct 2008 19:31:13 +0000 (UTC), Sylvain Robitaille wrote:

    >Grant wrote:
    >
    >>>I TCP_Wrap stand-alone daemons, such as sshd, sendmail, and others.
    >>>I've been doing it for years.

    >>
    >> So that's different from slack compiled versions?

    >
    >I don't know. I'd have to check the appropriate slackbuild scripts.
    >
    >> Anyway, I run a deny list in the firewall, so perhaps roughly the same
    >> effect?

    >
    >I'm normally configured for default-deny (except perhaps for Sendmail on
    >mx servers), so potentially not the same effect (though the same might
    >be possible). The logs look different (I have log-monitoring software
    >trained on the TCP_Wrappers log format), and it just feels "easier" to
    >me to configure TCP_Wrappers.


    Well one stays with familiar + trusted tools that get the job done.

    > Probably because the syntax is more
    >human-readable (and allows for FQDN/domain-names, for example) than
    >iptables/ipchains/ipfwadm.


    What's human readable? I used to count relative jump offsets backwards
    in hexadecimal when programming machine code on paper (before I got to
    programming in assembler And lest you think that was some hobby, the
    machine being programmed was installed in a 700-worker car assembly
    plant and every car body got entered on it as it came out of the paint
    shop and on to the assembly line. I drift... Need coffee!

    Grant.
    --
    http://bugsplatter.id.au/

  15. Re: ssh attack profile

    On Tue, 07 Oct 2008 16:13:20 +0200, Simon Sibbez wrote:

    >Grant wrote:
    >
    >> [some stuff]

    >
    >I chose the easy path, blocking whole nets of offenders. Use a
    >different port for ssh. And whole countries are blocked, nothing but
    >crap comes creeping out of asia anyway.


    Hey I'm in Asia! Well, Asia-Pacific, some say to block whole A-P /8
    blocks, but that may block Australia/NZ as well 'cos apnic is the RIR
    (Regional registry).

    Grant.
    --
    http://bugsplatter.id.au/

  16. Re: ssh attack profile

    On Tue, 07 Oct 2008 08:15:21 +1100, Grant wrote:

    >This is the third similar profile I've noticed in the firewall log, there's
    >the initial contact, then some minutes or hours later there's the probe that
    >results in attacker being cut off and 'jailed' -- to be jailed simply means
    >further packets from the offending IP are dropped for some long time (hours)
    >until IP goes quiet.


    Changed jail rule to REJECT new TCP connection attempts to see the
    difference:

    08:33:08 JLE:inpkay ssh TCP 64831 -> 22 (ssh) inet->ppp0 TTL=108 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    ....
    08:46:29 JLE:inpkay ssh TCP 45278 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:31 JLE:inpkay ssh TCP 45637 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:33 JLE:inpkay ssh TCP 45958 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:35 JLE:inp:drop reset TCP 46436 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:35 JLE:inp:drop reset TCP 46451 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:36 JLE:inp:drop reset TCP 46482 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:36 JLE:inp:drop jail TCP 46510 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:36 JLE:inp:drop jail TCP 46534 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:36 JLE:inp:drop jail TCP 46561 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:36 JLE:inp:drop jail TCP 46578 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:37 JLE:inp:drop jail TCP 46599 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:37 JLE:inp:drop jail TCP 46617 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:37 JLE:inp:drop jail TCP 46646 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:37 JLE:inp:drop jail TCP 46666 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:40 JLE:inp:drop jail TCP 46666 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:40 JLE:inp:drop jail TCP 47000 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:41 JLE:inp:drop jail TCP 47020 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree
    08:46:41 JLE:inp:drop jail TCP 47036 -> 22 (ssh) inet->ppp0 TTL=44 SYN
    115.95.34.164 (KR:Korea, South) -> deltree

    So a quite a few more hits after being jailed, but harmless as
    attacker gives up in less than ten seconds -- that's acceptable

    Current firewall jail rules:

    report " jail "
    iptables -N jaildrop
    iptables -A jaildrop $limit_rate_log "JLE:inp:drop jail "
    iptables -A jaildrop -p tcp -m conntrack --ctstate NEW -j REJECT
    iptables -A jaildrop -p all -j DROP

    iptables -N gotojail
    iptables -A gotojail -m recent --rsource --name rate --remove
    iptables -A gotojail -m recent --rsource --name jail --set -g jaildrop

    # hook INPUT chain -- discard jailed IPs until they're gone quiet
    iptables -A INPUT -p all -m recent --rsource --name jail --update \
    --seconds $mintime_jail -g jaildrop

    Oops, I now have rate limited logging:
    root@deltree:~# grep 115.95.34.164 /var/log/messages |wc -l
    19

    Well, that's okay, the thing did stop trying ssh port.

    Grant.
    --
    http://bugsplatter.id.au/

  17. ssh login fail IP or CIDR discovery scripts, was :Re: ssh attack profile

    On Tue, 07 Oct 2008 16:13:20 +0200, Simon Sibbez wrote:

    >Grant wrote:
    >
    >> [some stuff]

    >
    >I chose the easy path, blocking whole nets of offenders. Use a
    >different port for ssh. And whole countries are blocked, nothing but
    >crap comes creeping out of asia anyway.
    >
    >That combo does the trick for me.
    >
    >Now, what do you suggest to cope with a standard port listening postfix
    >being battered by evildoers? :-)


    Something this I wrote this morning to stop repeat ssh offenders?

    Adjust the awk search patterns to discover postfix abusers...

    Two scripts (I could merge them?) one builds an IP list, the other
    builds a list of CIDR blocks containing offending IPs, but requires
    ip2cn-server and database (url below). These may then be read into
    iptables to make a filter, I've written an untested example using bits
    from my rc.firewall script.

    performance
    ````````````
    root@deltree:~# wc -l /var/log/messages
    15210 /var/log/messages
    root@deltree:~# time firewall-check-ssh-fail-ip -t
    82.66.33.122
    121.15.171.65
    122.205.95.2
    123.108.201.204
    123.127.231.205
    123.220.251.13
    123.243.227.220
    174.133.144.82
    203.177.131.37
    206.221.191.215

    real 0m0.185s
    user 0m0.140s
    sys 0m0.040s
    root@deltree:~# time firewall-check-ssh-fail-cidr -t
    82.64.0.0/14
    121.8.0.0/13
    122.204.0.0/14
    123.108.200.0/21
    123.112.0.0/12
    123.216.0.0/13
    123.243.0.0/16
    174.132.0.0/15
    203.177.128.0/18
    206.221.176.0/20

    real 0m0.375s
    user 0m0.184s
    sys 0m0.152s

    Box is old Dell OptiPlex GX100, 500MHz Celeron with 256MB memory,
    http://bugsplatter.id.au/kernel/boxen/deltree/

    shell scripts
    ``````````````
    #!/bin/bash
    #
    # firewall-check-ssh-fail-ip -- 2008-10-09, last edit 2008-10-09
    #
    # script to scan /var/log/messages for ssh login failures and
    # merge offender IPs into a ban list
    #
    # Copyright (C) 2008 Grant Coady GPLv2
    #
    # usage: run as a root cron job to merge new ssh login attackers into
    # the firewall's ssh-ban-list-ip file
    #
    # home site: http://bugsplatter.id.au/firewall/
    #

    # location of ssh failed login ban list for firewall
    ssh_ban_list="/usr/local/etc/ssh-ban-list-ip"

    # exception list of IPs never to ban
    exceptions="'123\.22\.22\.22|^192\.168\.1'"

    # log file, where to find sshd messages -- default /var/log/messages
    log_file="/var/log/messages"

    sort_uniq_ban_list() # filename
    {
    local tmp=$(mktemp) || exit 1
    sort -t. -n -k1,1 -k2,2 -k3,3 -k4,4 < $1 \
    | uniq > $tmp && mv $tmp $1
    }

    # discover failed ssh attempts from log file
    awk '
    $5 !~ /^sshd/ {
    next
    }
    /not receive|Invalid/ {
    print $NF
    }
    /reverse map/ {
    sub(/[[]/, "", $12)
    sub(/[]]/, "", $12)
    print $12
    }
    ' $log_file | egrep -v $exceptions >> $ssh_ban_list

    sort_uniq_ban_list $ssh_ban_list

    [ "$1" == "-t" ] && cat $ssh_ban_list

    # end

    #!/bin/bash
    #
    # firewall-check-ssh-fail-cidr -- 2008-10-09, last edit 2008-10-09
    #
    # script to scan /var/log/messages for ssh login failures and merge
    # offender's CIDR block into a ban list
    #
    # Copyright (C) 2008 Grant Coady GPLv2
    #
    # usage: run as a root cron job to merge new ssh login attackers into
    # the firewall's ssh-ban-list file
    #
    # requires ip2cn-server, see: http://bugsplatter.id.au/ip2cn/
    #
    # home site: http://bugsplatter.id.au/firewall/
    #

    # location of ssh failed login ban list for firewall
    ban_list="/usr/local/etc/ssh-ban-list-cidr"

    # exception list of IPs never to ban
    exceptions="'123\.22\.22\.22|^192\.168\.1'"

    # log file, where to find sshd messages -- default /var/log/messages
    log_file="/var/log/messages"

    get_cidr_block() # IP_addr
    {
    echo $1 | gawk '
    BEGIN {
    # ip2cn-server socket
    service = "/inet/tcp/0/localhost/4743"
    }
    {
    print $1 " a" |& service
    service |& getline
    print
    }'
    }
    sort_uniq_ban_list() # ban_list_filename
    {
    local tmp=$(mktemp) || exit 1
    sort -t. -n -k1,1 -k2,2 -k3,3 -k4,4 < $1 \
    | uniq > $tmp && mv $tmp $1
    }
    # find failed ssh login IP addresses
    for x in $(awk '
    $5 !~ /^sshd/ {
    next
    }
    /not receive|Invalid/ {
    print $NF
    }
    /reverse map/ {
    gsub(/[[]/, "")
    gsub(/[]]/, "")
    print $12
    }
    ' $log_file | sort -t. -n -k1,1 -k2,2 -k3,3 -k4,4 | uniq \
    | egrep -v $exceptions)
    do
    # get CIDR block for each IP from ip2cn-server
    get_cidr_block $x >> $ban_list
    done

    sort_uniq_ban_list $ban_list

    [ "$1" == "-t" ] && cat $ban_list

    # end

    loading list into iptables
    ```````````````````````````
    #!/bin/bash
    ....
    block_entry_count=0

    load_iptables_chain_from_file() # file, chain_name, action
    {
    local addr="" rest=""

    while read addr rest # read from list
    do
    [ -z "$addr" ] && continue # ignore blank lines
    iptables -A $2 -p all -s $addr -j $3
    block_entry_count=$(( block_entry_count + 1 ))
    done < $1
    }

    ban_list="/usr/local/etc/ssh-ban-list-cidr"

    iptables -N ban_ssh
    block_entry_count=0
    load_iptables_chain_from_file $ban_list ban_ssh REJECT

    if [ $block_entry_count -gt 0 ]
    then
    iptables -A INPUT -j ban_ssh
    else
    iptables --delete-chain ban_ssh
    fi
    ....

    Grant.
    --
    http://bugsplatter.id.au/

+ Reply to Thread