Apr 10 19:07:57 linux-d1x3 sshd[4569]: Invalid user oracle from 80.191.117.91
Apr 10 19:08:00 linux-d1x3 sshd[4572]: Invalid user oracle from 80.191.117.91
Apr 10 19:08:03 linux-d1x3 sshd[4575]: Invalid user test from 80.191.117.91
Apr 10 19:08:05 linux-d1x3 sshd[4579]: Invalid user test from 80.191.117.91
Apr 10 19:08:08 linux-d1x3 sshd[4582]: Invalid user test from 80.191.117.91
Apr 10 19:08:10 linux-d1x3 sshd[4585]: Invalid user test from 80.191.117.91
Apr 10 19:08:13 linux-d1x3 sshd[4588]: Invalid user test from 80.191.117.91
Apr 10 19:08:16 linux-d1x3 sshd[4591]: Invalid user test1 from 80.191.117.91
Apr 10 19:08:18 linux-d1x3 sshd[4595]: Invalid user test from 80.191.117.91
Apr 10 19:08:21 linux-d1x3 sshd[4598]: Invalid user cvsuser from 80.191.117.91
Apr 10 19:08:29 linux-d1x3 sshd[4609]: Invalid user user1 from 80.191.117.91
Apr 10 19:08:31 linux-d1x3 sshd[4613]: Invalid user user1 from 80.191.117.91
Apr 10 19:08:34 linux-d1x3 sshd[4616]: Invalid user ftpuser from 80.191.117.91
Apr 16 15:03:12 linux-d1x3 sshd[19738]: Invalid user jeffrey from 202.107.209.33
Apr 16 15:03:14 linux-d1x3 sshd[19743]: Invalid user andres from 202.107.209.33
Apr 16 15:03:17 linux-d1x3 sshd[19786]: Invalid user andrei from 202.107.209.33
Apr 16 15:03:19 linux-d1x3 sshd[19811]: Invalid user vincent from 202.107.209.33
Apr 16 15:03:21 linux-d1x3 sshd[19815]: Invalid user tina from 202.107.209.33
Apr 16 15:03:24 linux-d1x3 sshd[19820]: Invalid user roland from 202.107.209.33
Apr 16 15:03:26 linux-d1x3 sshd[19824]: Invalid user kim from 202.107.209.33
Apr 16 15:03:28 linux-d1x3 sshd[19828]: Invalid user gnats from 202.107.209.33
Apr 16 15:03:30 linux-d1x3 sshd[19832]: Invalid user elizabeth from 202.107.209.33
Apr 16 15:03:33 linux-d1x3 sshd[19836]: Invalid user content from 202.107.209.33
so the hacker try to connect every 3 seconds…
so FW_SERVICES_ACCEPT_EXT don’t seem to do its job…
on the web, some people put FW_CONFIGURATIONS_EXT empty
i don’t really understand why… it’s it ok to put nothing when we want to allow ssh?
how to block the ip after 2 failed attempts?
in /etc/ssh/sshd_config i put
MaxAuthTries 3
don’t know if that will stop the hacker to try to connect every 3 seconds?
I did a little bit of google search and one result from bugzilla discussion was related to the fact that “the first firewall rule will apply <<as is>> so conesquently the next settings will be ignored”.
This would be the explanation to
on the web, some people put FW_CONFIGURATIONS_EXT empty
if
FW_CONFIGURATIONS_EXT=“sshd”
is the first rule in the chain it will work as it is - no limitations
I might be wrong about it since I can’t look at the moment to the rules / documentation but I think it’s worth trying to leave that line empty and use only the second one.
Another useful thing to make it hard for the script kiddies would be to change the default sshd port and ask your users to use key auth instead of the normal user / pass.
On 04/17/2010 10:26 AM, collinm wrote:
>
> hi
>
> i have a machine who run opensuse 11.2 with a sshd server open
>
> i checked in the log and i have
>
>
> Code:
> --------------------
> Apr 10 19:07:57 linux-d1x3 sshd[4569]: Invalid user oracle from 80.191.117.91
> Apr 10 19:08:00 linux-d1x3 sshd[4572]: Invalid user oracle from 80.191.117.91
<snip>
> --------------------
>
>
> so the hacker try to connect every 3 seconds…
The most important thing, as always, is to have strong passwords.
You should be fine, those attempt are just usual noise then.
On Sat, 17 Apr 2010 07:26:01 +0000, collinm wrote:
> in /etc/ssh/sshd_config i put
> MaxAuthTries 3
>
> don’t know if that will stop the hacker to try to connect every 3
> seconds?
You might try looking at fail2ban - I’ve not used it (yet, but
coincidentally I noticed someone trying to hack into my ftp server last
night and just set a firewall rule to deal with it), but I hear it’s
pretty good at dealing with this kind of thing.
What you’ve put in won’t block them, but will just reset the
authentication cycle IIRC (ie, the password prompt for interactive
attempts would ask 3 times and then fail, and they’d have to start over).
The more often I read this great advice of installing a tool like fail2ban/blockhosts etc. to “improve security” or even to “block an attack”, the more I wish something like this
On 04/18/2010 05:36 PM, Akoellh wrote:
>
> The more often I read this great advice of installing a tool like
> fail2ban/blockhosts etc. to “improve security” or even to “block an
> attack”, the more I wish something like this
>
> ‘Attacking Log Analysis tools’
> (http://www.ossec.net/main/attacking-log-analysis-tools)
>
> will happen again, soon (the sooner the better).
>
> This is even more true if this “attack” is the standard “background
> noise” of the internet today.
>
>
There it says that the attacker can attempt to log in by hiding the real
IP and thus being allowed to attempt to log in.
He still can’t log in, just attempt to.
Blockhosts and similar only keep logs tidier if you like, nothing else.
They are not security measures in any manner.
Vahis
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.12-0.2-default
18:46pm up 23 days 22:04, 15 users, load average: 0.20, 0.33, 0.30
On 04/18/2010 07:06 PM, Akoellh wrote:
>
> Vahis;2154268 Wrote:
>> Blockhosts and similar only keep logs tidier if you like, nothing else.
>
> There is something else, they open up another potential attack vector,
> for no reason.
>
> And as …
>
> Vahis;2154268 Wrote:
>>
>> They are not security measures in any manner.
>
> . it does not make real sense to use them.
>
>
I agree. Like I wrote to OP:
“The most important thing, as always, is to have strong passwords”.
“Strong” can be discussed, of course.
Mine are over 20 characters, with numbers and upper and lower case mixed.
They or parts of them can’t be found in any dictionary in any language.
That’s how I think I’ve kept them strong.
Vahis
http://waxborg.servepics.com
openSUSE 11.2 (x86_64) 2.6.31.12-0.2-default
19:12pm up 23 days 22:30, 15 users, load average: 0.20, 0.20, 0.19
On Sun, 18 Apr 2010 16:06:02 +0000, Akoellh wrote:
> Vahis;2154268 Wrote:
>> Blockhosts and similar only keep logs tidier if you like, nothing else.
>
> There is something else, they open up another potential attack vector,
> for no reason.
>
> And as …
>
> Vahis;2154268 Wrote:
>>
>> They are not security measures in any manner.
>
> . it does not make real sense to use them.
If you addressed me, see above, using key based login will “disarm” any password based brute force login attacks and this is what the OP was asking, how to block this attack.
You can not deny the attacker to send packages to your machine without disconnecting him (telekinesis anyone?) or disconnecting your machine from the net, so what’s the point of installing any additional software which opens up further attack vectors (it always does, more code = more potential bugs, but in this case there are examples for such bugs, see link posted before) without really blocking anything?
If there were a (D)DoS attack going on, this also would not help at all, the moment the packets arrive at your machine, it has to deal with them, given enough “power” of the attacker(s) it does not make any difference, if the (D)DoS will take down the machine because of too many packets being rejected by SSHD or too many packets being rejected by a packet filtering/host blocking mechanism.
However, as the “attack” described in the first posting is the “usual background noise” if the internet today, I don’t see the need of an alternative except using pubkeys, which should be used in any way.
On Mon, 19 Apr 2010 09:36:01 +0000, Akoellh wrote:
> If you addressed me, see above, using key based login will “disarm” any
> password based brute force login attacks and this is what the OP was
> asking, how to block this attack.
That works for ssh (and in fact I use that myself), but what about for
attacks on ftp services or other services?
On Mon, 19 Apr 2010 17:26:01 +0000, FeatherMonkey wrote:
> sftp maybe, from my brief look it supports key auth.
That’s one option, but not everyone has an sftp client - you could also
ask about dealing with failed auths through a webpage.
> I’m actually curious about this subject. How about reversing the
> question how do you stop the log parsers adding false positives?
The simplest way, from what I’ve read, is to stay current; the article
Akoellh referenced talked about one attack that is already defeated by an
updated pattern.
But this sort of thing is always (IME) a cat and mouse game - I have to
admit that I’m somewhat curious about the supposed arbitrary code
execution issues in some of these tools, not quite sure how you get to
that point.
