Find the answer to your Linux question:
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 11
As a few members here know, I recently got blind-sided by what I'm almost certain was a rootkit. I've been limping along for the last week or so with a ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined! questio verum's Avatar
    Join Date
    Jun 2007
    Location
    Adrift in an ever-expanding universe, quietly contemplating the wondrous and the inevitable.
    Posts
    82

    Rebuilding after rootkit invasion - need advice


    As a few members here know, I recently got blind-sided by what I'm almost certain was a rootkit. I've been limping along for the last week or so with a reinstall that I'm not even sure is clean. I've got a new drive sitting in wraps on my desk, and I should have a trustworthy copy of Fedora 9 in my hands by Friday. What I'd like to know is: What is the best way to reduce the chances of this happening again?

    I'm all ears at this point. I know I've got a lot to learn about security. How good is the firewall app that comes with Fedora 9 (KDE 4.0.3)? Should I use it in beginner mode, or woodshed and learn the expert mode? What other measures should I take? I've been studying SELinux. Since rootkits and lax security policies seem to be the greatest threat for a novice like me, what else should I consider? I will eagerly devour any info you might send my way.

    -Learning the hard way-

    qv

    EDIT: I've now got what I'm reasonably confident is a clean install of FC9 on the old drive. I want to get familiar before breaking the seal on the new stuff. One of the problems I've faced is that I couldn't be confident in any of the software I had on hand, since I don't know what might have picked up malicious code during the burn process. So.... I've tossed everything. I pulled & burned this copy of FC9 from a clean machine. When installing FC9 I activated drive encryption, set up the firewall using beginner mode, and activated SELinux using the defaults. I'd like to use flash player, but I know just enough about the risk to be totally paranoid. I'm not one to visit obviously risky sites, but now I look at every site -even this one- with a skeptical eye. I've been to the OReilly site looking for some decent books on Fedora, iptables, and security. I've also spent a little time at the NSA security site, If anyone has any words of wisdom, you have my attention. Thanks.

  2. #2
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Quote Originally Posted by questio verum View Post
    As a few members here know, I recently got blind-sided by what I'm almost certain was a rootkit. I've been limping along for the last week or so with a reinstall that I'm not even sure is clean.
    If you don't think it is clean then don't use it. You'll just get rooted again.

    What I'd like to know is: What is the best way to reduce the chances of this happening again?
    1. Do not install any software that you do not need.
    2. Do not allow any un-secure connections.
    3. Use ssh keys not passwords to log into the box remotely
    4. move all services that are to be available on the net to a chroot environment.
    5. Hard firewall that doesn't allow any connection other then the service you provide.
    6. firewall logging
    7. Run SELinux
    8. Install IDS software
    9. Passwords that are random with a combination of upper/lower case letters, numbers and special characters.
    10. keep the system off-line until you have it completely configured.


    I'm all ears at this point. I know I've got a lot to learn about security. How good is the firewall app that comes with Fedora 9 (KDE 4.0.3)?
    IPTABLES should be good enough. Learn how to set them up from the CLI and don't rely on a GUI program for this.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  3. #3
    Just Joined! questio verum's Avatar
    Join Date
    Jun 2007
    Location
    Adrift in an ever-expanding universe, quietly contemplating the wondrous and the inevitable.
    Posts
    82
    Thanks, Robert. I take your advice to heart. I skimmed through a primer on iptables earlier tonight. I'll print and read it more thoroughly when I get home tomorrow. Your point is well taken about not relying on a non-trustworthy OS install. I feel relatively confident that as of last night I finally got a clean copy by pulling and burning it from my brothers machine. I installed it on my old drive (after running a clean copy of DBAN on the most stringent setting) basically to use as a sandbox, for familiarization and learning before I install on the new drive for keepsies. I'm not storing anything I intend to keep beyond the next few days. Logging into this site is about as much disclosure as I'm allowing in my use of this install.

    I don't use remote logins right now, so as far as I know that's not an issue. Your list draws a couple questions though. I'm buying a couple of O'Reilly books on *nix security and Fedora, but in the meantime it sure would be cool if you'd indulge me on a couple of questions. I'm not totally clear what you mean by 'un-secure connections'. Are you talking about the path between my box and my isp, or something else? I'm cabled to a router with firewall which runs out to my cable modem. The router has wireless, but the wireless is turned off. Would you recommend a firewall appliance, or a dedicated pc running something like Smoothwall? Am I missing the point?

    I grasp the concept of a chroot environment, but I really need to learn details, and how to set it up. Beyond googling, do you have any tutorial recommendations? Anything special I should look for in an IDS? I hope I'm not bugging you with the questions. Your above response was very much appreciated. Thanks!

    qv

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Lazydog's Avatar
    Join Date
    Jun 2004
    Location
    The Keystone State
    Posts
    2,677
    Here is a great tutorial on IPTABLES
    If you need help setting this up let me know.

    Regards
    Robert

    Linux
    The adventure of a life time.

    Linux User #296285
    Get Counted

  6. #5
    Super Moderator Roxoff's Avatar
    Join Date
    Aug 2005
    Location
    Nottingham, England
    Posts
    3,903
    There are other options you could look at for security. It also helps to understand why someone would hack your system.

    The way I do it is to use a dedicated firewall system between my server and the internet - I use smoothwall, although there's quite a bit of choice if you look. What this does is push my security off my main server to a known, tightly controlled environment (and one that is configured by people that know much more about security than I do).

    If you have this arrangement, then you don't need to worry nearly as much about securing the server itself. You only need to secure the services that run on ports that have been forwarded by the firewall. This simplifies things significantly.

    If you know what potential hackers would want with your system, then it's also easier to guard against it. If they're just script kiddies looking to steal your bandwidth to ddos on their mates, then just making things slightly more difficult for them will make them go elsewhere.

    If you're being hacked by people wanting you to distribute spam/email, just don't allow email connections into your computer, or spend your time bolting down your email server so that this can never happen.

    If you've got business confidential information that some folks might want to steal, then encrypt it with strong keys, keep backups and if possible keep really sensitive data off the server. You could even construct 'public' misinformation versions of the stuff you really want to keep private (but that kind of behaviour is for the truly paranoid).
    Linux user #126863 - see http://linuxcounter.net/

  7. #6
    Just Joined!
    Join Date
    Aug 2008
    Location
    Seattle, WA
    Posts
    46
    Quote Originally Posted by Lazydog View Post
    1. Hard firewall that doesn't allow any connection other then the service you provide.
    2. firewall logging
    I know that firewalls are generally configured DENY ALL then ALLOW <specific>, but is there a reason for this? if my machine isnt listening on port xxx, what harm does it do if its not blocked?

    I know that if I AM compromised, having a harsh firewall will prevent the attacker from hosting new services and connecting to things I dont like... but if I'm compromised, cant the attacker just flush the firewall rules?

    additionally, why firewall logging? I asked about iptables performance in #debian this evening and was told that unless I was logging, I could run my firewall pretty much however I want on pretty much any hardware and not take a performance hit.

  8. #7
    Just Joined! questio verum's Avatar
    Join Date
    Jun 2007
    Location
    Adrift in an ever-expanding universe, quietly contemplating the wondrous and the inevitable.
    Posts
    82
    Quote Originally Posted by Roxoff View Post
    There are other options you could look at for security. It also helps to understand why someone would hack your system.
    I'm fairly confident anyone trying to get into my machine would fall into the first or second group. I don't store anything of great value on this system.

    The way I do it is to use a dedicated firewall system between my server and the internet - I use smoothwall, although there's quite a bit of choice if you look. What this does is push my security off my main server to a known, tightly controlled environment (and one that is configured by people that know much more about security than I do).
    This is looking more and more like the best setup for me. I'm thinking of running smoothwall or openbsd on a pico or itx palm-sized box and running it as a headless unit after setup. I'm trying to think 'green' and space-saving here. I've got too much clutter around me already, I've also wondered if anything would be gained from setting the firewall to boot from cd only, and eliminate any writeable media. Is that feasible?

  9. #8
    Administrator jayd512's Avatar
    Join Date
    Feb 2008
    Location
    Kentucky
    Posts
    5,023
    Quote Originally Posted by NeoIce View Post
    I know that firewalls are generally configured DENY ALL then ALLOW <specific>, but is there a reason for this?
    Easy... Linux is pretty much built around being secure. On that note, it's better to lock all of the doors in the house, and only open the one you need
    Jay

    New users, read this first.
    New Member FAQ
    Registered Linux User #463940
    I do not respond to private messages asking for Linux help. Please keep it on the public boards.

  10. #9
    Just Joined!
    Join Date
    Aug 2008
    Location
    Seattle, WA
    Posts
    46
    [QUOTE=jayd512;631566][QUOTE=NeoIce;631279]I know that firewalls are generally configured DENY ALL then ALLOW <specific>, but is there a reason for this?

    Easy... Linux is pretty much built around being secure. On that note, it's better to lock all of the doors in the house, and only open the one you need
    exactly. isnt that why I have ssh-keys, strong passwords, PAM modules (notably the 'wheel' group), and noexec on the user-writable partitions (/home, /tmp)? it seems like all the firewall is protecting against are things that would occur AFTER a malicious user gained access to my system.

  11. #10
    Linux Guru Jonathan183's Avatar
    Join Date
    Oct 2007
    Posts
    3,043
    Quote Originally Posted by NeoIce View Post
    it seems like all the firewall is protecting against are things that would occur AFTER a malicious user gained access to my system.
    or something being accidentally introduced ... which is then exploited ... deny all & only open required ports just seems like a better approach to me. Why leave a port open you don't need ?

Page 1 of 2 1 2 LastLast

Posting Permissions

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