Harden Apache web servers with some of these quick tips

Harden Apache web servers with some of  these quick tips


Apache is one of the most widely used web servers on the planet… and with good reason. Not only is it incredibly powerful and flexible, it’s also free. That cost to feature ratio makes for an attractive package for the DIY(Do-It-Yourself) crowd.


Apache is also really secure out of the box. But for those who live on the edge of paranoia, it’s nice to know there are ways to make an already secure web server even more secure. Here are some tips that you can employ quickly to harden your already running Apache server.


Hide the banner
Apache announces itself with the help of a banner file. By announcing itself, this allows hackers to more easily target attacks. So instead of blindly announcing what piece of software is handing out content, let’s obfuscate it by turning off SecuritySignature.

1. Open a terminal window.
2. Open the Apache configuration file (in Ubuntu this is /etc/apache/apache2.conf).
3. Search for a line containing ServerSignature. If found, set to off.
4. Search for ServerTokens. If found, set to ProductOnly.

Now, restart Apache with the command /etc/init.d/apache restart. Apache is no longer broadcasting itself as the web server. If you want to test this, issue the command curl -I http://DOMAIN, where DOMAIN is the domain serving up your website.




Deny All
The best way to secure access to Apache is to deny access to everything and everyone and then allow access only where needed. This is done by modifying the directory containers; specifically, you’ll want to start with the main <Directory /> container and make sure it looks like:


<Directory />
Order deny,allow
Deny from all
</Directory>


Now create new containers for the directories that you need to give access to. These can look like:


<Directory "/var/www/XXX">
Order allow,deny
Allow from all
</Directory>


where XXX is a specific directory that must be accessed. Once you’ve done this, restart Apache and enjoy a stronger web server.




Trace HTTP requests
Trace HTTP requests are another possible security issue. These requests echo back all received information, which can be used to trick Apache into printing HTTP cookies and hijacking HTTP sessions. This is known as the Cross Site Scripting attack (or XSS).


In order to disable this feature, set the TraceEnable directive in /etc/apache/apache2.conf to off. After you change the setting and the file saved, restart Apache, and you should be good to go.




Disable Directory Indexing
The Directory Indexing feature prints out the contents of directories (this is especially true where there is no index.html or index.php file in the directory). On a Ubuntu server, there are enabled modules in the /etc/apache/mods-enabled directory. The modules to be removed are: autoindex.load and autoindex.conf. You can remove those files with the following commands:


sudo rm -rf /etc/apache2/mods-enabled/autoindex.load
sudo rm -rf /etc/apache2/mods-enabled/autoindex.conf


For other distributions look for the “index” option in the particular directory container and remove the option. A directory container starts with <Directory> and ends with </Directory>. Within those tags you will find the line: Options index FollowSymLinks… . Just remove the “index” option, save the file, and restart Apache.




Disable WebDAV
WebDAV is a popular protocol that allows for the sharing of data (such as calendars) and allows for web-based email. If these features are not needed, I highly recommend disabling this protocol from your Apache server. To do this, issue the following commands and then restart Apache:


sudo rm /etc/apache2/mods-enabled/dav.load
sudo rm /etc/apache2/mods-enabled/dav_fs.conf
sudo rm /etc/apache2/mods-enabled/dav_fs.load
sudo rm /etc/apache2/mods-enabled/dav_lock.load




Use SSL(Security Socket Layer)
I won’t go into the setting up and configuring of SSL, but when you need secure http, you must use SSL. 




Keep up to date
When an update is released for Apache, it is often for security purposes. Keep your eye on updates and make sure that Apache installation is as up to date as possible. This is critical Unlike the proprietary world, the open source world tends to find and fix bugs quickly, so shortly after a bug is found, you can bet the developers will be working on a fix right away. On a piece of software as important as Apache, those bug fixes will be rushed out to the repositories much faster than, say, a piece of desktop software.




Watch your log files
In the /var/log/apache2 directory, these logs are available: access.log and error.log. These logs, in particular, are always important to watch. If there seems to be an issue with Apache, I like to use the tail command on either of these log files (using the command sudo tail -f /var/log/apache2/access.log) to watch the logs as events are recorded.

*****************************

Five tips for improving Linux Server performance

Five tips for improving Linux Server performance


Most Linux server distributions, out of the box, will outperform proprietary systems. But that doesn’t mean there aren’t things you can do to improve the performance of your server. In fact, there are always ways to eke out a bit more performance, no matter the operating system. But in this article, I want to speak directly to boosting the performance of the Linux server.


1) Kill services that are not needed
This particular trick will go a long way toward improving the performance of your server. With some Linux servers, certain services seem to want to run by default, regardless of whether they are being used. If that is the case, make sure those services are not running. For example: Samba. If you’re not serving files to Windows or other platforms, kill the Samba daemon. The same holds true for many other services. Your best bet is to decide what your server IS doing and then go through and kill what it doesn’t need. This will also have the benefit of making your server more secure.


2) Pay close attention to SELinux
SELinux is an often misunderstood tool. Its purpose is to enhance the security of a server or desktop. It is there for a reason and should not be stopped altogether. It should, however, be configured to meet the specific needs of your server. SELinux is quite powerful, and if it’s improperly configured, that power can rob your system of much-needed CPU cycles and slow down data throughput. If your distribution uses SELinux, be sure you have a strong understanding of it so you can fine-tune it to meet your needs.


3) Compile software from source
This might seem a bit counterintuitive, but when you compile your software from source, you can often run the compilation with flags and arguments highly specific to your hardware and/or needs. This goes for software that runs services and, of course, the kernel itself. The more hardware/need-specific you make your software, the more performance you will gain. Of course, this does require some experience with installing from source. I would recommend starting with this method on a test machine to get used to how the software can be better tailored to fit your situation.


4) Keep updated
This is insanely important from both a performance and a security standpoint. I see it so often: administrators ignoring updates for fear the updates will break their currently running software. If you are one of those admins, I recommend having a testbed server that mirrors your production server. With that testbed in place, you can run the updates prior to running them on the production machine so you will know precisely what could go wrong. From my experience, though, it’s a rare occasion that something does go wrong with a Linux software update.


5) Can the GUI
If you really need as much performance as possible, you can do one of two things: Use a GUI-less server installation or run the server in run level 3. If you need the GUI to get the machine up and running well, you won’t need that GUI running all the time. So instead of running GDM or KDM (and stealing resources), edit the run level so that the boot process stops at run level 3 - console login. This will not only save CPU cycles and memory, it will also circumvent the possible security issues of having GUIs running on your precious server. Each distribution edits the run level differently, so make sure you understand how to make this change before you attempt it.

*************************

The Pros and Cons of Tower, Rack, and Blade Servers

The Pros and Cons of Tower, Rack, and Blade Servers

There are three main choices when it comes to buying a new server: tower, rack, or blade. Here are some of the pros and cons about each kind of server.

Tower servers :-

Tower Server

Tower servers seem dated and look more like desktops than servers, but these servers can pack a punch. In general, if you have a lot of servers, you’re probably not using a bunch of tower servers, because they can take up a lot of space and are tough to physically manage since you can’t easily stack them on one another. In some cases as organizations grow and move to rack servers, conversion kits can be purchased to turn a tower server into a rack-mount server.

As implied, tower servers are probably found more often in smaller environments than anywhere else, although you might find them in point solutions in larger places.

Tower servers are generally on the lower end price-wise, although they can expand pretty decently and become really expensive.Tower servers take up a lot of space and require individual monitors, keyboards, and mice or a keyboard, video, mouse (KVM) switch that allows them to be managed with a single set of equipment. In addition, cabling can be no fun, especially if you have a lot of network adapters and other I/O needs. You’ll have cables everywhere.


Rack servers :-

Rack Server

If you run a data center of any reasonable size, you’ve probably used a lot of industry standard 19″ wide rack servers. Sized in Us (which is a single 1.75″ rack unit), rack servers can range from 1U “pizza boxes” to 5U, 8U, and more. In general, the bigger the server, the more expansion opportunities are available.

Rack servers are extremely common and make their home inside these racks along with other critical data center equipment such as backup batteries, switches, and storage arrays. Rack servers make it easy to keep things neat and orderly since most racks include cable management of some kind. However, rack servers don’t really simplify the cabling morass since you still need a lot of cabling to make everything work — it’s just neater. I once worked in a data center in which I had to deploy 42 2U Dell servers into three racks. Each server had to have dual power cables, keyboard, video, and mouse cables and six (yes, six) network cables (six colors with each color denoting a specific network). It was a tough task to keep the cabling under control, to put it mildly. Because everything was racked, there was built-in cable management that made this easier.

Like tower servers, rack servers often need KVM capability in order to be managed, although some organizations simply push a monitor cart around and connect to video and USB ports on the front of the server so that they don’t need to worry about KVM.Rack servers are very expandable; some include 12 or more disks right in the chassis and support for four or more processors, each with multiple cores. In addition, many rack servers support large amounts of RAM, so these devices can be computing powerhouses.


Blade servers :-

Blade Server

There was a day when buying individual blade servers meant trading expansion possibilities for compactness. Although this is still true to some extent, today’s blade servers pack quite a wallop. I recently purchased a half-height Dell M610 blade server with 96 GB of RAM and two six-core processors.

There is still some truth to the fact that blade servers have expansion challenges when compared to the tower and rack-based options. For example, most tower servers have pretty significant expansion options when it comes to PCI/PCI Express slots and more disk drives. Many blade servers are limited to two to four internal hard drives, although organizations that use blade servers are likely to have shared storage of some kind backing the blade system.

Further, when it comes to I/O expansion options, blade servers are a bit limited by their lack of expansion slots. Some blade servers boast PCI or PCI Express expansion slots, but for most blade servers, expansion is achieved through the use of specially designed expansion cards. In my case, the Dell M600 and M610 blades have three mezzanines. The first mezzanine consists of dual Gigabit Ethernet adapters. The remaining mezzanines are populated based on organizational need. The blade server doesn’t have quite the I/O selection of other server form factors, it’s no slouch, either.

When raw computing power and server density is the key drive, blade servers meet the need. For example, I have a 10U Dell M1000e blade chassis that can support up to 16 servers. So, each server uses the equivalent of 0.625U of rack space. On top of that, the blade chassis holds four gigabit Ethernet switches and two Fibre Channel switches, so there is additional rack space savings since I don’t need to rack mount these devices to support different connectivity options. In addition, the blade chassis has a built-in KVM switch so I don’t need to buy a third party and cable it up.

Speaking of cabling, a blade environment generally has much less of it than tower or rack environments since a lot of the connectivity is handled internally. You’ll end up with a neater server room as a result.

Another point is adding a new server consists of simply sliding it into an available slot in the chassis. There is no need to rack a new server and deal with a bunch of new cabling. This small size makes heat dissipation a challenge. Blade chassis can put out a lot of heat.

From a cost perspective, blade servers require some initial infrastructure, such as the chassis, so the upfront cost is often higher than for servers of other types.


Bottom line :-

If you need one or two servers, a tower solution probably makes sense. If you need three to 24 servers or massive scalability, then rack servers are for you. When you go need more than 24 servers, I advise you to consider a blade solution to meet your data center needs.

*******************************