Page 1 of 3 123 LastLast
Results 1 to 25 of 61
  1. #1
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685

    How to (somewhat) secure a Linux Server

    While the only way to secure a server 100% is to unplug it from the network, there are quite a few things that I do to enhance security. A few of them (the non client exclusive stuff) can be found right here. Questions, as always can be asked and I'll try to explain it as easily as humanly possible.
    Anything added
    Code:
    like this
    should be added to the file right above it, using whatever shell editor you choose (vi, pico, etc).

    in /etc/sysctl.conf, add
    Code:
    # disable packet forwarding
    net.ipv4.ip_forward = 0
    # enable source route verification
    net.ipv4.conf.all.rp_filter = 1
    # ignore broadcast pings
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    # enable syn cookies
    net.ipv4.tcp_syncookies = 1
    # size of syn backlog
    net.ipv4.tcp_max_syn_backlog = 512
    # disable automatic defragmentation 
    # set max files
    fs.file-max = 32768
    # Enable IP spoofing protection, turn on Source Address Verification
    net.ipv4.conf.all.rp_filter = 1
    # Enable TCP SYN Cookie Protection
    net.ipv4.tcp_syncookies = 1
    # Enable ignoring ping request
    net.ipv4.icmp_echo_ignore_all = 1
    What does this do?
    This sets a variety of code for the linux OS to use itself. It tells the system to ignore pings, icmp, enable SYN protection, disable network forwarding and more.
    Please note
    After doing this, you will need to restart your network (generally rebooting the server works fine).

    in /etc/rc.local, add
    Code:
    for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
    echo 1 >
    done
    echo 1 > /proc/sys/net/ipv4/tcp_syncookies
    for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
    echo 0 >
    done
    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
    This does much of the same thing as the above, it's more repetitive, but it's another layer of 'security' as it were. ICMP is denied, broadcasts denied, tcp syn is denied.

    in /etc/host.conf, the following is added (if it doesn't exist already)
    Code:
    # Lookup names via DNS first then fall back to /etc/hosts.
    order bind,hosts
    # We have machines with multiple IP addresses.
    multi on
    # Check for IP address spoofing.
    nospoof on
    The comments are quite clear on this one. The first uses bind, then hosts to lookup domain names. The second says we have machines with multiple ip addresses (in many cases it's important). The third (somewhat) prevents individuals from "spoofing" an ip address and hitting up your server.

    In /etc/hosts.deny, the following line is added:
    Code:
    ALL: PARANOID
    More "spoof" protection there.

    From there, it's time for the firewall. The firewall is the most important thing to a linux server. Without it, you can be literally killed. With it, you are somewhat defended and protected. While no good firewall will fully protect a Linux server, it's an extra layer of security, which is a very good thing.
    Personally, I use APF which maintains a decent ballance between blocking ports you don't want accessed and limiting traffic. There's also a wonderful attempt at a ddos protection system in place there. While (again) no ddos protection can work on a TRUE ddos, it'll stop a number of attacks.

    From there, it's time for the kernel. Look around for a tutorial on kernels. You can either custom compile the kernel (not recommended unless you're highly familliar with Linux) or use an RPM (or whatever package system you're using).

    Compiling a kernel is NOT recommended on non local machines. Why? Because if you screw something up, you have no chance at hitting that power down button, starting up in single user mode and recompiling it. You have to wait for the datacenter to respond to the ticket, which (usually) is slow and very costly.


    There are a variety of other (personal) configuration changes that I make to applications, to prevent them from overloading, such as:
    proftpd:
    in /etc/proftpd.conf, I add:
    Code:
    TimeoutIdle 600
    TimeoutNoTransfer 600
    TimeoutLogin 300
    MaxInstances 30
    MaxClientsPerHost 2
    at the top. This is pretty much self explanatory

    for mysql:
    in /etc/my.cnf (or wherever my.cnf is located)
    Code:
    [mysqld]
    port            = 3306
    skip-locking
    set-variable    = max_connections=100
    set-variable    = max_user_connections=20
    set-variable    = key_buffer=16M
    set-variable    = join_buffer=4M
    set-variable    = record_buffer=4M
    set-variable    = sort_buffer=6M
    set-variable    = table_cache=1024
    set-variable    = myisam_sort_buffer_size=32M
    set-variable    = interactive_timeout=100
    set-variable    = wait_timeout=100
    set-variable    = connect_timeout=10
    set-variable    = thread_cache_size=128
    And finally, in /etc/rc.local, I add:
    Code:
    TMOUT=180
    export TMOUT
    at the bottom. This logs everyone off if they're idle for more than 3 minutes. Adjust that at will, it goes by seconds, so say 300 seconds would be 5 minutes, 600 would be 10 minutes idle, etc.

    There's a number of other security tricks that I use , such as:
    limiting ssh access
    in /etc/hosts.deny
    Code:
    sshd: ALL
    in /etc/hosts.allow
    Code:
    sshd: host.ip.number.1,host.ip.number.2,etc
    Some would eliminate root login, but I wouldn't take it that far. If your server is properly monitored, you won't need to elliminate it.

    Some would suggest using tripwire, and at the beginning, I did, as well, until I started working with hosts who had real data on their server, and it (literally) crippled the servers. Tripwire is something that will check everything on your server to ensure that it's running smoothly, and that it hasn't been modified. The downside to that is if you've got a ton of files on the server, it loads the server down untill it just can't be accessed any longer. The same goes with updatedb, which is why I actually remove the cron entry for that as well.

    Unfortunately, there's no real "automation" for security and systems administration. The best key in the game is knowing your logs, reading them, understanding what they say, and how to react based on it. As well, tools such as chkrootkit and FAF will help, and knowing as well as working with Linux for years helps. A lot of the security job is knowing when to react, and just exactly how to react, as well as being informed. If you don't know something, ask, especially if it looks suspicious

  2. #2
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,261
    Aide is also good in replacement for tripwire
    Last edited by anon-e-mouse; 01-26-2004 at 09:50 AM.

  3. #3
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685
    got a link? I'm always looking for new toys (errm utilities) to play with
    Last edited by anon-e-mouse; 01-26-2004 at 09:51 AM.

  4. #4
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,261
    Last edited by anon-e-mouse; 01-26-2004 at 09:52 AM.

  5. #5
    Join Date
    Oct 2002
    Posts
    702
    Compiling a kernel is NOT recommended on non local machines
    You might want to change that to remote instead of local.
    Last edited by anon-e-mouse; 01-26-2004 at 09:52 AM.

  6. #6
    Join Date
    Jul 2001
    Location
    Singapore
    Posts
    1,790
    Originally posted by TheVoice
    You might want to change that to remote instead of local.
    Doesn't this same meaning?
    non local and remote?
    Or you mean:
    Compiling a kernel is NOT recommended on non remote machines
    instead of:
    Compiling a kernel is NOT recommended on non local machines

  7. #7
    Join Date
    Oct 2002
    Posts
    702
    I really should stop posting at 3 in the morning
    Last edited by anon-e-mouse; 01-26-2004 at 09:53 AM.

  8. #8
    Join Date
    Mar 2003
    Location
    Kansas City, MO
    Posts
    66
    This post was helpful. THank you.
    Last edited by anon-e-mouse; 01-26-2004 at 09:55 AM.

  9. #9
    Join Date
    Jul 2002
    Location
    USA
    Posts
    1,125
    Nice post and information. Very appreciated.
    Last edited by anon-e-mouse; 01-26-2004 at 09:54 AM.

  10. #10
    I see no reason for disabling ICMP - can anyone explain?

    regards,
    M.
    Last edited by anon-e-mouse; 01-26-2004 at 09:55 AM.

  11. #11
    Join Date
    Aug 2002
    Location
    Chandler, Arizona
    Posts
    2,564
    Originally posted by Miha
    I see no reason for disabling ICMP - can anyone explain?

    regards,
    M.
    Prevents pinging. I guess in a DDoS attack that's a good thing.
    Last edited by interactive; 01-26-2004 at 12:25 PM.

  12. #12
    Join Date
    Jul 2001
    Location
    Singapore
    Posts
    1,790
    Quoted from Security-HOWTO:
    Ping flooding is a simple brute-force denial of service attack. The attacker sends a "flood" of ICMP packets to your machine. If they are doing this from a host with better bandwidth than yours, your machine will be unable to send anything on the network. A variation on this attack, called "smurfing", sends ICMP packets to a host with your machine's return IP, allowing them to flood you less detectably. You can find more information about the "smurf" attack here.

  13. #13
    actually ICMP packets are being "cut" at the router (your closest router, to be correct). Try doing "ping -f -s 40000 somehost.com" for example - you will see a lot (more than 50%; probably close to 90%) of packets getting lost. Your provider won't allow such action most likely, unless, of course, there is some very old router that allows you to pass such amount of ICMP packets per second.
    I remember when one could knock Win98 with "ping -f" (ping of death), but this is not an issue anymore.
    ICMP pings are useless these days, and I can't remember any host/network suffering from ICMP flood for the past "N" years.

    regards,
    M.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:13 PM.

  14. #14
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685
    Actually, you're wrong
    Just because the -f option to ping is limited doesn't mean ping can't be used to launch any sort of attack against a server. The best response is to nullroute icmp alltogether.

    It's entirely possible to flood a server, not with packets but with data, which customer has to pay for, and (usually) ends up crippling a server until whoever is doing it has decided they are done.

    If ping flooding were disabled, or weren't such a common thing, then datacenters wouldn't have a single problem, but, it is, unfortunately. ICMP is a very dangerous protocol to leave open on your server.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:13 PM.

  15. #15
    Originally posted by wolfstream
    Actually, you're wrong
    Just because the -f option to ping is limited doesn't mean ping can't be used to launch any sort of attack against a server. The best response is to nullroute icmp alltogether.
    hm, I think I've covered that in my last post - most (if not all) providers have decent routers. This problem with ICMP flood is not a problem anymore - nearly all routers limit the ICMP packet rate and size of ICMP packet. I don't think you will be able to send a packet larger than 67k of data - router simply won't accept it.

    It's entirely possible to flood a server, not with packets but with data, which customer has to pay for, and (usually) ends up crippling a server until whoever is doing it has decided they are done.
    again, if you sent 10.000 echo requests, it does not mean destination will take all of them because routers will cut more than 3/4th of it, unless you send 1 packet per second, as suggested, which isn't going to cause you flood with terabytes of bandwidth.

    If ping flooding were disabled, or weren't such a common thing, then datacenters wouldn't have a single problem, but, it is, unfortunately. ICMP is a very dangerous protocol to leave open on your server.
    however, statistics show that targeted attack on specific service is more common and more dangerous than simple ICMP flood, which isn't a flood, eventually.

    regards,
    M.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:14 PM.

  16. #16
    Post has been helpful...Thanks!

  17. #17
    Join Date
    Nov 2003
    Posts
    320
    Is this safe to do on a RHE server with Cpanel?

  18. #18
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685
    Originally posted by damainman
    Is this safe to do on a RHE server with Cpanel?
    I (personally) haven't tried this on RHE, but I don't see how it'd be much different. The core is the same.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:14 PM.

  19. #19
    Join Date
    Nov 2003
    Posts
    320
    thanks,

    Now its that i know some code, not much but something have changed for RHE, then RH9... For example disabling recurssive look ups.

    Any known conflicts with cpanel?

  20. #20
    Join Date
    Nov 2003
    Posts
    320
    Thanks for the tutorial, very easy to follow.

  21. #21
    Join Date
    Jan 2004
    Posts
    31
    Just the info I was looking for.

  22. #22
    ( i can't ssh to my server after i do what u said ( . What now ??

  23. #23
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685
    Have your DC login and move hosts.deny and hosts.allow to hosts.deny.bak and hosts.allow.bak.
    Make sure your ip is in the exclusion line that I mentioned above.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:15 PM.

  24. #24
    but i did not do anything in those files !!!! .

  25. #25
    Join Date
    Sep 2002
    Location
    Among the corn
    Posts
    10,685
    then you didn't do what I suggested I've had servers running on the same scripts and setup for over 2 years without a problem. The only time you'd get denied ssh access is if:
    A> you've blocked ssh without allowing your own ip
    OR
    B> you've got an ip[ that doesn't resolve correctly.

    <edit>signature removed</edit>
    Last edited by choon; 02-09-2004 at 09:15 PM.

Page 1 of 3 123 LastLast

Related Posts from theWHIR.com

Posting Permissions

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