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

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.

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.)

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.

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

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