Results 1 to 31 of 31

Thread: Server Hacked

  1. #1
    Join Date
    Oct 2005
    Location
    Minneapolis, MN
    Posts
    149

    Server Hacked

    Hi,

    I recently got the HostGator's basic server. I have 2 phpbb forums running on it. Not much else. Had trouble with WHM and cPanel this morning. Told by tech support that the server got hacked and needed a rebuild.

    How could something like this happen? Does it happen often? What should I do to prevent something like this from happening? I am switching to theplanet with their firewall option. Hopefully this will keep my server safer.
    Kick Ass SEO - Minnesota Search Engine Optimization Service

  2. #2
    Join Date
    Nov 2002
    Location
    WebHostingTalk
    Posts
    8,878
    * Moved to Technical and Security Issues....

    Sirius
    I support the Human Rights Campaign!
    Moving to the Tampa, Florida area? Check out life in the suburbs in Trinity, Florida.

  3. #3
    Join Date
    Apr 2006
    Location
    Jacksonville, FL
    Posts
    498
    Did you have anything security-wise running, or was it just a fresh-out-the-box server?

  4. #4
    Join Date
    Oct 2005
    Location
    Minneapolis, MN
    Posts
    149
    I have no idea. What kinds of security-wise measures should I have. HostGator just gave me the sever and I thought they would take care of the security things.

    I am switching to theplanet.com and got their firewall. Would that be good for preventing hacking?
    Kick Ass SEO - Minnesota Search Engine Optimization Service

  5. #5
    Were the Phpbb forums up to date? I remember reading somewhere that ther were secuirty exploits for the forum. If someone used them, they could compromise a whole server....

  6. #6
    You need to hire a server management company ASAP.
    Eleven2 Web Hosting - World-Wide Hosting, Done Right!

  7. #7
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    i would bet you didnt have a updated kernel.

    A firewall is not going to stop hacks.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  8. #8
    Join Date
    May 2002
    Location
    Kingston, Ontario
    Posts
    1,573
    Since you ordered the server with hostgator - did you ever ask them to perform a security audit at any point? A hardware firewall won't do anything in terms of making your server safe. It's like putting a dead bolt on your front door when you leave the side window open because this is a software based attack - eg hole in phpBB - you need mod_security and other things going to help.
    Upload Guardian 2 - Malicious Upload Scanner - Windows and Linux!
    Instantly scan uploaded files
    Get notified when released

  9. #9
    Most dedicated hosts (e.g. Rackspace) don't just log onto your server to routinely check it. They are alerted by something, whether it be a phishing scam or downtime, that causes them to log onto the affected server to disable the offending scripts/applications.

    You definitely got hacked somehow. Here are a list of possible ways:
    1. Allowing root logins
    2. phpBB not up to date (the nature of that open-source application is that it requires an update every few weeks)
    3. Outdated kernel
    4. Applications running that are unnecessary
    5. Unnecessary open ports
    6. SSH allowed on port 22 (move it to another port)
    7. Please don't tell me you have telnet or finger enabled.

    Those are the only few I can think of on the top of my head. A firewall itself does not do you much good. As a server administrator and maintainer, you need to be on top of everything on an almost daily basis.

    Truthfully, this is not HostGator's fault. You are ultimately responsible. The same thing is likely to occur on theplanet.com when you move there. In HostGator's defense (and let me add that I have no relationship whatsoever with them nor do I really know them that well), they did nothing wrong.

    You should NEVER expect to just be handed a server and that you can turn your back on it. Install security scripts, get email notifications when stuff seems to go wrong, and you'll have a better handle of things.

  10. #10
    Join Date
    May 2001
    Location
    Colorado, USA
    Posts
    812
    Check out Rack911.com. They offer some great server setup and server security packages. I used their services several times and they are excellent to work with and the prices are moderate and fair.

    Christoph
    Web Hosting Resource Kit - Web Hosting Reviews & Hosting Tutorials

  11. #11
    Join Date
    Apr 2006
    Location
    Jacksonville, FL
    Posts
    498
    If you never did anything to the server, then it was most likly out of date, which caused the hacking. HostGator isn't going to secure your server for you, unless it was managed.

  12. #12
    Join Date
    Oct 2005
    Location
    Minneapolis, MN
    Posts
    149
    Hi guys,

    Thanks for all the responses! I ordered the HostGator server about 2 weeks ago. Didn't do anything with it. My phpBB forum is up to date. The web site and the forum are running fine even the server got hacked. The things that got messed up are WHM and cPanel.

    I never checked the telnet or finger. How do I disable them? Are they enabled by default? I am totally new to dedicated server hosting.
    Kick Ass SEO - Minnesota Search Engine Optimization Service

  13. #13
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    Told by tech support that the server got hacked and needed a rebuild.
    First things first, NEVER accept what "tech support" tells you at face value. Countless times I've been told by some flunky at "tech support" that a server's hacked and needs a reformat, and proven them wrong, every time.

    I am switching to theplanet.com and got their firewall. Would that be good for preventing hacking?
    If you don't know what you're doing, have an admin look at the server on a recurring basis. One time security doesn't cut it, ESPECIALLY if you're running something as vulnerable as phpbb. I would suggest looking into phpbb alternatives which are more secure (SMF is one that comes to mind right away).

    Moving to another DC doesn't guarantee anything is "hackproof". The only thing the DC is responsible for is the network and the server (if it's not co-located). You essentially just went from hostgator (a somewhat cheap provider) to TP (a somewhat not-so-cheap provider) when that wasn't necessary here.

    You definitely got hacked somehow. Here are a list of possible ways:
    Amazing, you can TELL the user got hacked? Yeah, ok, right. This is about as good as a "support tech" saying "You've been hacked", not even looking into the server. This is what 90% of them do:

    Customer opens ticket
    Customer says "My website was hacked"
    Tech says "Get a reload"
    Customer says "Sure"
    Company makes $30-$100 just for an OS reload.

    9/10 times, you don't need a reload. Of course, the "tech" is going to want you to get one, because company makes more money that way, etc.

    1. Allowing root logins
    2. phpBB not up to date (the nature of that open-source application is that it requires an update every few weeks)
    3. Outdated kernel
    4. Applications running that are unnecessary
    5. Unnecessary open ports
    6. SSH allowed on port 22 (move it to another port)
    7. Please don't tell me you have telnet or finger enabled.
    4/7 of that (over half) is not even going to lead you to security issues. Nothing is wrong with 1,4,5 or 6. Nothing at all. In fact, as a linux "newbie", you're only asking for more problems when you take action on those.

    i would bet you didnt have a updated kernel.
    Or an updated PHPBB setup. Either way, something was (most likely) out of date.

    It's not possible to tell what happened, when, since the server has been replaced. Unfortunately, this is bound to happen again, unless you keep your eye on the logs and look at what's going on. If you don't understand that, then, hey, that's what professionals are for
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details

  14. #14
    Join Date
    Oct 2005
    Location
    Minneapolis, MN
    Posts
    149
    Forgot to ask: does modsecurity help prevent hacking?

    How do you disable root logins? If it is disabled, how do I log in?

    Are there any online guides that would help me tighten the security through WHM or cPanel? I am not that familiar with Linux.
    Kick Ass SEO - Minnesota Search Engine Optimization Service

  15. #15
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,290
    Forgot to ask: does modsecurity help prevent hacking?
    Only if you have a good ruleset and know what you are doing.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  16. #16
    Join Date
    Mar 2003
    Location
    California
    Posts
    141
    With phpBB mod_security with some good rules is a must. But you should get a server management company to take a look and see how the server was compromised, see if they can clean it and harden it and maintain it for you. If you are not familiar with server security you should hire someone to do it for you, that is key. Think of it like paying insurance.
    Ripple Web
    RippleWeb.com
    Dedicated Servers - Private Cloud Services - Colocation

  17. #17
    Join Date
    Nov 2003
    Location
    Florence, KY
    Posts
    604
    Check out dynamicnet.com they are really good. You can't just get a server and expect the datacenter to do anything. As said before the server is yours so you are responsible to securing it. By default servers are usually not hardened.

    PM me if you would like my contact there at dynamicnet. A side note, they're cheap but they're good. It's a trade off.. You won't get both cheap and good.

    Justin

  18. #18
    Join Date
    Sep 2000
    Location
    Alberta, Canada
    Posts
    3,109
    gobeyond, you have not provided enough information for anyone to give a decent answer.

    The situation you were in required someone to login to your Server and see, exactly what the problem was. Perhaps HG Tech Support "did" login, you don't mention if they did nor if you asked how the Tech knew your Server was hacked. With a few simple commands, someone who knows what they are doing can determine if a Server has been 'rooted' (taken over by someone else) or, if it's something else.

    Moving to another DC will not solve your problem. Hardening a Server takes about 2 - 3 hrs. "after" the DC has set it up and turned it over to you. Unless specifically asked, a DC will not install the necessary Server-wide security that any Server should have.

    Act now before it's too late. Get someone to secure your Server before you end up where you were before.
    PotentProducts.com - for all your Hosting needs
    Helping people Host, Create and Maintain their Web Site
    ServerAdmin Services also available

  19. #19
    Join Date
    Nov 2003
    Location
    Auckland, New Zealand
    Posts
    584
    @linux-tech :
    What the poster Tamar posted was a quick list of things that can make it more difficult to compromise the server if actioned on. If not, they can be possible ways to breach a server. And quite often one of those things will be a contributing factor. Some honest and good possible information was posted by the user, and in your enthusism to post something, you were attacking valid points, the poster and arguing against things that were never in the post.

    Your took the comment "You definitely got hacked somehow." as meaning that he had determined the server was hacked as though it was something he diagnosed. Then you proceeded to mock the user for this. You do realise that this was " Your server was hacked" - re-stating the facts as stated by HostGator staff and the thread starter himself. That fact that you yourself do not question - only if the server reformat was necessary. So why attack the user for stating what is agreed upon?

    Someone hacked into the server. He didn't say root was compromised without examining the machine. Had that happened, perhaps your little comments would have had been more excusable.

    Exploit recovery is always possible without a format - but most of the time it's not really a good choice without significant resources. It's never 100% guranteed. There is atleast three levels of hack attack for forums. One is SQL injection. The other is managing to upload files into the account and doing account compromise. The other is a derivative root level compromise. There is more granular types of attacks in the middle as well.

    As for the argument that reformats are sometimes done to generate revenue - this is not entirely untrue. I'm sure some companies do that simply to avoid having to examine the server and determining the causes by more technical staff than to handle it at a lower level and cust costs. But note : HostGator does not charge anything for formats. They do fully managed servers, so they would be doing the restore of the data free. The poster was quite clear that moving to another DC won't really help.

    4/7 of that (over half) is not even going to lead you to security issues. Nothing is wrong with 1,4,5 or 6. Nothing at all. In fact, as a linux "newbie", you're only asking for more problems when you take action on those
    Security is about prevention and proactive updates in this industry. Your statements fly in the face of that. That comment made by you bear no sign that you are actually aware of why those items were mentioned as " possible " methods that the thread starter could have been compromised. One of the way to reduce exposure is to reduce the possible attack surface.

    You said #4 - Applications running that are unnecessary - is not a problem. In which planet is it a good idea for example to leave running FTP on a server which never gets used. FTPs do and have exploits and could easily get a server rooted. Same goes for MANY other software that are run on many servers. If someone isn't updating their site software regularly, then chances are that they aren't doing the same for their server softwares - even then the exploits and bugs are found routinely.

    The root login thing is also very important. Disctionary attacks are quite regular on the net. I've yet to find a server that never got a few in a week atleast if it's connected to the net directly. The ammount of people that use their birthdays, names as root passwords is shocking. That is why direct root logins are mentioned as a possible method of compromise. Having to wheel before doing this mean two seperate accounts have to be breached.

    The points about open ports have merits too.
    Last edited by ImZan; 09-08-2006 at 05:38 AM.
    BLUETRIDENT.NET - Reliable Shared, Reseller and Dedicated Hosting Solutions Provider
    Managed Hosting with Personal Service
    Highspeed Content Servers, Lighttpd, Ruby on Rails, Cluster Servers & Rich Web Application Hosting

  20. #20
    Thank you ImZan for your defense. I guess linux-tech didn't read that I said "possible" ways, not definite ways. Any of those I listed *can contribute* to the server being compromised, but I cannot say for sure WHAT the backdoor was.

    By the way, I'm a she, not a he.

  21. #21
    Join Date
    Oct 2005
    Location
    Minneapolis, MN
    Posts
    149
    Thanks again guys for your help! I am not sure exactly what happened to my server at Host Gator. The first tech support guy told me yesterday morning that the server was hacked through ssh. He didn't provide any details and I didn't know what to ask. Never did the ssh myself.

    Yesterday, the server was up and down from late afternoon through the evening. One of the phpbb forum got its database corrupted. This morning, the server was down again. Another tech support guy said that their datacenter informed them the primary hard drive was failing and needed a replacement. I don't know who to believe now. I am getting out of the Host Gator dedicated server after only 2 weeks.
    Kick Ass SEO - Minnesota Search Engine Optimization Service

  22. #22
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    Someone hacked into the server. He didn't say root was compromised without examining the machine. Had that happened, perhaps your little comments would have had been more excusable.
    Actually, no they didn't After talking to this individual on the phone for quite a while last night, the problem wasn't even that the server got hacked (surprise, I was right). The problem was with WHM/CPanel itself, not the server being hacked.

    As far as my comments being "inexcusable", hey, that's your choice to call them that, however, they're far from "inaccurate". They are 100% accurate.
    In my experience, with techs from countless "industry leading" providers, this is always the first assumption, and it is 99% of the time incorrect, because the tech responding doesn't bother to login to the server to test anything out. This was just one more fine example of that. The server wasn't hacked, yet the tech simply assumed (incorrectly) that it was.

    Security is about prevention and proactive updates in this industry. Your statements fly in the face of that. That comment made by you bear no sign that you are actually aware of why those items were mentioned as " possible " methods that the thread starter could have been compromised. One of the way to reduce exposure is to reduce the possible attack surface.
    Incorrect
    The 4 mentioned will provide absolutely no real "security" at all. They will, however, provide nothing but problems and complications with customers and the like . This is as bad as saying "force phpsuexec, and disable all the necessary functions of php". ALL this will do is create problems, and lure the user into a false sense of security. Of course, that's not mentioning the fact that the last doesn't even belong in a "security" risk, because neither of those have been enabled for years.

    I cannot say for sure WHAT the backdoor was.
    There was none.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details

  23. #23
    Join Date
    Nov 2003
    Location
    Auckland, New Zealand
    Posts
    584
    This is what happened:
    Tamar : You definitely got hacked somehow. Here are a list of possible ways:
    You : Amazing, you can TELL the user got hacked? Yeah, ok, right.

    That was inexcusable statements I was referring to.

    Now you're saying this :
    You : As far as my comments being "inexcusable", hey, that's your choice to call them that, however, they're far from "inaccurate". They are 100% accurate.
    In my experience, with techs from countless "industry leading" providers, this is always the first assumption, and it is 99% of the time incorrect, because the tech responding doesn't bother to login to the server to test anything out. This was just one more fine example of that. The server wasn't hacked, yet the tech simply assumed (incorrectly) that it was.


    You are mixing the two issues. I am not defending the techs that work at any number of world famous datacenters in WHT. They keep quite a few server management and resellers in business because of that. The comments about inexcusable related to your treatment of Tamar. How does being right about the server not being hacked make it right to go after Tamar ? She only tried to answer what the thread starter wanted. A few tips on protection.

    Incorrect
    The 4 mentioned will provide absolutely no real "security" at all. They will, however, provide nothing but problems and complications with customers and the like .
    I don't know where you got your information from, but even common sense dictates : if you don't need something running on the server, turn it off. There is no point in leaving doors open, if you're not expecting anything there. Turning off unneeded applications like : ftp / httpd / irc / X .... blah anything.... in a server IS a good idea. Anyone saying otherwise so are just blowing hot air. Take a moment and step back and see what you're arguing against. You're advocating that " Reducing the possible entry points for ' hackers / script kiddies ' won't do anything for security."

    The logic here is SO SO bad, I'm surprised as a company offering security and management services you're actually arguing against it. If I have to explain these, then I think anyone using your security services need to seriously look at what has been done for them. Finger and telnet are still enabled by default at some datacenters and corporate networks - because they have legit uses. Not to mention people's reluctance to embrace new technology and the amount of old software still running around. So could you explain how those points that Tamar gave in response to the threadstarter's request justify you making the mocking comments ?

    No one is saying the points made by Tamar will give 100% security. Neither me nor Tamar is saying that. These items when taken care of - help reduce the vulnerbility. PHPSuExec wasn't mentioned. While I don't like the idea of using that because of performance, I can see why some people like that because of the security aspect. It gives the additional restrictions that are really helpful to some administrators.

    Aside from that, using the logic " This is as bad as saying "force phpsuexec, and disable all the necessary functions of php". ALL this will do is create problems, and lure the user into a false sense of security. " - if faulty. No one mentioned PHPsueec. Disabling unused programs / changing ports / closing unneded ports don't stop proper use. If you think it does, you need to see how you're doing the tasks wrong. A good sysadmin will know the impact of things he changes and make sure they do not conflict with the client's basic needs.
    Last edited by ImZan; 09-08-2006 at 09:14 PM.
    BLUETRIDENT.NET - Reliable Shared, Reseller and Dedicated Hosting Solutions Provider
    Managed Hosting with Personal Service
    Highspeed Content Servers, Lighttpd, Ruby on Rails, Cluster Servers & Rich Web Application Hosting

  24. #24
    Join Date
    Sep 2000
    Location
    Alberta, Canada
    Posts
    3,109
    ImZan, it's all moot now.

    Sounds like, linux-tech, had a chat with, gobeyond, and is definitely much more knowledgable about the situation than any of us.

    Almost sounds like a Cpanel update was done. Current situation is that without first updating Bind, all kinds of problems will happen. Don't recall an update being mentioned though.
    PotentProducts.com - for all your Hosting needs
    Helping people Host, Create and Maintain their Web Site
    ServerAdmin Services also available

  25. #25
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    A good sysadmin will know the impact of things he changes and make sure they do not conflict with the client's basic needs.
    I'm going to say this, and leave it at that for now.
    What you (and countless others I've seen) recommend is just wrong. Why is it wrong? Because it doesn't help the situation, it hurts it. There are any number of ways how, here's just a couple of them.

    Let's take a look at ssh, shall we?
    SSH is the most critical application out there, and , as such, the most vulnerable to any number of attacks. HOWEVER, there are huge issues with the "modifications" suggested to ssh.

    Disabling root login:
    (Supposed) advantage ? Users have to use a secondary user to login.

    That's not going to solve anything, it'll take me 5 seconds once I'm in the server to figure out the user to use . Any skilled hacker doesn't use "root" logins, they use other vulnerabilities to get into your server

    Disadvantages?
    Now, instead of having to use 1 user to login to the server, you have to use two, and export paths and binaries and, uggh, it's a mess, allll over the place. More time is spent dealing with this than anything. It's nothing but an inconvenience for those who's time you DON'T want to waste.

    Solution?
    -- Use a PROPER root password (alphanumeric, 8+ characters).
    -- Use something like JTR to crack the system passwords and immediately disable those accounts that are easily cracked until they change their pass
    -- Better yet, use an ssh KEY system to get into the server. Bypass the whole (insecure) password thing altogether

    Changing the ssh port:
    This offers no real security at all. Anyone can run a scan against your server and find out what you've changed it to. Not a big deal there.

    2 of those solutions are nothing more than minor band-aids to the problem. The real solutions? You've seen at least 3 recommended that work, and provide minor (if any, at all) inconvenience to those who's time you should be respecting, instead of wasting

    Now, let's take a look at your "Uninstall xxx services" argument, shall we. Once this is done, you'll understand just WHY this is not a recommended option.

    We'll use the average linux user as an example. The average Linux user doesn't havea clue what xfs is, what bind is, what SAMBA is, what gpm is, what inetd is, etc. This user, going by countless posts (even your own, recommending the removal of an FTP server!!!) would uninstall services that are critical (at times) to the operation of a server. How are they supposed to get this stuff back in, if they can't get to the server now?

    See, there's a fine line here, between recommending that XXX application is installed, uninstalled, and KNOWING what it does and that it's safe to uninstall (or modify). Are various services (unused) vulnerable? Sure, but they're no more vulnerable than , say, phpbb. In fact, in most cases those are NOT as vulnerable as phpbb, because at least with services, in most cases you can easily get updates (rhn, yast, yum, etc), and those are (usually) handled automagically when something is needing to be done.

    No, I'm not advocating just leaving a server outdated, leavin stupid stuff running when it's not necessary. On the OTHER hand, I certainly can not advocate individuals saying "remove unused services" , because that (inevitably) will cause huge issues, especially when the user doesn't have a clue what he/she is doing with a Linux system.

    At the end of the day, there's a ballance, a very fine line between removing applications because "they're old", and true security. All the first will do is lure you into a false sense of security.

    True security isn't about obscurity, it's about knowing what your system is doing, what is going on, and what you need to do to prevent issues.

    True security is all about listening to your system and dealing with each on a case by case basis, responding to issues quickly and promptly.

    A (good) sysadmin would never say "your server's been hacked" when it's clear that it hasn't.
    A (good) sysadmin would never encourage such activity as "security by obscurity", as, a (good) sysadmin would know that's just the wrong approach.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details

  26. #26
    Join Date
    Nov 2003
    Location
    Auckland, New Zealand
    Posts
    584
    Quote Originally Posted by linux-tech
    I'm going to say this, and leave it at that for now.
    What you (and countless others I've seen) recommend is just wrong. Why is it wrong? Because it doesn't help the situation, it hurts it. There are any number of ways how, here's just a couple of them.Let's take a look at ssh, shall we?
    To say that these things hurt the security vulnerbilities of the server, as opposed to the default system you have to show that these INCREASE the vulnerbilities of the system. Otherwise you're wrong.

    SSH is the most critical application out there, and , as such, the most vulnerable to any number of attacks. HOWEVER, there are huge issues with the "modifications" suggested to ssh.

    Disabling root login:
    (Supposed) advantage ? Users have to use a secondary user to login.

    That's not going to solve anything, it'll take me 5 seconds once I'm in the server to figure out the user to use . Any skilled hacker doesn't use "root" logins, they use other vulnerabilities to get into your server

    Disadvantages?
    Now, instead of having to use 1 user to login to the server, you have to use two, and export paths and binaries and, uggh, it's a mess, allll over the place. More time is spent dealing with this than anything. It's nothing but an inconvenience for those who's time you DON'T want to waste.

    Solution?
    -- Use a PROPER root password (alphanumeric, 8+ characters).
    -- Use something like JTR to crack the system passwords and immediately disable those accounts that are easily cracked until they change their pass
    -- Better yet, use an ssh KEY system to get into the server. Bypass the whole (insecure) password thing altogether
    Wonderful. So you're saying, it doesn't actually cause extra vulnerbilities. Just the system admin has to work more. Where is the problem in this ? I would actually disagree that there is any other EXTRA work involved in this. If any account is broken into onto the server that is not the root user, then the hacker does not gain immidiate access to all system tools that can be damaging. As anyone who has worked on a real system knows, the longer this person will stay online, the more the chances of discovery.

    So your ORIGINAL point that this actually hurts is rather not true. BTW - I'm not disagreeing with those extra " solutions ". They are additions to doing 2 user login system.

    Changing the ssh port:
    This offers no real security at all. Anyone can run a scan against your server and find out what you've changed it to. Not a big deal there.
    You're right. Lets say that out of 100 people who attempt anything against a server, around 90 of them are just kids / people on the net just trying tools they found on the net. The popular script kiddie. They read the instructions, and it makes a point to note that ssh is port 22. They try this, and get nothing on the server. There goes 90% of your attacks not being successful. No one is saying this is not easily bypassed. It's quite easy to find out for a little more experienced hacker what tools are you running.

    However, as previously mentioned, for your points to be valid at all - you need to prove that doing this is going to actually increase security threat. You've not done so.



    2 of those solutions are nothing more than minor band-aids to the problem. The real solutions? You've seen at least 3 recommended that work, and provide minor (if any, at all) inconvenience to those who's time you should be respecting, instead of wasting
    To login to the server with two sets of logins will take you exactly 5 seconds extra. To use a different port requires NO additional time - except pronbably 5 sections the first time to change the default setting and save the values as bookmarks in your application. If you're on linux using default tools maybe 5 seconds to change the port.

    A lot of time is wasted indeed.

    Now, let's take a look at your "Uninstall xxx services" argument, shall we. Once this is done, you'll understand just WHY this is not a recommended option.

    We'll use the average linux user as an example. The average Linux user doesn't havea clue what xfs is, what bind is, what SAMBA is, what gpm is, what inetd is, etc. This user, going by countless posts (even your own, recommending the removal of an FTP server!!!) would uninstall services that are critical (at times) to the operation of a server. How are they supposed to get this stuff back in, if they can't get to the server now?
    Did you ACTUALLY read the posts that I made before replying to what you think I said ? My contention was removing applications that aren't used. I said, if a client did not require FTP, why leave it running. Obviously the best thing is if the client does not need that, remove it.

    Could you tell me how removing these services and applications that aren't used - which is different for each and every client - increases the risk of security for the client more by changing from the default ?


    See, there's a fine line here, between recommending that XXX application is installed, uninstalled, and KNOWING what it does and that it's safe to uninstall (or modify). Are various services (unused) vulnerable? Sure, but they're no more vulnerable than , say, phpbb.
    So what you're saying is this :

    These applications can be exploited, but even though they aren't used by the client or are "unnecessary"-quoting the original phrase used, they should still be left running.

    That makes no sense to me.

    In fact, in most cases those are NOT as vulnerable as phpbb, because at least with services, in most cases you can easily get updates (rhn, yast, yum, etc), and those are (usually) handled automagically when something is needing to be done.
    To prove your point that these things actually cause harm - you need to show that these make the security situation worse - so far, nothing you've said prove that in the even most remote way.

    No, I'm not advocating just leaving a server outdated, leavin stupid stuff running when it's not necessary. On the OTHER hand, I certainly can not advocate individuals saying "remove unused services" , because that (inevitably) will cause huge issues, especially when the user doesn't have a clue what he/she is doing with a Linux system.
    There is different ways dealing with applications that are not needed. If FTP server is not required, it can be removed or it can be prevented from working. As the idea is to stop unnecessary applications - when they become necessary that should be dealt with then. If the application might be needed in the near future maybe different tact needs to be applied. Again - it does not cause any harm to the end user of the sysadmin or the system does not become more insecure by doing this.

    At the end of the day, there's a ballance, a very fine line between removing applications because "they're old", and true security. All the first will do is lure you into a false sense of security.

    True security isn't about obscurity, it's about knowing what your system is doing, what is going on, and what you need to do to prevent issues.

    True security is all about listening to your system and dealing with each on a case by case basis, responding to issues quickly and promptly.
    If you didn't realise it before, nothing I said, or Tamar said goes against this. In your hurriness to post something, you railed against items that Tamar mentioned - correctly - about the security. What she said does help the security situation.

    The matter has turned out that it's not hacked. However, it still does not invalidate that you are claiming that the steps that make it harder are actually going to cause hurt. Not only is it wrong, but also makes no sense.

    A (good) sysadmin would never say "your server's been hacked" when it's clear that it hasn't.
    A (good) sysadmin would never encourage such activity as "security by obscurity", as, a (good) sysadmin would know that's just the wrong approach.
    A good sysadmin will know that security by obscurity is just one layer of the protection circle - it is not be all, end all. Neither me nor Tamar mentioned any thing that was against this. They know what will help and what won't. What you were saying in your posts to Tamar and me was that these steps mentioned do not help in the security situation.
    BLUETRIDENT.NET - Reliable Shared, Reseller and Dedicated Hosting Solutions Provider
    Managed Hosting with Personal Service
    Highspeed Content Servers, Lighttpd, Ruby on Rails, Cluster Servers & Rich Web Application Hosting

  27. #27
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,686
    Look, I have better things to do with my time than sit and argue a point with an individual who has clearly not got the experience I do in the field of what I do. This is WHAT I do for a living, and I've done it well enough for the past 10 years to gain a somewhat decent reputation at it.
    "Security by obscurity" (what you're suggesting, here) is flawed at best. There are so many holes and ways around things (as I've said before, and demonstrated before) that it just doesn't work. PROPER administration is not hiding, or removing anything, it is KNOWING what your system is and does at all times, at all costs.

    The suggestions and points made by me are very valid. The fact that you simply choose to ignore them is your choice, but that just shows lack of experience. You can run around trying to make your system as obscure as possible, but at the end of the day, it's only going to cause major problems and inconvenience.

    There is a ballance between security, usability, and knowledge. Removing services that you don't know about (including, as suggested by yourself FTP!) will cause problems. Leaving them there? Not always causing the problems.

    The MOST IMPORTANT thing of security isn't "obscurity", as preached by 99% of the individuals who know little about it, but KNOWLEDGE. KNOW what your system is up to at all times.

    Now, let's take this back to the original topic, instead of trying to insult someone's intelligence here, and waste their time.
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details

  28. #28
    Join Date
    Nov 2003
    Location
    Auckland, New Zealand
    Posts
    584
    linux-tech : I've been doing this for just less than seven years. So while you do have a slim lead on me, I think you're reaching if you think you can pass any this off as fruits of wisdom gained through experience. Let me be clear - I'm not disputing your "solutions" - I never have. If you read my posts properly, it should have been clear. If you do end up answering the post, please read the entire post before answering.

    "Security by obscurity" (what you're suggesting, here) is flawed at best. There are so many holes and ways around things (as I've said before, and demonstrated before) that it just doesn't work. PROPER administration is not hiding, or removing anything, it is KNOWING what your system is and does at all times, at all costs.
    First of all , security by obscurity is when you're hiding something.

    Removing / Disabling services and applications that aren't used by the client - is not it. Requiring two logins to get root level access is not it. However changing SSH port can be considered it. Changing the banner for the mail / ftp / httpd / and other services definately is it.

    Do the the last two I mentioned help ? Yes.
    How much do they help ? Some.
    So why do it ? Because every little bit counts. If it detracts one person, then it's one less issue.

    What me and other people who suggest these methods do this is for an additional level of security - by disabling things that aren't needed we are reducing possible entry points. So if a client doesn't need FTP services running on his server ( as a fictional client I've mentioned ) , as a sysadmin - we should not be lax enough in our job to install / keep it running. Should the client need it, by all means re/install it. If it can't be removed for future use, disable it. If it can't be disabled, limit it.

    You're trying to confuse the issues. This whole series of post started because you attacked Tamar for her post giving some nice and simple advice that does help. The original post was made because the thread starter said he was hacked and wanted advise on prevention. You misunderstood the intent of the post, and then proceeded to tear her post apart - mistakenly. Had there been anything in the post that was not common sense or wrong - something would have been alright. You tried to prove the points that Tamara provided aren't helpful at all for security. My original posts intent was to show that you were mistakenly going after Tamar, and nothing she had posted was inaccurate or made the situation worse. Only they helped.

    Perhaps simple maths will help clear this up. Say the chances of security breach through any FTP software ( for the fictional client ) running on a server is = 10%. There is a vulnerbility out for that version of FTP software that the client is using.

    My way : His vulnerbility - if disabled unneeded services - 10% * 0 = 0%
    Your way : His vulnerbility - ftp is not used by the client - 10%

    All I've and anyone else who advocate security through obscurity is saying is that it's a layer of the overall protection, it is not the whole thing. Lets also be clear, a few items you're claiming to be security through obscurity, are not so.

    Double logins do not fall into security through obscurity. Neither does closing open ports. Disabling / Removing unneeded applications that aren't required for a particular server is also not obscurity. These are all exposure limitation excercises. If something isn't needed - you do not run it. The same idea that stops installation of X windows and samba being installed on the server by default at most datacenters.

    Just to be clear, I've not tried to insult you. If you think I have - I apologise. I've made a point to reread my posts before this posting and didn't think so. I've tried being polite and reasonable.

    You're making valid points about needing to secure the system properly - however neither I or Tamar said anything at all to warrant this justification by you in the first place because frankly no one disagrees with the solutions as an added level of security.

    However, you are saying these in response to posts made by me on how you're wrong about not needing to turn off / remove unneeded applications. To show that you're right, you must prove that doing so makes it worse from a security stand point. If you're not going to read what is posted, and try to confuse the original matter of the post with confusing lines of discussion - there is no point in discussing things further. So I will stop now. Have a great day.
    BLUETRIDENT.NET - Reliable Shared, Reseller and Dedicated Hosting Solutions Provider
    Managed Hosting with Personal Service
    Highspeed Content Servers, Lighttpd, Ruby on Rails, Cluster Servers & Rich Web Application Hosting

  29. #29
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    1,683
    I'll just make one point that occurred to me out of the above.

    Running ssh on a port other than port 22 is not about "security through obscurity". It's about taking your machine out of the space where noobs attack it and flood your logs. I don't know about you, but it's a hell of a lot easier to just do without that noise in my logs. And getting a server out of the realm where automated attacks/scans can take place is a brilliant idea - there's always a (very small) chance that one day there'll be an SSH compromise.

    The point here is that an intelligent system configuration actually will use a whole number of "security through obscurity" techniques. Relying on them would be ridiculous, but some of them do add to security. Of course, there's a point at which you draw the line, for an average server, but changing ssh's port is well above that. Of course, a determined and skilled hacker would find your new SSH port in a matter of minutes, but they're rare, and they're always going to be harder to stop anyway. Good security is done in layers, and "security through obscurity" can be useful as ONE of those layers providing there are other layers under it.

    If you're new to server management, I'd always get a good linux admin company to "harden" your server. There are a lot of things that can be done to help, and when these things are all done by a competent system admin they act in concert to make it very unlikely that your system will ever be compromised. Sure, it will cost you around US$100 or so, but it will save you hours of grief and expense that would be incurred in the case of a serious server compromise. You don't need to waste your time and energy cleaning one of those up!! As a system admin with over 20 years of Unix experience/teaching, I still use a specialist security company (www.configserver.com) to do this stuff for me - they're experts, they do it every day - I'm just knowledgeable. There are a bunch of good companies/people out there - linux-tech, rack911, configserver - find one that has a hardening package you like and get it!
    Last edited by brianoz; 09-09-2006 at 07:44 PM.

  30. #30
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,574
    linux-tech,

    As ImZan said, most attacks are either:

    a) automated (and thus use port 22 for SSH, and root for the username - most of the time)
    b) done by script kiddies who just download tools and read instructions, etc.

    By offsetting the SSH port, you are immune to the vast majority of attacks against SSH. Why would you *not* want this?

    This does NOT hurt security, despite your failed attempt at 'proving' the contrary. This HELPS security.

    Of course, as stated by brianoz, you eventually have to draw the line, but there is NOTHING wrong with implementing obscurity for simple things like this. I personally maintain an SSH session to all of my servers - all day long, so I only have to login once anyways.

    Your suggestions are not bad either, linux-tech, and nobody here is disputing them, but there is nothing wrong with obscurity and your post does not 'prove' that there is anything wrong with it either.
    MediaLayer, LLC - www.medialayer.com Learn how we can make your website load faster, translating to better conversion rates for your business!
    The pioneers of optimized web hosting, featuring LiteSpeed Web Server & SSD Storage - Celebrating 10 Years in Business

  31. #31
    Join Date
    Dec 2004
    Location
    New York, NY
    Posts
    10,574
    BTW - one of your earlier points, linux-tech,

    9/10 times, you don't need a reload. Of course, the "tech" is going to want you to get one, because company makes more money that way, etc.
    While is it true that you can recover a system without reload and likely have no problems, it is STILL a good practice to reload and there is absolutely nothing wrong with doing so. A clean slate is great and will allow you to have peace of mind that there is nothing left on the system that could allow it to be compromised again.
    MediaLayer, LLC - www.medialayer.com Learn how we can make your website load faster, translating to better conversion rates for your business!
    The pioneers of optimized web hosting, featuring LiteSpeed Web Server & SSD Storage - Celebrating 10 Years in Business

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •