Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fishing for Hackers: Analysis of a Linux Server Attack

draios.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#31

Post by peterwwillis »

degio wrote: post #29
DodgyEggplant wrote: post #27

Great article, thanks. Does sysdig ready for production servers? tested so it does not introduce new issues?

I'm one of of the sysdig creators. Sysdig is a pretty young project (we released it around a month ago), so I can't promise it will be flawless in a production environment. However, we've had many installations under several different environments, and during the month after the release we had extremely few crash reports, which we've worked to fix right away.

By 'crash reports' do you mean the kernel/host?

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#32

Post by degio »

peterwwillis wrote: post #31
degio wrote: post #29

Earlier quoted context omitted.

I'm one of of the sysdig creators. Sysdig is a pretty young project (we released it around a month ago), so I can't promise it will be flawless in a production environment. However, we've had many installations under several different environments, and during the month after the release we had extremely few crash reports, which we've worked to fix right away.

By 'crash reports' do you mean the kernel/host?

I mean overall, so that includes kernel crashes.

Kernelwise, the main thing to report is a couple of crashes on non-mainline kernels like openVZ.

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#33

Post by wazoox »

fragmede wrote: post #8

So a DO/Rackspace/AWS VPS with a guessable root password can expect to be cracked in ~4 hours? That's terrible! AFAIK, AWS defaults to ssh-key logins with password logins disabled. Can someone comment about Rackspace/DO?

This is not limited to AWS/rackspace... Here's from my home PC:

$ uptime

  22:09:07 up 30 days, 12:19,  2 users,  load average: 0,17, 0,09, 0,07
$ sudo fail2ban-client status ssh-iptables

Password:

Status for the jail: ssh-iptables

  |- filter
  |  |- File list:	/var/log/messages 
  |  |- Currently failed:	1
  |  `- Total failed:	1757
  `- action
     |- Currently banned:	0
     |  `- IP list:	
     `- Total banned:	242
1757 attempts from 242 IP address in the past 30 days...

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#34

Post by revelation »

gighi wrote: post #14
jwcrux wrote: post #12

OP may also benefit from the use of an SSH honeypot. I use kippo ( https://code.google.com/p/kippo/ ) with great success. It tracks all commands run, as well as keeps copies of all downloaded files. In addition, it limits available commands to a certain predefined subset, allowing the host to prevent damage caused (e.g. a DoS attack in this case) by the system being compromised.

That's an interesting project. Would it have recorded also statistics like the connection activity? Seeing all the UDP traffic, and being able to trace its origin to the "@udp1 39.115.244.150 800 300" command, received not via shell but via a TCP connection, was pretty cool.

The original article is a bit unclear on this, but the command was not directly received from a TCP connection initiated by the botnet owner.

Rather, his server connected to some IRC server and joined a channel with all his other bot friends. The owner then sent the command to the IRC channel, and it is then broadcasted to all bots by whatever IRC server he is using.

(This is why lots of IaaS providers will forbid you from hosting an IRC server, and sometimes block all IRC traffic (by port anyway) on their networks)

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#38

Post by espringe »

jwcrux wrote: post #12

OP may also benefit from the use of an SSH honeypot. I use kippo ( https://code.google.com/p/kippo/ ) with great success. It tracks all commands run, as well as keeps copies of all downloaded files. In addition, it limits available commands to a certain predefined subset, allowing the host to prevent damage caused (e.g. a DoS attack in this case) by the system being compromised.

Another useful honeypot approach is Bitcoin Vigil, which will let you know if (bitcoin-stealing) malware has already made it onto the machine

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#40

Post by euske »

I had a similar experience as the OP years ago. Luckily, the attacker forgot to erase a bash history so I could recover almost all the command lines. It seems that most of these operations were pretty standardized; they first downloaded a bunch of exploits from another cracked site, then in my case they tried to run a local exploit to gain a hole in kernel (it was a Linux 2.4 box whose privilege escalation bug was fixed just weeks ago). I had a patch applied to the kernel so it didn't succeed. Then they started an IRC bot as a disguised name (like /usr/X11/X or something) and left. I felt embarrassed but in hindsight it was a pretty good lesson.
Post reply on HN