SSH login attempts

heri0n · 10-27-2004, 10:25 AM

I was looking through /var/log/secure.1 and found I have also received many of these attempts, but the thing that troubles me is that, I actually got some connections accepted??? It said like public key accepted from...(my user).. ssh2 .. port...
They were from my user, and valid ips, one from my work, but the other one was 192.168.1.1 which is my router... when I connect from home it's my Windows box which is like .101 or something... So that was kind of suspicious. But the thing that caught my attention was that it was accepting connections on random ports instead of the standard 22.... which I have not changed. So I am not sure if my box has actually been compromised or not... How can I be sure? I've shut down my box seen finding those messages...

BenODen · 10-29-2004, 07:16 PM

I've noticed multiple people on this thread fighting very hard not to have their sshd's
listening on a non-standard port. Do all you guys have other users that are accessing your
linux boxes from the internet? I decided to put ssh up on a non-standard port and
haven't seen any downside yet, and I've seen no attempts to connect besides my
own. So, for a personal box, it seems like a no brainer...

Am I missing something?

-Ben

Darin · 10-30-2004, 05:11 AM

I've been noticing these attempts since I opened up ssh on my firewall and server. It appears to be some script for brainless wannabe crackers, at least thats what I found after for googling for ssh brute force (OK technically these attempts are so pathetic they barely qualify as brute force I know) and finding some scripts but nothing relevant as far as prevention.

I fiddled with my sshd_config some

LoginGraceTime 45s
PermitRootLogin no
MaxStartups 5:50:25

and changed my passwords to be even more paranoid.

I was thinking of blocking the IPs but some might be wannabe crackers from my ISP or my skool, in which case I would end up blocking myself out. Blocking IPs at the firewall sounds like a good idea at first but with decent security the only negative these attacks have on you is full logfiles while there is the potential to block legitimate users out of your system. This would happen since the attackers ISP probably doesn't give them a static IP and eventually even DSL and cable IPs get changed. Any users you want to access your system who have the same ISP as the offender could then be blocked out if they get the attacker's old IP address; not to mention the attacker then has a new IP and is no longer blocked. It is also possible that an attack could come from a legitimate but compromised system and you end up blocking a legitimate host (although if they are open enough to get hit by the pathetic scripts that I see attempting attacks in my logs then blocking them for good will probably prevent future attacks when the next script kiddie breaks into their system.)

I do like the non standard port thing, that's probably what I will do just to keep my logs from filling up.

What I was really hoping for was to find something that could be set in ssh to just do like a 15sec delay after a failed login or maybe do a 15min IP lockout after so many failed attempts from one source. Basically something that would be only mildly annoying if I mistyped my password but would slow any automated attacks down to a useless crawl.

dmoorhouse · 10-30-2004, 03:17 PM

Has anyone found a script/daemon that would monitor for such activity and then add the offending ip to the hosts.deny or drop chain of iptables in real time? I'm a network admin but not a programmer

All the blocking would then be automated and only the offending ip would be locked out as the attempts are made.

Dar

Bjorkli · 11-01-2004, 08:06 AM

This is a script that I found in another tread (hopefully not this one). Not sure who to credit for this script. I have not tried it on my machine yet, but it seems to be a good script.

Seems to add offending IP (hosts) to the iptables (firewall) rules.

Code:

#!/bin/sh

# Settings:
iptables="/sbin/iptables"
blockchain="blocking"
blocktarget="blacklist"

# This program will match lines:
# Illegal user (userid) from (host)
# Failed password for (userid) from (host) (...)
# and adds (host) to the iptables blacklist chain
# $blockchain.
#
#This chain is cleared regularly by a separate
# script to let entries expire after a while.

while read mm dd hms localhostname sshd word1 word2 word3 word4 host1 host2 rest; do
if [ "$word1 $word2 $word4" = "Illegal user from" ]; then
$iptables -A $blockchain -s ${host1}/32 -j $blocktarget
elif [ "$word1 $word2 $word3 $host1" = "Failed password for from" ]; then
$iptables -A $blockchain -s ${host2}/32 -j $blocktarget
fi
done

Hope it helps...

BenODen · 11-01-2004, 09:48 AM

Personally, I think that script is to much of a heavy hammer. If I understand it correctly, if you fumble your own password once, the Ip
you're logging in from gets blocked.. It needs the other script (wherever it is) to back off a bit, and some counting of numbers of failures
is also in order it seems...

-Ben

dmoorhouse · 11-01-2004, 06:20 PM

I agree. That script looks promising. But counting the number of attempts would be great. I can see my deny chains becomming rather large

thanks for the script though. I'm going to look into it.

Matir · 11-02-2004, 02:16 PM

Quote:

Originally posted by e_larkin
what Im wondering is if there is a way to setup a false file system allow a guest, user, admin, or test login to the system so that when it (the script or person) does login it can be monitored and then traced back to an originating IP?

I would love to start messing with the idiot thats actually doing this.

Look into honeypots. Some of them do exactly this.

dmigh · 11-06-2004, 06:46 AM

LaBrea vs. The Super DMCA in the State of Illinois
http://www.hackbusters.net/whatsnew.html

labrea
http://labrea.sourceforge.net/labrea-info.html

makejail
http://www.floc.net/makejail/

Hamsjael · 11-11-2004, 03:32 AM

It seems to me that these attacks try different usernames depending on what machine the attack is coming from.
I suspect that infected machines attacks with all users from the passwd file, although some user like "test" and "admin" seems constant.

Maybe this is naive, but how about this for a countermeasure:

Every time the sshd deamon get these attempts from illegal users the host should start pinging the address the attacks are coming from. This way a DoS situation will pretty soon affect the infected site, and the admins out there will be forced to take action, and clean up. ;-)

dont no if it would be illegal, and maybe it could be done in a more elegant way. but these attacks are really starting to annoy me.

An ssh server coming on the network will almost immedatly get its logs filled wwith this crap, and it has been goinig on for a LOT longer than the two weeks stated here.

Capt_Caveman · 11-11-2004, 09:57 AM

Actually there are several versions of this malware. The first one used a limited password dictionary while newer versions have a substantially larger one like this example:

http://www.k-otik.com/exploits/08202004.brutessh2.c.php

You can see that the usernames and passwords are hard-coded, including the users test, guest, and admin. It would also be fairly trivial to add more passwords and usernames to the dictionary it's using, which likely accounts for some of the variability. Also note from the code that this is not a worm and doesn't "infect" systems by itself. If you find this on your system, it was likely uploaded manually or by an automated attack script.

Also I would highly recommend against using countermeasures like that against machines attempting these attacks. You're more likely to get into trouble with your ISP than to have an effect on the attacker. If you take preventative measures like disabling root logins, using good passwords, or switching to key-based authentication, you should be secure.

Also note that the post containing the "last two weeks" comment was posted at the beginning of August.

----
Btw, Happy Birthday.

Hamsjael · 11-11-2004, 10:07 AM

It is not difficult to protect a machine against this clumsy attack, but it just annoys me that some lamo wastes my bandwidth and pollutes my logs.

The ping idea would most likely not get anybody into trouble with their isp's as the outgoing ping traffic from the host being attacked would be limited, but the effect at the recieving end would be multiplied by all the host being attacked from it. Ofcourse there should be some kind of time limit on the ping response

thanx

Crashed_Again · 11-12-2004, 05:13 PM

Stupid script kiddies. Its annoying yes, but if you have good passwords their is nothing to worry about. Just don't have a user called test with password password.

This might have been answered but what exactly does this attack do if and when it successfully logs in? Zombie? Trojan?

lord_zoo · 11-14-2004, 10:01 AM

I was wondering if there's a small posibility that the "attacker" could be some kind of honeypot, since I have scanned one of the IP that appears in the logs and get a bunch of services listening on the other side.
This can be a script kiddie with ALL services running on a default instalation, but, who knows.

Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-11-12 23:14 EST
Interesting ports on xxxx.telia.com (x.x.x.x):
(The 3096 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
37/tcp open time
37/udp open time
67/udp open dhcpserver
68/udp open dhcpclient
79/tcp open finger
80/tcp open http
110/tcp open pop3
111/tcp open rpcbind
111/udp open rpcbind
113/tcp open auth
137/udp open netbios-ns
138/udp open netbios-dgm
139/tcp open netbios-ssn
445/tcp open microsoft-ds
512/udp open biff
554/tcp open rtsp
554/udp open rtsp
555/tcp filtered dsf
555/udp open dsf
644/udp open unknown
647/tcp open unknown
656/udp open unknown
659/tcp open unknown
659/udp open unknown
662/udp open unknown
665/tcp open unknown
1080/tcp filtered socks
1755/tcp open wms
1900/udp open UPnP
2049/udp open nfs
3128/tcp filtered squid-http
3306/tcp open mysql
4480/tcp filtered proxy-plus
5902/tcp open vnc-2
6002/tcp open X11:2
6588/tcp filtered analogx
8080/tcp filtered http-proxy
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 20.599 days (since Sat Oct 23 10:20:04 2004)

Nmap run completed -- 1 IP address (1 host up) scanned in 1693.240 seconds

The scan was performed during the probing. I waited to see him again in the logs and scanned the ip.
It's suspicious.

Matir · 11-14-2004, 10:10 AM

Wow, I have *NEVER* seen that many open ports before... very suspicious, if you ask me. Or stupid. One of the two.