Re: ssh brute force attacks

From: Tony Lawrence (pcunix_at_gmail.com)
Date: 03/20/05


Date: 20 Mar 2005 14:45:11 -0800


Peter T. Breuer wrote:
> Tony Lawrence <pcunix@gmail.com> wrote:
> > Peter T. Breuer wrote:
> > > But that's precisely what your mechanism does do, and of course
we know
> > > what IP address you use! Why wouldn't we?
> >
> > We are talking about two entirely different things here.
>
> No we are not.
>
> > On the one
> > hand we have someone who deliberately wants to DOS me.
>
> Fine - and he does that by spoofing your IP address and doing failed
> logins to your target box, which causes the target to block your IP
for
> login attempts. Voila: DOS.

For the umpteenth time, assuming that the blocking script is stupid
enough to add that particular ip address at all or leave the block in
place for an extended period of time. Said it over and over again, but
you keep ignoring that.

>
> > On the other we
> > have the blocking of an ip due to an apparent break in.
>
> That's the mechanism used to effect the DOS by the person who wants
to
> DOS you. So why do you consider the two different things?

Because they are. It's EXTREMELY unlikely that anyone who was
attempting a real break in is going to turn around and do a DOS attack.
 Most of these failed ssh brute force attacks are scripted or entirely
autonomous.

But if someone does want to DOS you, they are going to do so anyway,
whether or not you block failed logins. And I bet this wouldn't even
be part of what they'd do, because simulating blind failed logins from
multiple addresses isn't all that easy. You'd have to know, guess, or
somehow algorithmetically determine my MaxStartups setting and I'm not
even sure that can be done algorithmetically because it's a
probability..

>
>
> > The first is pointless.
>
> So? Tell that to them, not me!

Your ARGUMENT is pointless, not the attack.

>
> > If someone wants to DOS my webserver, they do
>
> But they are not trying to - they are DOSing the login service on
> whatever machine you set up the blocking mechanism via failed logins.

I doubt it. For the reasons stated above, this is extremely unlikely.

>
> What's the big deal with that simple idea? Where do webservers come
> into this?

Just an example. Webserver, mailserver, music server - who cares? Why
do you zero in on unimportant details yet ignore the big picture?

>
> And if they want to find out where you normally log in from (why
should
> they bother?) they simply have to observe you doing a remote login.

Just how are you observing my remote login ?????

>
> > If you want to
> > annoy me at home, you might observe a newsgroup post.
>
> I don't understand you - nobody is imagining these special
situations.
> We only know that you have machines Y and X. Y has a blocking
mechanism
> triggered by failed logins. Fine. So we spoof X and fail a login to
Y.
> Hey presto - you're DOSed by your own blocking mechanism.

Right. But you keep ignoring that I'd never put X into Y's blocking
script and that you are going to have an extraordinarily difficult time
triggering this script doing it blind and trying to anticipate sshd's
Max Startups. It's hard enough without a spoofed IP; I bet you'd
waste a lot of time trying to do it and never even be sure you had
succeeeded. If you wanted to DOS me, this is too much work - there are
easier ways.

>
> > Great, you've
> > maybe got a dynamic Comcast address which will change the minute I
> > power off their router. So MAYBE you could deny me access to my
web
>
> I don't understand you. What are you on about?

If you do somehow manage to deny me access to my public server, I
simply reset my router and now I have a new IP. But as stated above, I
doubt you could do that anyway. You definitely couldn't do it to me,
because I'm going to reset the blocks anyway unless they are repeated
offenders. And I'm never going to block my own ip address - that would
be stupid.

>
> > server IF you assume that my filtering and blocking is dumb enough
to
> > put its own public address into the block list. Which it isn't,
but
> > even if it were, again it is reset in the morning automatically.
>
> I simply do not know what you are talking about. Or why!

Then you aren't reading, are you? You are assuming you know what is
being said, and setting up strawmen that you gleefully tear apart.

>
>
> > > Too many, too fast, and you're to slow. BTW, I run an automatic
denial
> > > scheme:
> >
> > Huh? I'm too slow? What on earth do you mean? Do you think I sit
> > here and review this stuff manually?
>
> Sure. How else can you tell?

How else can I tell? Sheesh.. I keep a database of ip's I've recently
blocked. I don't let it get very large, but I can compare it to what
I've blocked even more recently and decide algorithmically whether or
not to block them for a longer period this time.

>
> > Of course not: at a specific
> > time, a script runs that does certain things, like re-allowing
console
> > login, allowing access from the local network, unblocking adresses
that
> > have been blocked overnight, etc. As I explained earlier, I have
>
> Why would you unblock addresses that have been blocked? What's the
> point of blocking them if you are going to unblock them every day!
> Well, I suppose it would give you some relief, but it's not worth it
-
> you still will be DOSed after half an hour again.

Gawd, you really don't listen :-) Plus, you seem to be talking out of
both sides of your mouth!

Look, we're talking about blocking IP's that have shown antisocial
behavior. I unblock them after a period of time because they may be
dynamic. But if they show up again too soon, they will get blocked for
a longer period. Get it?

>
> For myself, I jealously guard my collection of blocked IPs!

And how do you arrive at these addresses? By some mechanism or do you
make them up? If it's by some mechanism, you could in theory be
spoofed also, so you seem to be taking both sides of the argument!

>
> No, I am not defending anything! I am simply trying to explain to you
> that an automatic blocking scheme leads to a DOS vulnerability,
> something which you seem stubbornly too dense to get, not matter how
> carefully and how slowly it is explained to you, and no matter how
hard
> your nose is rubbed in actual pictures of it.

Ahh, abusive Peter is here again. We really nned that industrial
sander. I suggest we start with a fairly rough grit - it may take a
while to get down to the fine sandpaper..

Shall I say that you rather stubbornly refuse to notice the extreme
difficulties of failing logins with a spoofed ip, and the reality that
most if not all such login failures would be from real hacking
attempts, most of which would be scripted?

No matter how many times I note these facts, you ignore them and
construct the same straw man that you can knock down to show how
foolish I am.

And most amazingly, apparently you block ip's yourself, which couldn't
possibly be a manual process because you've already crowed "Too slow!"
when you wrongfully assumed that was what I was doing. One has to
wonder just what YOU are talking about, Peter.

-- 
Tony Lawrence


Relevant Pages

  • Re: ssh brute force attacks
    ... >> Assuming you know my home machine's address and assuming my filter ... hand we have someone who deliberately wants to DOS me. ... have the blocking of an ip due to an apparent break in. ... ip's is a nice way of "introducing DOS attacks". ...
    (comp.os.linux.misc)
  • Re: ssh brute force attacks
    ... > Peter T. Breuer wrote: ... Voila: DOS. ... But they are not trying to - they are DOSing the login service on ... whatever machine you set up the blocking mechanism via failed logins. ...
    (comp.os.linux.misc)
  • Re: ssh brute force attacks
    ... If somebody wants to DOS me, ... As usual, dear Peter, while I truly respect and admire your ... But that can't be the case for someone who has failed login attempts, ... A DOS attack is not a break-in. ...
    (comp.os.linux.misc)
  • Re: ssh brute force attacks
    ... >> If he spoofs X AND THEN does some failed password attempts, yes, your ... >> to want to do a DOS on you. ... What if someone spoofs the IP?" ... or login timeout is exceeded at every attempt. ...
    (comp.os.linux.misc)
  • Re: ssh brute force attacks
    ... >>How is blocking a specific IP more inducive to a DOS attack than ... >>wouldn't the only DOS be syn floods? ... and you are blocking possibly legitimate IP addresses. ... "Blocking IPs because of failed logins is a nice way introducing DOS ...
    (comp.os.linux.misc)