5 Tips for any Linux administrator
1) Disable users account quickly.
Every administrator at one point or another needs to quickly remove a users access on their Linux servers. We can do the below
usermod -l Johnny
The above will deny Johnny access to login to your Linux system via sshd, etc. What this does is it adds ! in front of the encrypted password in /etc/shadow. Should Johnny decide to behave, and you’re bored enough to unlock him, issue the below:
usermod -U Johnny
The above will removed the ! and Johnny will be able to login to the system again.
2) Disable ICMP Echo Replies (aka stop your Linux server from replying to pings)
Ping? Pong! So you want to stop replying to ICMP echo (ICMP_ECHO) TCP packets. This is often issued in times of DoS, where replying to every packet with an ICMP_ECHO_REPLY quickly satures the pipe. What we can do is disable replies on the system.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
Now ping your system. Get anything back? To re-enable ICMP replies, issue the below.
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
3) Limit your ssh daemon (sshd) to certain IPs.
What we are going to do here is use tcpwrappers to limit access to sshd by certain IP blocks. In this case, we will use your home IP and grant yourself access to sshd. We do this by editing /etc/hosts.allow and /etc/hosts.deny respectively. This is great for stopping brute force attacks, and a general nice bit of security over all.
echo ‘SSHD : YOURIPHERE : ALLOW’ >> /etc/hosts.allow
Now, we’ve granted your home IP access. Make sure this is the correct address!
echo ‘SSHD : ALL : DENY’ >> /etc/hosts.deny
Now you have blocked sshd access to everybody NOT defined in /etc/hosts.allow – be careful!
4) Disabling Trace in Apache. Very common issue of failure in PCI-related scans.
Often times, when doing PCI related webserver scans (or PCI related webserver scams….) you will see that Tracing is enabled in Apache, and now you’ve failed.
echo ‘TraceEnable Off’ >> /etc/httpd/conf/httpd.conf
service httpd restart
You may have to adjust the /etc/httpd/conf/httpd.conf above with your main Apache webserver configuration file. We then reload Apaches configuration so the changes take effect. You can now re-run the test if this is the only issue the scan detected.
5) Disabling SELinux
Bah, SELinux. You want it gone but keeps coming back. Below you will see how to disable SELinux.
Take your favorite Linux text editor (in this case, we will use nano. You can use vi, pico, etc as you wish).
nano /etc/selinux/config
We want to turn “SELINUX=whatever” to SELINUX=disabled – then save changes.
This still isn’t enough. To fully disable SELinux, you need to do one additional step.
echo 0 > /selinux/enforce
reboot
PHP opcode caching
Install APC Caching
One of the most common occurences today of webserver load is the ever-so-needed PHP. PHP is usually a must have – often not a way around it. It’s just too popular and mainstream in todays Internet. How would we reduce load caused by PHP? Well, what we CAN do is install some caching. I prefer APC myself – it’s easy, fast and it plain works. The problem with APC is you cannot run Zend and Ioncube with. This usually crosses it off shared hosting servers.
APC works by caching PHP opcodes and storing them in memory (RAM). This usually significally reduces load caused on your server caused by PHP applications. For this example, we will assume you are running PHP 5.2, Apache webserver and CentOS Linux operating system.
Onto installing APC!
The first way we can do is if you have php-pear installed. Then we can use PECL 
First thing you can try is installing straight from pecl. This won’t work depending on things such as /tmp hardening, SELinux status, etc. I’ll explain how to get around that and install APC for PHP caching in a moment.
pecl install apc
nano /usr/local/lib/php.ini
service httpd restart
Of course, remove the Zend-related lines. If your php.ini is in a different spot, please change the above. If you don’t have nano installed, use vi – or whatever editor you DO have installed.
A lot of times installing APC for PHP caching doesn’t work with the above. These reasons can be /tmp is noexec, SELinux is blocking the C compiler, etc. So, what I do is below:
pecl download apc
cd apc*
phpize
./configure –with-apc
make && make install
Now, if everything worked above – you need to again uncomment the Zend lines in your php.ini (/usr/local/lib/php.ini for cPanel users) and add extension=apc.so to your php.ini as well. Then you can:
service httpd restart
php -i | grep -i apc
Now, APC caching for PHP should be enabled! Congratulations and I hope the PHP induced load on your Linux webserver is now dropping steadily.
Setting up a HTTP load balancer
HAProxy is a TCP load balancing application. It can be used to loadbalance TCP connections (i.e., email(smtp etc)) – not just webservers. Very conveniently, however, HAProxy does in fact have it’s own mode for HTTP specific applications. In this guide, we will setup HAProxy infront of 2 fictional Apache webservers with the HAProxy server running CentOS. If one server goes offline, we will begin serving connections to the other server in a roundrobin fashion.
Important thing to note is all requests will come from the HAProxy server! Awesomely enough, however, we will include the X-Forwarded-For value of the clients IP in our packets. This means you can install mod_rpaf on your Apache webserver, or similar, and log the correct IPs.
Lets start.
Login to your Linux server, and install HAProxy.
wget http://haproxy.1wt.eu/download/1.3/src/haproxy-1.3.23.tar.gz
tar zxvf haproxy-1.3.23.tar.gz
cd haproxy-1.3.23
make
cp haproxy /usr/sbin/haproxy
Now, grab an init file for HAProxy so we can easily start/stop HAProxy. The good guys over at Rack911 have provided a download for you to use.
wget http://layer1.rack911.com/haproxy/haproxy.init -O /etc/init.d/haproxy
chmod +x /etc/init.d/haproxy
Below is what will be your /etc/haproxy.cfg – First thing we want to do is set the maximum connections HAProxy will handle simultaneously. Good thing to note is connections over this limit are queued, and not disregarded. We will set this under the global block. We will also configure the daemon and nbproc settings.
global
maxconn 4096 # Total max connections. Adjust as needed.
daemon # We are going to run HAProxy as a daemon.
nbproc 2 # This HAProxy server is an Atom, so it has 2 cores visible. Set to number of processing cores you have #available.#Next we’re going to set some other HAProxy settings under the defaults block.
defaults
mode http # Run HAProxy in HTTP mode. HAProxy can do a lot more than HTTP!
clitimeout 60000 # Wait 60,000ms or 60s for client to time out on us.
srvtimeout 20000 # We will only wait 30 seconds for server to reply to us.
contimeout 5000 # Server has 4 seconds to answer us initually.
option httpclose # Disable Keepalive. Check your webservers KeepAlive value. Default to off in Apache2.#Finally, the below is the last piece of meat we need. Remember to use an IP not bound to port 80!
listen http_proxy ip:80 # Place your selected IP in the ip spot. IP and port number separated by colon.
balance roundrobin # Load Balancing algorithm
option httpchk # We want to see which servers aren’t working for us. Can also specify URIs for this.
option forwardfor # This sets X-Forwarded-For. Remember to load mod_rpaf or similar to gain anything from this.
## Define your servers to balance
server web1 ip:80 weight 1 maxconn 512 check # 512 max connections.
server web2 ip:80 weight 1 maxconn 512 check # 512 max connections on this server.
We should now be able to start HAProxy. You put the above in /etc/haproxy.cfg – right?
service haproxy start
Lets add HAProxy to start on boot.
chkconfig add haproxy
You should now have a simple configured load balancer. When you visit the selected IP in a web browser, you should be bounced in a roundrobin fashion from web1-web2.
We’d like to thank Rack911 for their assistance with this tutorial.
Latisys’s Chicago Facility Receives First Type II Audit
Web hosting solutions provider Latisys today announced its Chicago-area Tier III Data Center has successfully completed its first SAS 70 Type II audit. In addition to completing the Chicago facility audit, Latisys’ other colocation facilities (Denver, Irvine) were also audited and again confirmed to be SAS 70 Type II compliant. The Denver facility has been compliant since 2005, and the Irvine facility has been compliant since 2007.
Statement on Auditing Standards (SAS) No. 70, Service Organizations is a widely recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA). The SAS 70 audit independently verifies the validity and functionality of a data center’s control activities and processes. Achieving successful completion of a SAS 70 Type II audit confirms that Latisys’ Chicago data center has been through an in-depth audit to ensure adequate controls and safeguards are in place.
“Our customers – particularly those in heavily regulated sectors such as energy, financial, healthcare, insurance and pharmaceuticals – require assurance that the highest levels of internal controls and security are established and maintained,” said Evans Mullan, Chief Operating Officer, Latisys. “Investing the necessary resources to complete SAS 70 Type II audits for all three Latisys data centers reaffirms our commitment to safeguarding customers’ sensitive data and mission critical IT infrastructure with best practice processes.”
VPS.net and 10TB
About VPS.net and 10TB
UK2 has been a major player in the web hosting industry since 1998. UK-2 Group is accredited by ICANN (the Internet Corporation for Assigned Names and Numbers) to provide .com, .biz, .info, .net, .org, .jobs, .name and .pro gTLD’s. Some new features released by UK2 include a new UK based call centre, 24/7 live online support and new product packages to cater for a wide range of customers – those new to the web and even savvy developers.
Network
VPS.net and 10TB utilize a wide variety of datacenters.
Washington, DC
10TB’s Washington, DC datacenter utilizes eight bandwidth carriers:
- Comcast
- Time Warner
- Equinix
- Telefónica
- NTT America
- Level3
- Internap
- Global Crossing
Seattle
10TB’s Seattle datacenter utilizes eight bandwidth carriers to deliver an incredible 90 GBps of capacity:
- Global Crossing
- Internap
- Level3
- NTT America
- Qwest
- Comcast
- Time Warner
- SIX
Dallas
10TB’s Dallas datacenter uses nine tier 1 bandwidth providers:
- Global Crossing
- Internap
- Level3
- NTT America
- SAVVIS
- Comcast
- Time Warner
- Equinix
- Telefónica
Chicago
VPS.net’s Chicago location uses 2 carriers.
- Global Crossing
- nLayer
Utah
VPS.net’s Utah location uses primarily 3 carriers.
- Global Crossing
- XO
- Level3
Contact information
Sales department
Email: sales@midphase.com
Toll Free: +1.866-MIDPHASE
Support department
Email: support@midphase.com
Toll Free: +1.866-MIDPHASE
Sponsors
