u3b3rg33k
11-05-2008, 11:36 AM
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
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