Server got hacked.. interesting security opportunity - Overclock.net

Forum Jump: 
Reply
 
Thread Tools
post #1 of 14 Old 03-20-2012, 02:13 PM - Thread Starter
 
Sarec's Avatar
 
Join Date: Aug 2008
Location: CA
Posts: 732
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 38
I have a server that myself and a friend run that is using Debian Squeeze. We have a running RT, sql, and ftp environment. I noticed some errors in some basic commands such as pstree and ls.

The scope of this post is not to ask how to clean it up. Not yet anyways, I turned off the server and do not have physical access to it at the moment. What I want is to be pointed in the right directions on how to secure a server in linux. From the easy configurations to the nitty gritty. How do major suppliers protect their machines? Is it all in proprietary scripts?

Thoughts please. I am new to security but I am perfectly willing, and already am, doing research and would love any help I could get.

Quote:
The problem is, like so many other things, people want instant gratification. They want the reward without the work, the cool of the Coke without the sweat that makes them hot in the first place... -iceblade^
Sarec is offline  
Sponsored Links
Advertisement
 
post #2 of 14 Old 03-20-2012, 03:31 PM
Kamehameha!!!
 
Plan9's Avatar
 
Join Date: Nov 2011
Location: Planet Vegeta
Posts: 8,038
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 574
A quick breakdown:
  • Disable FTP and use SFTP (I wrote a guide to do that on here somewhere)
  • Following on from the above, disable all other clear text log ins. eg SSH instead of telnet (which you're unlikely to have running anyway), SSL HTTP authentication (use self signed certs if you have to). SSH tunnel any remaining traffic that cannot be encrypted.
  • Install fail2ban to block attempted brute force attacks
  • tune iptables (plenty of guides to do that online - but be very careful as it's an easy way to brick your box)
  • make sure all your TCP sockets listen on localhost unless you specifically want outside connections to that daemons (this is less of an issue if you have iptables set securely - but it's good practice anyway)
  • install some kind of reporting. whether that's just fail2ban or if you install supplementary tools - it's entirely up to you. You need to know what's happening to your box when you get abnormal traffic and you're away from it. Just make sure that those reports are e-mailed and make sure that if you need to install postfix (or any other form of mail relay) to do so, that it only listens on localhost.
  • sandbox users. SFTP accounts should be chrooted. root shouldn't have SSH access. Daemons shouldn't run as root. etc

stumped, Sarec, Multiverse and 4 others like this.
Plan9 is offline  
post #3 of 14 Old 03-20-2012, 03:40 PM
WaterCooler
 
Join Date: Jul 2010
Location: Oz & US
Posts: 1,206
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 132
Plan9 offers great advice.
It is a lot of reading (but well worth it) to have a look at this. It will give you info on chrooting for sftp so that the user can only see there home directory.
Sarec likes this.
mdatmo is offline  
Sponsored Links
Advertisement
 
post #4 of 14 Old 03-20-2012, 03:50 PM
Kamehameha!!!
 
Plan9's Avatar
 
Join Date: Nov 2011
Location: Planet Vegeta
Posts: 8,038
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 574
Another tip i swear by i trying to hack your own server. Imagine you've locked yourself out of your house and you need to break in to get your keys - then apply the same logic to your server. You'd be amazed the number of potential loopholes you might find when you really set your mind to it smile.gif


Also, I should have added to the earlier list:
* non-guessable usernames is as important as non-guessable passwords.
* use SSH keys instead of passwords. I recommend this because while it does offer a security benefit, it isn't strictly necessary if you follow all the other steps as attackers shouldn't get the opportunity to brute force attack your server. However SSH keys are a lot more convenient as well. So for that reason alone, they're definitely worth setting up.
Multiverse, _GTech and Shrak like this.
Plan9 is offline  
post #5 of 14 Old 03-20-2012, 04:24 PM - Thread Starter
 
Sarec's Avatar
 
Join Date: Aug 2008
Location: CA
Posts: 732
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 38
When you stated, "make sure all your TCP sockets listen on localhost unless you specifically want outside connections to that daemons (this is less of an issue if you have iptables set securely - but it's good practice anyway)". I thought TCP listened in on all ports anyways. Do you mean binding my default TCP activity to 127.0.0.1 and then only having specific applications able to use eth0 via their own binds?

If so, how do I bind all TCP to 127.0.0.1.

Quote:
The problem is, like so many other things, people want instant gratification. They want the reward without the work, the cool of the Coke without the sweat that makes them hot in the first place... -iceblade^
Sarec is offline  
post #6 of 14 Old 03-20-2012, 04:25 PM
Gone From OCN
 
Shrak's Avatar
 
Join Date: Dec 2011
Location: Nixers / Reddit
Posts: 10,322
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 605
Might as well add a couple reps to Plan9.
Shrak is offline  
post #7 of 14 Old 03-20-2012, 04:48 PM
Kamehameha!!!
 
Plan9's Avatar
 
Join Date: Nov 2011
Location: Planet Vegeta
Posts: 8,038
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 574
Quote:
Originally Posted by Sarec View Post

When you stated, "make sure all your TCP sockets listen on localhost unless you specifically want outside connections to that daemons (this is less of an issue if you have iptables set securely - but it's good practice anyway)". I thought TCP listened in on all ports anyways. Do you mean binding my default TCP activity to 127.0.0.1 and then only having specific applications able to use eth0 via their own binds?
If so, how do I bind all TCP to 127.0.0.1.

The binded NIC is a different matter as that should be controlled transparently to your daemon. I'm not sure how Debian does this, but in SLES there's a whole bunch of mappings in /etc/sysconfig/network. I'd assume Debian would be the same as they're both Linux Standard Base, but I'm just guessing here.

What I mean about the listener is really nothing more than choosing which IP your daemons listen on. If your box isn't sat behind a firewall and all your daemons listen on 0.0.0.0 (which is often the default), then that means that every daemon can be connected to externally - even for local services. Now if you're running a basic mail relay (such as postfix) to send security emails to yourself every x days, you only want that mail relay to be accessible locally otherwise all sorts of disreputable folk could potentially abuse your SMTP server and send spam from it (granted you can lock SMTP down, but let's assume for a second that you haven't). So what you do is set postfix (your SMTP server) to listen on localhost (127.0.0.1) - this means that even if you don't have a firewall enabled, your mail relay is only accessible from connections originating from your actual box (ie your security e-mails) and will ignore any other connection request.

There are still ways around this as TCP/IP packets can easily be re-written to spoof another IP address. But the chances of someone doing that are pretty much nil compared with the chance of an opportunist port scanning your box and noticing all sorts of fun daemons are running.

Actually, while I'm on the subject of port scanning, you can configure iptables to adaptively block suspected port scans - which was one of the iptable tweaks I had in mind when I wrote my bullet point list earlier. However I'm far from an expert on iptables (I just follow blogs about that myself). So I'm afraid I couldn't give you any configuration instructions on that specifically smile.gif
Quote:
Originally Posted by Shrak View Post

Might as well add a couple reps to Plan9.

Thanks mate smile.gif
_GTech likes this.
Plan9 is offline  
post #8 of 14 Old 03-20-2012, 07:24 PM
Tweaker
 
enorbet2's Avatar
 
Join Date: Jan 2008
Location: Virginia
Posts: 3,309
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 392
Send a message via AIM to enorbet2 Send a message via Skype™ to enorbet2
Greetz
Plan9's advice is right by the numbers solid (but what should we expect from a guy with a name so cool it could only be cooler if Seinfeld hadn't done an episode featuring it) biggrin.gif If you'd like some tools and reference material to help you follow a path that can get you up to that speed I dug up a few that helped me and one I still use to this day.

Reference and Software
- http://www.wireshark.org/ This is considerably expanded since back in the day when I learned from it but the basics are still there and they still allow downloads of Source.


Reference - I'm including http://www.tripwire.com/ even though they've gotten huge and commercial as there is still a lot of reference by and about them and their goods all over the webz


Testing Software
- Back in the day the Nessus Suite was a Hacker's Best Friend (well, maybe second to Internet Explorer and Outlook Express wink.gif ) and it just began with huge longboats full of Vikings and went on from there. Kidding aside, it was extremely useful for attacking a network with terrific configurability and delivering a very thorough report on the results. They, too, have gotten big but they have not forgotten their roots. I recommend you consider the free registration and get the free version of the suite for starters so you can see the effect of what you do and learn from experience. It's found at TENABLE

You have some work ahead of you but many find it extremely interesting and even fun.
Sarec likes this.

Compone Accomoda Supera
enorbet2 is offline  
post #9 of 14 Old 03-21-2012, 03:21 AM - Thread Starter
 
Sarec's Avatar
 
Join Date: Aug 2008
Location: CA
Posts: 732
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 38
My goal is to learn from this experience, clean it up, button it down and open it back up to the world and see if my measures hold true. I look forward to a possible battle.

Thanks for the help and direction.

Quote:
The problem is, like so many other things, people want instant gratification. They want the reward without the work, the cool of the Coke without the sweat that makes them hot in the first place... -iceblade^
Sarec is offline  
post #10 of 14 Old 03-25-2012, 06:17 PM
Linux Lobbyist
 
Join Date: Aug 2008
Location: Canada
Posts: 159
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 4
Send a message via MSN to TrueTroop Send a message via Skype™ to TrueTroop
I have 3 different linux servers and all I do:

1) Use fail2ban (simple to install prevents 99.99% of bruteforce attacks)

2) Use none default ports (*VERY IMPORTANT*)

3) Bind access to services only you use to a specific IP

To be honest, the port thing alone will keep you safe the overwhelming majority of the time as people aren't going to spend the time trying to figuire out what random port you set the service to broadcast to, they'll just move on to the next guy who uses the default port....

613websites.com ● Canadian Web Design and Hosting
TrueTroop is offline  
Reply

Quick Reply

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off