Results 1 to 6 of 6
  1. #1
    Master Untangler u3b3rg33k's Avatar
    Join Date
    Nov 2008
    Posts
    234

    Default attack blocker not noticing ssh brute force attempts?

    If this post shows up twice, sorry (seems as thought the bit bucket in the sky ate it).

    It appears as though I've been under attack by a computer somewhere hell bent on brute forcing the root user via ssh. since I don't allow root login externally, it's not a problem. the fact that neither attack blocker or intrusion prevention are picking it up is. (I didn't see a bad login option in intrusion prevention for ssh)

    related thread: http://forums.untangle.com/showthread.php?t=5403

    what got my attention was when I noticed 75 open connections to the ssh gateway on my network (separate machine for added security). it's usually fewer than that, but each connection attempts to login once every 5 seconds, until it's disconnected for failing by ssh.

    UT is in bridge mode between the T1 router / firewall and the switch.
    Since UT doesn't seem to be interested in this traffic, I put this rule into my firewall (I found it while trying to learn about iptables, so no credit is due me for it's conception):

    # create properREJECT chain that does different rejects for tcp/udp
    iptables -N properREJECT
    iptables -A properREJECT -p tcp -j REJECT --reject-with tcp-reset
    iptables -A properREJECT -j REJECT --reject-with icmp-port-unreachable
    #
    iptables -N blacklistdrop
    iptables -A blacklistdrop -j LOG --log-prefix "adding to BLACKLIST: "
    iptables -A blacklistdrop -m recent --name BLACKLIST --set -j DROP
    #
    #
    # on external hosts, do rate limiting on incoming ssh packets, and keep a blacklist for 30 seconds
    # this rule drops *any* packet if the IP is in the blacklist
    # icmp 'destination-unreachable' packets should not update BLACKLIST, because
    # they are generated by our own REJECT rule in the extern_out chain
    iptables -A extern_in -m recent --name BLACKLIST --update --seconds 120 -j DROP
    #
    # all *established* ssh connections simply continue
    iptables -A extern_in -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
    #
    # *new* ssh connections are all put into a list 'sshconn', and if there are 3 such packets in 30 seconds
    # we send the package to chain 'blacklistdrop' which puts the IP in the blacklist
    iptables -A extern_in -p tcp --dport 22 -m state --state NEW -m recent --name sshconn --rcheck --seconds 30 --hitcount 3 -j blacklistdrop
    #
    # if we have seen less then 3 such packets in the last 30 seconds we accept
    iptables -A extern_in -p tcp --dport 22 -m state --state NEW -m recent --name sshconn --set -j ACCEPT
    #
    # if the destination address is in the blacklist, we REJECT *any* packet
    iptables -A extern_out -m recent --name BLACKLIST --rdest --rcheck --seconds 30 -j properREJECT
    #
    # outgoing we accept all ssh traffic, with connection tracking
    iptables -A extern_out -p tcp --sport 22 -m state --state ESTABLISHED,NEW,RELATED -j ACCEPT

  2. #2
    Untanglit SirLoxElroy's Avatar
    Join Date
    Nov 2008
    Location
    A Hole with 47 Computers
    Posts
    17

    Default Same Here, but more

    I am also getting slammed with SSH login attacks that neither attack blocker, nor ID is picking up. I have also tried creating rules in "Firewall" to block and log it, however that did not do any good either. I did have it port forwarded to another machine through untangle, have had to shut it off as it was bringing that machine to it's knees. I have tried in "Firewall" to block and log everything to see, it blocks everything, but logs nothing.

    One other thing I am seeing is OpenVPN, of which only one person is setup (me) and I am not on it, plus it is also set for the untangle default port, is getting session spikes of up to 10 under sessions, but logging nothing.

  3. #3
    Master Untangler Evil_Bert's Avatar
    Join Date
    Nov 2007
    Location
    Sydney, Australia
    Posts
    119

    Default

    I just want to pose the question - and perhaps an UT guru can confirm or deny - but why would UT's ID or Attack Blocker prevent SSH login attempts? SSH login is a valid function - how can UT tell the difference between a 'good' and 'bad' SSH login attempt?

    (Also, for the OP - maybe you already know this, and at the risk of being mistaken since I don't know what clients you're running or your network setup - have you tried fail2ban or denyhosts? That might be easier to manage than custom firewall rules.)
    There are many alternate universes, but only this one has beer.

  4. #4
    Master Untangler u3b3rg33k's Avatar
    Join Date
    Nov 2008
    Posts
    234

    Default

    I haven't, but I'm considering putting in a rule into the ssh machine to do a 30 minute ban for failed login attempts.

  5. #5
    Untangler doubtintom's Avatar
    Join Date
    Aug 2007
    Posts
    78

    Default

    DenyHosts is a great tool. fail2ban is also mentioned. DH pools known hacker IPs so you share protection information from all other users. Pretty comprehensive.

    http://en.wikipedia.org/wiki/DenyHosts
    Tom

  6. #6
    Master Untangler u3b3rg33k's Avatar
    Join Date
    Nov 2008
    Posts
    234

    Default

    Cool beans. I'm going to look into DH further.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2