From: Tim <t....@co...> - 2005-03-02 04:28:56
|
Les Gondor wrote: > > > Tim wrote: > >> Bruce Smith wrote: >> >>>>> I had a SnapGear firewall linux appliance with IDB (Intrusion >>>>> Detection >>>>> and Blocking) - it actually worked fairly well. You set it up to >>>>> trigger on >>>>> obvious TCP ports like MSSql (1433) or Netbios (137/8/9). Anybody who >>>>> scans me on those ports I don't want in on any port... UDP is not good >>>>> because it's too easy too forge. >>>>> >>>>> I don't know if that was proprietary or opensource tho... but it's not >>>>> really rocket science. It might be nice to auto-expire the entries if >>>>> possible. >>>>> >>>>> Does iptables now do this? >>>>> >>>> >>>> >>>> The problem with any automated procedures is, that you're very >>>> vulnerable >>>> to DoS attacks. >>>> Scenario: >>>> You automatically block all IPs with invalid connection attempts. >>>> I 'attack' your firewall, but forge the sender IPs. You will >>>> automatically >>>> block all those IPs for a while. >>>> I can get you to block your mail servers, access to the root DNS server >>>> and to whatever *I* please. >>>> >>>> You see although it's in theory a good idea, it's just to exploitable. >>>> >>> >>> >>> >>> You can do limited automated blocking under some circumstances if you're >>> careful. >>> >>> For example, look at the logs for a machine with an open SSH port to the >>> internet. I'm being hit with dictionary attacks trying to guess a valid >>> SSH login on all my boxes that allow SSH (and I bet you are too). >>> >>> You can "solve" the problem by not allowing password authentication >>> (only allowing RSA/DSA keys or some better method), but it doesn't stop >>> crackers from trying to login anyway (and filling your logs with >>> crap). So I started playing with some iptables rules ... >>> >>> Here are my rules from a web/ftp server - only one NIC - NOT a firewall: >>> (some IP numbers in the following example have been changed) >>> >>> ------------------------------------------------------------------------------------- >>> >>> ${IPTABLES} -P INPUT DROP >>> ${IPTABLES} -P OUTPUT ACCEPT >>> ${IPTABLES} -P FORWARD DROP >>> >>> # special handling for SSH (to dwarf SSH dictionary attacks) >>> ${IPTABLES} -N SSH-attack >>> ${IPTABLES} -A SSH-attack -m recent --name SSHattack --set -j LOG >>> --log-level DEBUG --log-prefix "SSH-attack: " >>> ${IPTABLES} -A SSH-attack -j DROP >>> # >>> ${IPTABLES} -N SSH >>> ${IPTABLES} -A SSH -s 192.168.1.22 -j ACCEPT # allow my >>> desktop without restriction >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHattack --rcheck >>> --seconds 300 -j DROP >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --rcheck >>> --seconds 60 --hitcount 3 -j SSH-attack >>> ${IPTABLES} -A SSH -p TCP --syn -m recent --name SSHconn --set >>> ${IPTABLES} -A SSH -p TCP --syn -j ACCEPT >>> >>> # Local interface - do not delete! >>> ${IPTABLES} -A INPUT -i lo -j ACCEPT >>> >>> # Allow established connections. >>> ${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT >>> >>> # Allow all Pings, FTP, HTTP, NTP >>> ${IPTABLES} -A INPUT -p icmp -j ACCEPT >>> ${IPTABLES} -A INPUT -p tcp -i ${OUT_DEV} -m mport --ports 20:21,80 >>> -j ACCEPT >>> ${IPTABLES} -A INPUT -p udp -i ${OUT_DEV} -s 192.168.1.0/24 --dport >>> 123 -j ACCEPT >>> >>> # special SSH connection limiting >>> ${IPTABLES} -A INPUT -p tcp --dport 22 -i ${OUT_DEV} -j SSH >>> ${IPTABLES} -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG >>> --log-prefix "INPUT policy: " --log-level DEBUG >>> ------------------------------------------------------------------------------------- >>> >>> >>> It _always_ allows the standard services of the box (HTTP, FTP, etc.) >>> so they CANNOT be DoS'ed no matter what. It also allows established SSH >>> connections to keep running, even if new connections are blocked from >>> the same IP address. >>> >>> If it receives more than 3 SSH new connects (valid or invalid) within 60 >>> seconds from the same IP, it blocks the source IP from connecting to >>> port 22 for 5 minutes. SSH only logs the first three invalid connects >>> and iptables logs the special message of "SSH-Attack:" once, then it >>> shuts down the IP for 5 minutes. By the time 5 minutes expires the >>> cracker has given up and moved on to a different box. (maybe yours? :) >>> >>> These rules be a problem if I do a bunch of "scp" commands in a short >>> amount of time, but I'm aware of this and it's usually not a problem. >>> >>> I also bypass my primary workstation from this test, so I only have to >>> worry about connecting too frequently when I'm home or "on the road". >>> >>> And sure, someone could DoS me from SSH'ing into that box, but it's >>> highly unlikely since I do it so infrequently, and they'd have to know >>> the random IP I get at home, or on the road. >>> >>> BTW, the "recent" module can be used to create a port-knocking setup >>> too, which I may play with next ... >>> >>> - BS >>> >>> >>> >>> >> SSH is over TCP, so if the attacker actually wants to send password >> attempts, they can't forge their return IP can they? Therefore sites >> failing logon numerous times could be blocked completely without fear >> of DOS attack? >> >> Tim >> >> > > Well, yes, if you assume that the purpose of the attack is to gain > access. If I merely want to DoS the SSH server, then I don't care if the > access denied packets go into the bit bucket; it's the automatic > blocking of the (forged) IP that is of interest to me. > > Les > Yes, but the connection could never progress past the initial tcp handshake, never mind actually negotiate encryption and send login attempts unless the attacker acknowledges tcp packets from the DL box, right? And to get those packets, it needs to be capable of receiving at the IP address it is supposedly sending from right? Which implies that it is the real address, or perhaps it is on the same subnet and is stealing it, or perhaps a compromised router. So the potential for DOS seems limited to me. Tim |