hosted by liquidweb


Go Back   Web Hosting Talk : Web Hosting Main Forums : Web Hosting Talk Tutorials : Hosting Security and Technology Tutorials : How to (somewhat) secure a Linux Server
Reply

Forum Jump

How to (somewhat) secure a Linux Server

Reply Post New Thread In Hosting Security and Technology Tutorials Subscription
 
Send news tip View All Posts Thread Tools Search this Thread Display Modes
  #1  
Old 01-17-2004, 10:33 PM
twhiting9275 twhiting9275 is offline
Just me
 
Join Date: Sep 2002
Location: Among the corn
Posts: 10,472

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



Sponsored Links
  #2  
Old 01-17-2004, 11:48 PM
Steven Steven is online now
Problem Solver
 
Join Date: Mar 2003
Location: California USA
Posts: 13,113
Aide is also good in replacement for tripwire


Last edited by anon-e-mouse; 01-26-2004 at 09:50 AM.
  #3  
Old 01-17-2004, 11:55 PM
twhiting9275 twhiting9275 is offline
Just me
 
Join Date: Sep 2002
Location: Among the corn
Posts: 10,472
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.
Sponsored Links
  #4  
Old 01-17-2004, 11:57 PM
Steven Steven is online now
Problem Solver
 
Join Date: Mar 2003
Location: California USA
Posts: 13,113


Last edited by anon-e-mouse; 01-26-2004 at 09:52 AM.
  #5  
Old 01-18-2004, 02:48 AM
TheVoice TheVoice is offline
Web Hosting Master
 
Join Date: Oct 2002
Posts: 702
Quote:
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  
Old 01-18-2004, 02:55 AM
choon choon is offline
Retired Moderator
 
Join Date: Jul 2001
Location: Singapore
Posts: 1,790
Quote:
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  
Old 01-18-2004, 05:00 PM
TheVoice TheVoice is offline
Web Hosting Master
 
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  
Old 01-20-2004, 05:55 PM
Promethyl Promethyl is offline
Junior Guru Wannabe
 
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  
Old 01-25-2004, 10:54 PM
RobTheGolfer RobTheGolfer is offline
Web Hosting Master
 
Join Date: Jul 2002
Location: USA
Posts: 1,124
Nice post and information. Very appreciated.


Last edited by anon-e-mouse; 01-26-2004 at 09:54 AM.
  #10  
Old 01-26-2004, 09:40 AM
Mdot Mdot is offline
Web Hosting Master
 
Join Date: Feb 2002
Posts: 981
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  
Old 01-26-2004, 11:55 AM
interactive interactive is offline
Web Hosting Master
 
Join Date: Aug 2002
Location: Chandler, Arizona
Posts: 2,564
Quote:
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  
Old 01-26-2004, 12:16 PM
choon choon is offline
Retired Moderator
 
Join Date: Jul 2001
Location: Singapore
Posts: 1,790
Quoted from Security-HOWTO:
Quote:
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  
Old 01-26-2004, 04:49 PM
Mdot Mdot is offline
Web Hosting Master
 
Join Date: Feb 2002
Posts: 981
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  
Old 01-26-2004, 05:12 PM
twhiting9275 twhiting9275 is offline
Just me
 
Join Date: Sep 2002
Location: Among the corn
Posts: 10,472
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  
Old 01-26-2004, 06:32 PM
Mdot Mdot is offline
Web Hosting Master
 
Join Date: Feb 2002
Posts: 981
Quote:
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.

Quote:
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.

Quote:
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.
Reply

Related posts from TheWhir.com
Title Type Date Posted
Linux Malware Operation Windigo Infects 25,000 Web Servers Web Hosting News 2014-03-19 11:44:53
Linode Updates Cloud-Based Load Balancer Service with SSL Support Web Hosting News 2013-11-08 11:50:09
Big Data and Cloud Drive Enterprise Linux Adoption: Report Web Hosting News 2013-03-27 12:54:34
Web Host AYKsolutions Launches Unmetered Linux VPS Hosting at Chicago Data Center Web Hosting News 2013-01-07 16:23:08
DreamHost-Connected Cloud Storage Spinoff InkTank Joins Linux Foundation Web Hosting News 2012-08-28 16:20:56


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes
Postbit Selector

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

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump
Login:
Log in with your username and password
Username:
Password:



Forgot Password?
Advertisement:
Web Hosting News:



 

X

Welcome to WebHostingTalk.com

Create your username to jump into the discussion!

WebHostingTalk.com is the largest, most influentual web hosting community on the Internet. Join us by filling in the form below.


(4 digit year)

Already a member?