Re: understanding netstat -ap

[Eric Bambach <eric@cisu.net>]

Yawar,

 Your concern is very valid. However in our case our range of people we want 
to use SSH is very small so the probability of them getting caught in the 
crossfire is pretty small.

 In regards to auto-blacklisting, I suggest you look at the module. It will 
auto-blacklist after a predefined limit of tries, default is 10 failed 
attempts per hour which I think is very generous. The default is then to 
blacklist them for 2 days. If you want to be more swift you could configure 
it to be 5 failures in 10 minutes and blacklist for 2 hours which I dont 
think would be too intrusive but would still thwart most attempts.
 
 Furthermore, who cares if they are zombies. An attack is an attack. If the 
attacker can only complete 5 guesses per 2 days he would need hundreds of 
thousands (if not millions) of zombies testing you at the same time to 
sucessfully brute force a password.

 Also you may not realize but this particular method REALLY messes with an 
attackers attempts in that he does not realize he is blacklisted. What he 
will end up with is huge tracts of untested space in his dictionary whereas 
he believes he has tested all that space.

 There is also a tool to unblock a user/host easily. Combine this with a php 
or perl frontend a user can easily unblock himself if he/she has be 
wrongfully blocked. The pontential benifit far outweighs an occasional 
accidental blocking.

 I think the benifits far outweigh the costs. I could see if you were a shell 
server with hundreds to thousands of users where the accidental blocking 
might cause a problem. But for any other type of server there really is no 
reason NOT to use pam_abl. Most servers are limited to being ssh'ed by a 
small set of users/administrators anyways from limited IP spaces.


On Sunday 18 September 2005 03:10 pm, Yawar Amin wrote:
> On 9/19/05, Eric Bambach <eric@cisu.net> wrote:
> [...]
>
> >  Although it wont stop the connections, what pam_abl does is
> > auto-blacklist the host after so many failed attempts. They can still try
> > to log in and it looks like they're authenticating but even if they have
> > a correct username/password pair they will be denied! Its quite a nifty
> > module.
>
> [...]
>
> We're facing this problem also. We've considered auto-blacklisting
> hosts like you say, but what if these hosts are actually simply
> zombies taken over for launching brute force attacks, or external IP
> addresses for a whole range of NAT'd hosts, any one of which might be
> the attacker, and the rest innocent bystanders?
>
> You could remove them from the blacklist after a while, perhaps. Or
> maybe not. The problem remains: how to blacklist them very swiftly
> when it's decided they're trying a brute force, and then whitelist
> them again after a while so that nobody else suffers because of the
> bad guys.

-- 
----------------------------------------
--EB

> All is fine except that I can reliably "oops" it simply by trying to read
> from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?

The latitude and longtitude of the bios writers current position, and
a ballistic missile.

                --Alan Cox LKML-December 08,2000 

----------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs