[lug] DOS ssh attacks

[karl horlen]

since this topic is relevant,i'm wondering if someone can explain something to me about DOS attacks.

most of those replying here are offering firewall solutions that block certain ips based on x condition.

although this helps the problem somewhat, it doesn't really solve it does it?  

what i mean is that the firewall is still going to get bombarded by the *same* *number* of rogue requests meaning it still has to process them.  immediately dropping the packets seems like it would definitely decrease the load on the firewall, but if the firewall still has to process each packet, i would think you would still be able to clog a firewall to the point where whatever it's routing to behind it becomes unreachable or slow beyond use.

the oddity being that if the firewall is a separate device from the target server it routes too, the server itself will not have any performance issues.  but since the firewall is the "gatekeeper" to get to the server, won't dos attacks on the firewall adversely impact whatever services you have running on the server regardless if the firewall drops said packets?  or am i barking up the wrong tree?

in the case where a firewall lives on the target server, then it would seem like you're screwed regardless.

i've always wanted to know this about DOS attacks.  it seems like they win regardless of what you do on a firewall.  most of us never get hit with them so we're lucky.

thanks to anyone who can clarify for me or post a real life scenario with before and after server performance results.


--- On Sat, 1/10/09, George Sexton <gsexton at mhsoftware.com> wrote:

> From: George Sexton <gsexton at mhsoftware.com>
> Subject: Re: [lug] DOS ssh attacks
> To: "Boulder (Colorado) Linux Users Group -- General Mailing List" <lug at lug.boulder.co.us>
> Date: Saturday, January 10, 2009, 8:27 AM
> Here are some fragments from my IPTables scripts. They limit
> the number of bad login attempts permitted and then insert a
> lockout rule.
> 
> ALLOW_SSH_HOSTS="importanthost.mydomain.com"
> 
> 
> ########################################################################
> #       SSH RULES
> ########################################################################
> 
> iptables -F SSHRULES
> iptables -X SSHRULES
> iptables -N SSHRULES
> 
> #
> # If it's an already established session, let it
> continue.
> #
> iptables -A SSHRULES -m state --state ESTABLISHED,RELATED
> -j ACCEPT
> #
> # If it's a new session, rate limit it by IP address
> using the
> # RECENT module.
> #
> if [ ! -z "$ALLOW_SSH_HOSTS" ]; then
>  for THISHOST in $ALLOW_SSH_HOSTS; do
>    THISIP=`host $THISHOST | cut -f 4 -d " "`
>    iptables -A SSHRULES -m state --state NEW --source
> $THISIP -j ACCEPT
>   done
> fi
> 
> iptables -A SSHRULES -m state --state NEW -m recent --name
> SSHPROBES \
> 	--set
> iptables -A SSHRULES -m state --state NEW -m recent --name
> SSHPROBES \
>         --update --seconds 180 --hitcount 6 -j LOGDROP
> #
> # If we got here, we are a new connection and not violating
> the
> # rate limit.
> #
> iptables -A SSHRULES -j ACCEPT
> 
> ########################################################################
> #       END SSH RULES
> ########################################################################
> 
> iptables -A INPUT -i $WAN_IF -p tcp --dport ssh  -j
> SSHRULES
> 
> 
> 
> Rob Nagler wrote:
> > We've been under heavy attack the last 24 hours.
> The only annoyance is
> > that all the ssh connections are sucked up for a
> period of time so we
> > can't get in via certain machines public
> interfaces.  Blocking the
> > addresses in iptables fixes the problem.
> > 
> > This seems to be localized to our ViaWest hosts.  Our
> FRII rack is
> > always available.
> > 
> > Is anybody else experience this type of attack (see
> log entries
> > appended) right now?
> > 
> > Another question is: any tricks we can use to slow
> down requests to
> > ssh so we don't get locked out?
> > 
> > Thanks,
> > Rob
> > 
> >
> ----------------------------------------------------------------
> > Jan 10 08:53:37 host1 sshd(pam_unix)[28289]: check
> pass; user unknown
> > Jan 10 08:53:37 host1 sshd(pam_unix)[28289]:
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=217.219.159.13
> _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List:
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > Join us on IRC: lug.boulder.co.us port=6667
> channel=#colug
> 
> -- George Sexton
> MH Software, Inc.
> Voice: +1 303 438 9585
> URL:   http://www.mhsoftware.com/
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List:
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug