On Fri, Dec 5, 2008 at 10:05 AM, Evgeniy Bushkov [EMAIL PROTECTED] wrote:
Adam Carter пишет:
Also take a note that there are no known-compromised hosts
What about hosts listed in RBLs?
http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. It would be
interesting to see if how much
Alan McKinnon wrote:
On Thursday 04 December 2008 21:03:17 Christian Franke wrote:
I just don't see what blocking ssh-bruteforce attempts should be good
for, at least on a server where few _users_ are active.
Two reasons:
a. Maybe, just maybe, you overlooked something. Belts,
Adam Carter пишет:
Also take a note that there are no known-compromised hosts
What about hosts listed in RBLs?
http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. It would be
interesting to see if how much correlation there is between ssh brute forcing
bots and the contents of
Steve пишет:
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
Previously, I noticed dictionary attacks launched - which were easy to
detect... and I've a process to block the IP address of any host that
repeatedly fails to authenticate.
Simon wrote:
Since it is very unlikely that the attacker is targeting you
specifically, changing the port number (and removing root access) will
very likely stop the attack forever. Though, if the attacker did
target you, then you will need some more security tools (intrusion
detection,
On December 3, 2008, Steve wrote:
Dmitry S. Makovey wrote:
Erm - surely I either need to set up my client to port-knock... which
is a faff I'd rather avoid... in order to use the technique.
nope. just start connection. wait a minute. cancel. start another one.
wait a minute. cancel.
On 12/03/2008 09:02 PM, Steve wrote:
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
I'm not particularly concerned - since I'm confident that all my users
have strong passwords... but it strikes me that this data identifies a
bot-net
On December 4, 2008, Christian Franke wrote:
I just don't see what blocking ssh-bruteforce attempts should be good
for, at least on a server where few _users_ are active.
Considering how much creative paranoia I've exposed in this thread it might
come as a surprise, but I do agree with the
On Thursday 04 December 2008 21:03:17 Christian Franke wrote:
On 12/03/2008 09:02 PM, Steve wrote:
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
I'm not particularly concerned - since I'm confident that all my users
have strong
Also take a note that there are no known-compromised hosts
What about hosts listed in RBLs?
http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. It would be
interesting to see if how much correlation there is between ssh brute forcing
bots and the contents of the various lists.
Open a Wiki page on Wikipedia, update it every so often and
provide simple
parser for it so others can recycle same IPs. Since it's a
Wiki page - others
can update it as well (including botnet owners, but then
they'd have to reveal themselves - tricky situation) :)
Reveal themselves in what
Also take a note that there are no known-compromised hosts
What about hosts listed in RBLs?
http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists. It
would be interesting to see if how much correlation there is
between ssh brute forcing bots and the contents of the various lists.
Maybe
Dmitry S. Makovey wrote:
On December 3, 2008, Steve wrote:
Dmitry S. Makovey wrote:
well. Nobody but you knows your requiremens and specifics - we're just
listing options. It's up to you to either take 'em or leave 'em ;)
Fair enough - but I've still not found an option for sharing/using
On December 4, 2008, Adam Carter wrote:
Open a Wiki page on Wikipedia, update it every so often and
provide simple
parser for it so others can recycle same IPs. Since it's a
Wiki page - others
can update it as well (including botnet owners, but then
they'd have to reveal themselves -
On Thursday 04 December 2008, Steve wrote:
Simon wrote:
Since it is very unlikely that the attacker is targeting you
specifically, changing the port number (and removing root access) will
very likely stop the attack forever. Though, if the attacker did
target you, then you will need some
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
Previously, I noticed dictionary attacks launched - which were easy to
detect... and I've a process to block the IP address of any host that
repeatedly fails to authenticate.
What I see now
You could try sshguard or denyhosts.
On Wed, Dec 3, 2008 at 2:02 PM, Steve [EMAIL PROTECTED] wrote:
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
Previously, I noticed dictionary attacks launched - which were easy to
detect... and I've a process to block the IP address
On Wednesday 03 December 2008 22:02:43 Steve wrote:
I've recently discovered a curious pattern emerging in my system log
with failed login attempts via ssh.
Previously, I noticed dictionary attacks launched - which were easy to
detect... and I've a process to block the IP address of any host
On December 3, 2008, Steve wrote:
Sure, I could use IPtables to block all these bad ports... or... I could
disable password authentication entirely... but I keep thinking that
there has to be something better I can do... any suggestions? Is there
a simple way to integrate a block-list of
Thanks for all the replies so far... I'll reply once to these... (Oh,
and when I said ports in my original post, I meant addresses - my
typing fingers just ignored my brain...)
I'm against a 'novel port' approach - as I am against port-knocking (for
my server) because these may prove challenging
On December 3, 2008, Steve wrote:
I have, in the past, used DSA only keys - but this was frustrating on
several occasions when I wanted access to my server and didn't have my
SSH keys available to me... I almost always connect using a key pair
rather than a password - but the password option
I previously used denyhosts - but (I can't remember why) it became
preferable to block with IPtables rather than with
tcpwrappers... which
prompted me to dump it in favour of a bespoke script based upon
blacklist.py (http://blinkeye.ch/mediawiki/index.php/SSH_Blocking) -
though, now, I'm
Dmitry S. Makovey wrote:
P.S. I actually don't do any of the above. It was just a surge of creative
paranoia
in response to initial request :)
All good ideas - except selling the blacklist... I'd be happiest to
share my blacklist for free... my objective is to minimise exposure to
botnets -
On Wed, Dec 3, 2008 at 4:55 PM, Steve [EMAIL PROTECTED] wrote:
Dmitry S. Makovey wrote:
P.S. I actually don't do any of the above. It was just a surge of creative
paranoia
in response to initial request :)
All good ideas - except selling the blacklist... I'd be happiest to
share my
On December 3, 2008, Paul Hartman wrote:
Of course, this is assuming the botnet stops after rejected connections...
oh no, not rejected - dropped ;) let them go through pains of timing out
without knowing if anything is actually listening on the other side ;)
--
Dmitry Makovey
Web Systems
Paul Hartman wrote:
I think using Dmitry's idea of rejecting the first 2 connections, but
then allowing it as normal on the third attempt would satisfy your
requirements for being on the normal port, allowing all IPs and
requiring no special setup on the client end (other than knowing they
On December 3, 2008, Steve wrote:
Paul Hartman wrote:
I think using Dmitry's idea of rejecting the first 2 connections, but
then allowing it as normal on the third attempt would satisfy your
requirements for being on the normal port, allowing all IPs and
requiring no special setup on the
Dmitry S. Makovey wrote:
Erm - surely I either need to set up my client to port-knock... which
is a faff I'd rather avoid... in order to use the technique.
nope. just start connection. wait a minute. cancel. start another one. wait a
minute. cancel. start new one - voila! :)
Eeew...
I noticed the same thing on my host several weeks ago.
I strongly suggest removing root access to your ssh, root is probably being
tried by more than 50% of all login attempts... the other trials are
semi-intelligent random usernames (ie, users that might really well exists, like
'apache'
30 matches
Mail list logo
