|
|
|
|
||||||
| comp.security.ssh SSH secure remote login and tunneling tools. |
![]() |
|
|
LinkBack | Outils de la discussion |
|
|
#1 |
|
Messages: n/a
Hébergeur: |
I used to run my ssh server on a high port no. to avoid the dictionary
attacks. It worked quite well but I've had to go back to good ol' port 22 because I've been plugging laptop into networks with *crazy* restrictions like blocking huge ranges of client ports except for specific services. So I've changed the server config to allow PubkeyAuthentication only, and that's working fine, BUT the dictionary attacks are still coming. (See below for the sort of stuff I mean, in syslog.) AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm surprised the attacking "clients" try it. Am I right? Why do they keep trying? Anything else I can/should do? Thanks! Invalid user webmaster from 24.148.29.250 Invalid user ftp from 24.148.29.250 Invalid user sales from 24.148.29.250 Invalid user admin from 24.148.29.250 Invalid user andrea from 24.148.29.250 Invalid user guest from 24.148.29.250 Invalid user guest1 from 24.148.29.250 Invalid user guest2 from 24.148.29.250 Invalid user guest3 from 24.148.29.250 Invalid user guest4 from 24.148.29.250 Invalid user guest5 from 24.148.29.250 Invalid user guest6 from 24.148.29.250 Invalid user guest7 from 24.148.29.250 Invalid user guest8 from 24.148.29.250 Invalid user guest9 from 24.148.29.250 |
|
|
|
#2 |
|
Messages: n/a
Hébergeur: |
Nomen Nescio wrote:
> I used to run my ssh server on a high port no. to avoid the dictionary > attacks. It worked quite well but I've had to go back to good ol' port > 22 because I've been plugging laptop into networks with *crazy* > restrictions like blocking huge ranges of client ports except for > specific services. > > So I've changed the server config to allow PubkeyAuthentication only, > and that's working fine, BUT the dictionary attacks are still > coming. (See below for the sort of stuff I mean, in syslog.) > > AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm > surprised the attacking "clients" try it. Am I right? Why do they keep > trying? Anything else I can/should do? How should they know you have disabled password authetication? (you did, didn't you?) -- Cezary Morga |
|
|
|
#3 |
|
Messages: n/a
Hébergeur: |
Nomen Nescio <nobody@dizum.com> wrote:
> I used to run my ssh server on a high port no. to avoid the dictionary > attacks. It worked quite well but I've had to go back to good ol' port > 22 because I've been plugging laptop into networks with *crazy* > restrictions like blocking huge ranges of client ports except for > specific services. I've thought about a stupid simple web page (most sites would allow 80) that I could type in an IP address and enable that address for port 22. Even with *zero* authentication on the web page, I don't think it would be a problem. A bot isn't going to do that kind of work for one host. > AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm > surprised the attacking "clients" try it. Am I right? Why do they keep > trying? Stupid bots don't care. -- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > |
|
|
|
#4 |
|
Messages: n/a
Hébergeur: |
Nomen Nescio <nobody@dizum.com> writes:
>I used to run my ssh server on a high port no. to avoid the dictionary >attacks. It worked quite well but I've had to go back to good ol' port >22 because I've been plugging laptop into networks with *crazy* >restrictions like blocking huge ranges of client ports except for >specific services. >So I've changed the server config to allow PubkeyAuthentication only, >and that's working fine, BUT the dictionary attacks are still >coming. (See below for the sort of stuff I mean, in syslog.) >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm >surprised the attacking "clients" try it. Am I right? Why do they keep >trying? Anything else I can/should do? Do you thinkthat there is a human being behind those attacks, trying all the passwords? It is a program. which is launched from someone else's computer. You could just put that IP address into /etc/hosts.allow with a deny tag for ssh. sshd: 24.148.29.250:deny >Thanks! >Invalid user webmaster from 24.148.29.250 >Invalid user ftp from 24.148.29.250 >Invalid user sales from 24.148.29.250 >Invalid user admin from 24.148.29.250 >Invalid user andrea from 24.148.29.250 >Invalid user guest from 24.148.29.250 >Invalid user guest1 from 24.148.29.250 >Invalid user guest2 from 24.148.29.250 >Invalid user guest3 from 24.148.29.250 >Invalid user guest4 from 24.148.29.250 >Invalid user guest5 from 24.148.29.250 >Invalid user guest6 from 24.148.29.250 >Invalid user guest7 from 24.148.29.250 >Invalid user guest8 from 24.148.29.250 >Invalid user guest9 from 24.148.29.250 |
|
|
|
#5 |
|
Messages: n/a
Hébergeur: |
Darren Dunham <ddunham@redwood.taos.com> writes:
>Nomen Nescio <nobody@dizum.com> wrote: >> I used to run my ssh server on a high port no. to avoid the dictionary >> attacks. It worked quite well but I've had to go back to good ol' port >> 22 because I've been plugging laptop into networks with *crazy* >> restrictions like blocking huge ranges of client ports except for >> specific services. >I've thought about a stupid simple web page (most sites would allow 80) >that I could type in an IP address and enable that address for port 22. >Even with *zero* authentication on the web page, I don't think it would >be a problem. A bot isn't going to do that kind of work for one host. Or you could simply have your ssh respond to port 80. Unless you actually have a web server running on that machine, that will be fine. >> AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm >> surprised the attacking "clients" try it. Am I right? Why do they keep >> trying? >Stupid bots don't care. >-- >Darren Dunham ddunham@taos.com >Senior Technical Consultant TAOS http://www.taos.com/ >Got some Dr Pepper? San Francisco, CA bay area > < This line left intentionally blank to confuse you. > |
|
|
|
#6 |
|
Messages: n/a
Hébergeur: |
Nomen Nescio <nobody@dizum.com> writes:
> Why do they keep > trying? Because they're script kiddie attacks and will try no matter what your config. > Anything else I can/should do? Just move sshd to listen on a non-standard port and the annoyance will cease. -- Todd H. http://www.toddh.net/ |
|
|
|
#7 |
|
Messages: n/a
Hébergeur: |
Todd H. wrote:
> Nomen Nescio <nobody@dizum.com> writes: > >> Why do they keep >> trying? > > Because they're script kiddie attacks and will try no matter what your > config. > >> Anything else I can/should do? > > Just move sshd to listen on a non-standard port and the annoyance will > cease. > Or just don't worry about it if you've disabled password authentication. That keeps them busy trying hopelessly to get into your server instead of attacking one that's truly vulnerable. |
|
|
|
#8 |
|
Messages: n/a
Hébergeur: |
Chuck <skilover_nospam@bluebottle.com> writes:
> Todd H. wrote: > > Nomen Nescio <nobody@dizum.com> writes: > > > >> Why do they keep > >> trying? > > > > Because they're script kiddie attacks and will try no matter what your > > config. > > > >> Anything else I can/should do? > > > > Just move sshd to listen on a non-standard port and the annoyance will > > cease. > > > > Or just don't worry about it if you've disabled password authentication. > That keeps them busy trying hopelessly to get into your server instead > of attacking one that's truly vulnerable. If the sshd server isn't there to listen to an attack on port 22, sshd won't cut a failed login attempt to a log. The host level port filter will just quietly ignore the tcp connection request. Seems to work a treat. -- Todd H. http://www.toddh.net/ |
|
![]() |
| Outils de la discussion | |
|
|