i got hacked. what were they up to?

[Sysa]

Do you ssh this box from the internet? I hope there is a good reason to have open ports like that.

The moral of the story really: Strong passwords, hardware firewall, encrypt all network traffic possible.

"... hardware firewall ..." - . I do not think it saves you but you'll not see and control the situation!!

[Veronika]

Bcore,

thanks for bringing up this topic. I´m kind of what you have been until this happened to you: a trusting user and installer, not too much worried about hacking attemps aimed at my system... so thank you again for sharing your story. It makes me think I have to be more careful.

Best

[simulacrum]

You can count me in as a lazy admin with an old version of Awstats (6.2). The cracker was able to load multiple apps, the purpose of which I'm unsure, although one appears to be some kind of IRC bot. The really strange part was my server was fine for the two days since it was compromised. I was SSH'ed in this morning fiddling around as usual for me and I saw the offending process. When I killed it everything went south. Once I booted the LiveCD and looked at the filesystem I found that all the executables in /bin had been overwritten at about the time when I killed that process. It would seem that it was some kind of local root exploit waiting to go off.

I know I'm not the only one who's been rooted because of awstats, but I need to vent. I'm pretty bummed. I'm recompiling now and will soon have a fresh Gentoo install. Ironically, the intrusion happened the day after posting my screenshot in off the wall. I wonder if the script kiddies were looking for vulnerable machines on the Gentoo forums. Beware.

[MrUlterior]

Do you have a .tar of the rootkit or at least the names of the files the intruder uploaded? I'd be very interested having a squiff at that one.

[Giorgio]

me too...
thanks

[Maedhros]

Merged the previous three posts here.

[djdunn]

my openbsd gets beat on, on a daily basis for this kind of stuff. for being an old machine. It shrugs the repeated attacks off fine. I don't worry about it. closing my firewall off completly to incomming ports and packets helps. It's part of the times we live in. It's better to adjust and accept that people will try than to make it so that you don't notice they are there. I reinstall every 6 months to keep OpenBSD up to date. So log files arent a big problem. I'd rather them know that im here and they cant mess with me than to be invisible.

[simulacrum]

The intruder grabbed vulturu.tar.gz and upacked an application called "raven" There were several other applications downloaded but I didn't bother saving them. I guess in retrospect that might have been the way to go. I'd be curious if anyone here was familiar with this vulturu/raven application.

[killfire]

Don't know about anyone else, but I do think that if you get hammered enough on these tries, it can crash your box, or at least drop it offline. I've had my server up for 120 days, no problem. This started, and my box crashes almost every 5 days until I changed ports. And no, there aren't any strange directories or users, and netstat shows only my local IPs causing traffic.

http://home.insightbb.com/~arcruea/attempts.log << Lots of attempts on my IP from 5 log files.

I must say, though, that this is REALLY pissing me off. I've emailed countless abuse@ISP addresses now, and finally gave up. I should write a script, though, that does it for me.

And I looked at one of the address in that attempt log in a web browser. . .it's an HTTP debian server with default install.

my suggestion is get another box, as powerful as possible, and install openbsd on it, then set it up as a firewall....


if you can just drop all connections on port 22 except the ones you want (white list it kind of)

or if not, just shut down port 22 for a certain ip after 2 or 3 attempts.... that way, your firewall takes a beating, but who cares, openbsd is like a rock... and your actual computer is free of all but a few connections...

killfire

[killfire]

Well I did read all 10 pages before posting so I've seen this mentioned before but this machine is my desktop and an http/ftp server so I don't want to trade off too much usability just for some security. So I was hoping I could figure out a way to sort of halt these hacking attempts without limiting everything else.

if you dont even need ssh, then its simple:

get a dedicated firewall (openbsd is best, but most things will do), a cheap old box will do

and deny everything except port 80 and port 21... (my memories terrible, 21 is ftp right?)

otherwise look into dynamically updating pf's rukes, with something like snortsam...

killfire

[rex123]

I've just seen this excellent site: http://www.ranum.com/security/computer_ ... -firewall/

[mekong]

One question: Is there a worm active on sshd port? I've got logins attemps a few hunderds time daily from dozen IP's. Are these all hacked linuxboxes?

[Pacolov]

Mar 23 15:11:50 [sshd] Did not receive identification string from 217.74.167.142
Mar 23 15:18:38 [sshd] Illegal user test from 217.74.167.142
Mar 23 15:18:38 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:18:38 [sshd] Failed password for illegal user test from 217.74.167.142
port 60696 ssh2
Mar 23 15:18:41 [sshd] User guest not allowed because shell /dev/null is not exe
cutable
Mar 23 15:18:41 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:18:41 [sshd] Failed password for illegal user guest from 217.74.167.14
2 port 60810 ssh2
Mar 23 15:18:45 [sshd] Illegal user admin from 217.74.167.142
Mar 23 15:18:45 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:18:45 [sshd] Failed password for illegal user admin from 217.74.167.14
2 port 60896 ssh2
Mar 23 15:18:48 [sshd] Illegal user admin from 217.74.167.142
Mar 23 15:18:48 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:18:48 [sshd] Failed password for illegal user admin from 217.74.167.14
2 port 60989 ssh2
Mar 23 15:18:51 [sshd] Illegal user user from 217.74.167.142
Mar 23 15:18:52 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:18:52 [sshd] Failed password for illegal user user from 217.74.167.142
port 32852 ssh2
Mar 23 15:18:55 [sshd] Failed password for root from 217.74.167.142 port 32946 s
sh2
Mar 23 15:18:58 [sshd] Failed password for root from 217.74.167.142 port 33031 s
sh2
Mar 23 15:19:02 [sshd] Failed password for root from 217.74.167.142 port 33119 s
sh2
Mar 23 15:19:05 [sshd] Illegal user test from 217.74.167.142
Mar 23 15:19:05 [sshd] error: Could not get shadow information for NOUSER
Mar 23 15:19:05 [sshd] Failed password for illegal user test from 217.74.167.142
port 33213 ssh2

Damn, I didn't even notice that stuff like this is going on at my server. luckily i keep it up to date and have secure logins only and use ssl where i can.

another spot: these fu**** steal bandwidth :o(

[sam22]

Following is a sample from my log.
This freak is trying with serveral login names. First common male, then female then colors black, red,...
Fortunately none of the times he got access.


Mar 24 22:10:41 vlinsrv sshd[10528]: Illegal user jordan from 82.149.224.51
Mar 24 22:10:41 vlinsrv sshd(pam_unix)[10528]: check pass; user unknown
Mar 24 22:10:41 vlinsrv sshd(pam_unix)[10528]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=ftp1.hg-computer.de
Mar 24 22:10:43 vlinsrv sshd[10528]: Failed password for illegal user jordan from 82.149.224.51 port 59084 ssh2
Mar 24 22:10:44 vlinsrv sshd[10530]: Illegal user michael from 82.149.224.51
Mar 24 22:10:45 vlinsrv sshd(pam_unix)[10530]: check pass; user unknown
Mar 24 22:10:45 vlinsrv sshd(pam_unix)[10530]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=ftp1.hg-computer.de
Mar 24 22:10:47 vlinsrv sshd[10530]: Failed password for illegal user michael from 82.149.224.51 port 59230 ssh2
Mar 24 22:10:48 vlinsrv sshd[10532]: Illegal user nicole from 82.149.224.51
Mar 24 22:10:49 vlinsrv sshd(pam_unix)[10532]: check pass; user unknown
Mar 24 22:10:49 vlinsrv sshd(pam_unix)[10532]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=ftp1.hg-computer.de
Mar 24 22:10:51 vlinsrv sshd[10532]: Failed password for illegal user nicole from 82.149.224.51 port 59371 ssh2
Mar 24 22:10:52 vlinsrv sshd[10534]: Illegal user daniel from 82.149.224.51
Mar 24 22:10:57 vlinsrv sshd(pam_unix)[10534]: check pass; user unknown
Mar 24 22:10:57 vlinsrv sshd(pam_unix)[10534]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=ftp1.hg-computer.de
Mar 24 22:11:00 vlinsrv sshd[10534]: Failed password for illegal user daniel from 82.149.224.51 port 59513 ssh2

[59729]

ssh displays the ip or the domain from the person trying to login right?

Code: Select all

## drop all from xxx
iptables -A INPUT --source xxx.xxx.xxx.xxx -j DROP
### drop all from xxx on dport 22
#iptables -A INPUT --source xxx.xxx.xxx.xxx --dport 22 -j DROP

[moocha]

The intruder grabbed vulturu.tar.gz and upacked an application called "raven" There were several other applications downloaded but I didn't bother saving them. I guess in retrospect that might have been the way to go. I'd be curious if anyone here was familiar with this vulturu/raven application.

Bit of trivia: In Romanian, "vultur" means "eagle". Sounds like a nickname / handle for the creator of the corresponding rootkit. Not surprising, too - Romania does seem to exhibit an unusually high density of script kiddies per square kilometer.

[Mythos]

sorry but ... why use 22 port ? change port ...

Block as default your iptables and only allow what you want ...

install hardened-dev-sources with gprsec and pAX plus selinux, then your system is close to openbsd and heaven secure i guess.


something like this ...

Code: Select all

#Accept NEW,ESTABLISHED,RELATED
ACCEPTNER='-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT'
ACCEPTER='-m state --state ESTABLISHED,RELATED -j ACCEPT'
ACCEPTN='-m state --state NEW -j ACCEPT'
AC='-m state --state NEW,ESTABLISHED,RELATED' 

# Only chosen port's will be accept.
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -P FORWARD DROP 

$IPTABLES -A INPUT -p tcp $ACCEPTER
$IPTABLES -A INPUT -p tcp -s $EXTIP -d $locaIP --dport 1022 $ACCEPTN #SSHD 

#Block all
$IPTABLES -A INPUT -p tcp -j DROP 

i have this in my sshd_config

Code: Select all

#/etc/ssh/sshd_config
Port 1022
Protocol 2
AllowUsers dune
LoginGraceTime 1m
PermitRootLogin no
StrictModes yes
MaxAuthTries 2
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM yes
Subsystem       sftp    /usr/lib/misc/sftp-server

[alxcm]

Hey all...

Do you think a firewall is really necessary? I run a DMZ'd server with the following nmap -sS reply:

Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-03-28 12:22 EST
Interesting ports on xxx (x.x.x.x):
(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
80/tcp open http
111/tcp open rpcbind
631/tcp open ipp
1024/tcp open kdm
1025/tcp open NFS-or-IIS
2049/tcp open nfs
3632/tcp open distccd
8080/tcp open http-proxy

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

I get people bouncing off of ssh all the time but my passwords are very secure...nobody has yet logged in, as far as I can tell from the logs. I know distcc might not be the best idea, but I'll probably set up iptables for that. Anyway, any insecurities you can see right off the bat?

[moocha]

Anyway, any insecurities you can see right off the bat?

There's a difference between "insecure" and "exploitable". Assuming you're running the latest packages, there are no known exploitable vulnerabilities there. But there are two basic vulnerabilities:

• It's possible to launch denial of service attacks against the services running on open ports, even if access control prevents unauthorized users using your services (for example, flooding the HTTP proxy with requests)
• Nobody can guarantee the non-existence of any exploitable vulnerabilities on those services. Historically, for example, the portmapper (port 111) has been an entry portal for a lot of nasty things (anyone remember rpcstatd? ).

[Mythos]

Anyway, any insecurities you can see right off the bat?

There's a difference between "insecure" and "exploitable". Assuming you're running the latest packages, there are no known exploitable vulnerabilities there. But there are two basic vulnerabilities:

• It's possible to launch denial of service attacks against the services running on open ports, even if access control prevents unauthorized users using your services (for example, flooding the HTTP proxy with requests)
• Nobody can guarantee the non-existence of any exploitable vulnerabilities on those services. Historically, for example, the portmapper (port 111) has been an entry portal for a lot of nasty things (anyone remember rpcstatd? ).

I think that hardened-dev-sources, have an option that prevent's that http request attack ...

Code: Select all

[*] Deter exploit bruteforcing 

 CONFIG_GRKERNSEC_BRUTE:                                                 │
  │                                                                         │
  │ If you say Y here, attempts to bruteforce exploits against forking      │
  │ daemons such as apache or sshd will be deterred.  When a child of a     │
  │ forking daemon is killed by PaX or crashes due to an illegal            │
  │ instruction, the parent process will be delayed 30 seconds upon every   │
  │ subsequent fork until the administrator is able to assess the           │
  │ situation and restart the daemon.  It is recommended that you also      │
  │ enable signal logging in the auditing section so that logs are          │
  │ generated when a process performs an illegal instruction.               │
  │                                                                         │
  │ Symbol: GRKERNSEC_BRUTE [=y]                                            │
  │ Prompt: Deter exploit bruteforcing                                      │
  │   Defined at grsecurity/Kconfig:248                                     │
  │   Depends on: GRKERNSEC                                                 │
  │   Location:     

[moocha]

No, Mythos, that's a completely different thing. CONFIG_GRKERNSEC_BRUTE does not protect you against a large number of requests, it just prevents forkbombing as a side effect of a large number of request, should those requests cause the daemon to die. Even then you're still potentially vulnerable to resource starvation attacks.

[Mythos]

well there are no perfect system ... the best solution is patching, updating and choose carefully what services users and port's are needed...

[moocha]

well there are no perfect system ... the best solution is patching, updating and choose carefully what services users and port's are needed...

That's very good advice. In order to have a stable and secure system, less is always more .

[someguy]

indeed

[Legoguy]

Beware. The list of names they try is getting longer:

http://turbogfx.homelinux.org/sshattempts.txt

That was logged on the 25th, 6 days ago. 587 attempts within 10 minutes. Of course none of them were harmful (none of them existed) but I'd imagine the list is getting longer as the thing breaks into more boxes.

Starting from October 29th 2004, there have been 4166 attempts on my machine... none of them doing anything. You only really need to worry if you have a user/pass the same, although I can't confirm that, but it seems to be the case.

To find all of the relevant items in your log:

Code: Select all

grep "sshd\[[0-9]\+\]: \(Invalid\|User\|reverse\)" /var/log/messages

Add a " | wc -l " on it to see the number of attempts.