Apache: Reducing Information Leaked Through The Headers

Apache by default announces all sorts of information about itself when you make a connection to it :-

$ lynx -head http://some-server-fqdn/
HTTP/1.1 302 Found                                                                                                                                                                                                                             
Date: Thu, 31 May 2018 12:18:22 GMT                                                                                                                                                                                                            
Server: Apache/2.2.15 (CentOS)                                                                                                                                                                                                                 
Location: https://t-oala-idp-01.iso.port.ac.uk/                                                                                                                                                                                                
Connection: close                                                                                                                                                                                                                              
Content-Type: text/html; charset=iso-8859-1        

This can be fixed by simply changing the ServerTokens Apache configuration option to “minimal”. This is found in either security.conf or in global.conf somewhere under /etc/apache2 (or elsewhere if Apache has been set up in a strange way).

Make the change and restart Apache in the usual way – apachectl configtest and then apachectl graceful.

Posted in Technical | Tagged , | Comments Off on Apache: Reducing Information Leaked Through The Headers

Apache: Disabling Directory Indexes

One of the features of Apache that can cause security issues (or at least those who audit security issues may complain about it) is the ability to produce a file listing of a directory if there is no index page in place :-

This can be turned off by removing the Apache option “Indexes”; search the Apache configuration directory (assumed to be /etc/apache2) for a file containing that word :-

# find . -type f -exec grep -li Indexes {} \;

Check each file for an active Indexes option :-

Options Indexes FollowSymLinks

And remove the “Indexes”.

Restart Apache in the usual way (apachectl configtest and if that comes back Okay, then apachectl graceful).

Posted in Technical | Tagged , | Comments Off on Apache: Disabling Directory Indexes

Apache: Disable the ETag Header

By default, the Apache web server has an information disclosure vulnerability where the ETag header shows information about the file containing the object in question. This can contain an “i-node” value which in combination with the use of NFS can permit certain forms of attack.

Whilst not especially serious, it is worth disabling this header given how easy it is to do (and the security people will stop complaining about it). Simply add :-

FileETag None

to an Apache configuration file and restart in the usual way. You can make this change in almost any of the files commonly found under /etc/apache2 but two possible locations where it is ready to go are :-

  1. For Ubuntu/Debian-derived Linux systems, look at /etc/apache2/conf-enabled/security.conf (it is present but commented out)
  2. For SLES-derived Linux systems, add the line to /etc/apache2/conf.d/local.conf

Of course with any Apache change you will need to restart it (and preferably in a safe manner) :-

✓ root@pm-log2# apachectl configtest
Syntax OK
✓ root@pm-log2# apachectl graceful  


Posted in Technical | Tagged , | Comments Off on Apache: Disable the ETag Header

Apache: Disabling TRACK and TRACE Methods

By default Apache supports a number of HTTP methods in addition to the ones we normally use – GET (to get objects) and PUSH (to push form data although you can send form data with GET too). These additional methods are mostly harmless, but two do leak information about a server that you may not want an attacker to know.

Fortunately turning this off is a single line configuration change; simply add the following to one of the Apache configuration files :-

  TraceEnable off

And you will be protected (and won’t receive any more nasty messages about that bit of configuration).

You can make this change in almost any of the files commonly found under /etc/apache2 but two possible locations where it is ready to go are :-

  1. For Ubuntu/Debian-derived Linux systems, look at /etc/apache2/conf-enabled/security.conf (it is present but commented out)
  2. For SLES-derived Linux systems, add the line to /etc/apache2/conf.d/local.conf

Of course with any Apache change you will need to restart it (and preferably in a safe manner) :-

✓ root@pm-log2# apachectl configtest
Syntax OK
✓ root@pm-log2# apachectl graceful  


Posted in Technical | Tagged , | Comments Off on Apache: Disabling TRACK and TRACE Methods

Apache: Blocking “Dangerous” Files

There are all sorts of “dangerous” files that can appear within a web server’s document root; some are merely potentially dangerous but some can be genuinely dangerous. For example, if someone uses an editor to change a .php file, it is possible that a backup file for that script will be created within the document root called something.php~, and because this isn’t a genuine php file, it won’t be interpreted by php so the source code of your php script could be visible publicly :-

This is not something you want to see!

To protect against a whole set of similar attacks, blocking access to certain file “patterns” is a sensible precaution. The following can be added to a .htaccess file or to the main Apache configuration file (preferred) :-

<FilesMatch "(^\.htaccess|\.sql$|\.svn$|\.git$|\.DS_Store|.*~$|\.old$|\.bak$)" >
  Order allow,deny
  Deny from all

The contents of the “FilesMatch” directive is effectively a list of regular expressions alternatives (grouped by enclosing in “(” and “)” and separated with “|” = standard syntax). For the benefit of documentation the individual clauses are :-

  1. “\.htaccess” (files containing the string “.htaccess”) – blocks access to Apache options file.
  2. “\.sql$” (files ending in “.sql”) – blocks access to SQL files.
  3. “\.git$” (files ending in “.git”) – blocks access to git repositories which are contained within directories named “.git”.
  4. “\.svn$” (files ending in “.svn”) – blocks access to svn repositories as above.
  5. “\.DS_Store” (files containing the string “.DS_Store”) – blocks access to OSX “droppings” left in directories.
  6. “.*~$” (files ending in “~”) – blocks access to emacs style editor backups.
  7. “.*old$” (files ending in “old”) – blocks access to a typical backup file.
  8. “.*bak$” (files ending in “bak”) – blocks access to vim style editor backups.

The configuration can be added to any Apache configuration file in the global context (rather than specific to a particular virtual server), but suggested places are :-

  1. For Ubuntu/Debian-derived distributions: /etc/apache2/apache2.conf (at the end of the file).
  2. For SLES-based servers, /etc/apache2/conf.d/local.conf

Once the change has been made, check the configuration with apachectl configtest. Providing that returns no errors, restart Apache gracefully with apachectl graceful.

Posted in Technical | Tagged , | Comments Off on Apache: Blocking “Dangerous” Files

Processor Bugs: Meltdown and Spectre

There has been lots of stories relating to two new severe security vulnerabilities (one of which is in every Intel processor for over a decade); the trail of stories starts here. The details of the vulnerability are very highly technical so this post will concentrate on the less technical aspects.

As the original papers highlight, this is a result of a decades long policy across the industry of increasing complexity in pursuit of performance over security.

What Is Vulnerable?

For Meltdown, practically everything with an Intel processor; it is known that patches for Linux and Windows are being prepared. macOS was patched in December (if you have patched recently!).

Information on the vulnerability of other processors to Meltdown is a bit varied at present. It may be that AMD processors are vulnerable under certain conditions (although AMD have claimed that they are not vulnerable).

It is probable that Spectre is effective on rather more processors – AMD, and possibly some ARM processors (smartphones).

What Is The Effect?

In short, this is unknown. Technically Meltdown allows an attacker to access parts of kernel memory from any user process. This by itself sounds not so bad, but it allows an attacker to defeat defenses that have made whole classes of old attacks no longer viable. Essentially in combination with other attacks, the machine can be totally compromised.

In the case of Spectre, the effect is to be able to use the same sort of side-channel to view data from other processes address spaces, and in addition to escape “sandbox restrictions”. This means data leakage.

However this requires an attacker to be in control of data that controls the execution path through the victim’s code. Which is generically a hard thing to do, although in some cases (browsers) it is likely to be quite easy. Expect browser (and other application) patches to be released shortly … and apply them!

What Does The Meltdown Patch Do?

With the rumour that the the Meltdown patch causes a performance hit of 5-30%, there is some concern over it.

Technically the Meltdown patch is a work-around for the problem – it moves the kernel address space out of the user address space. Every time a system call is made, the processor has to reload the memory management unit, which takes time. Thus the performance hit.

How exactly this will effect performance remains unknown to a certain extent. Essentially applications that make very heavy use of system calls will notice a performance hit, and those that don’t will probably not notice a hit. In terms of desktop applications, it is likely that the web browser will be hit, but most other applications are likely to be unaffected.

It is likely that servers will notice the effect the most, and it is likely that only on heavily loaded servers will the effect be noticeable.


This is a serious set of vulnerabilities, and there is a significant risk of those vulnerabilities being used. In addition the mitigation for Intel processors has a significant risk of causing a performance issue.

However there is no reason to panic – patches are currently being prepared for release or have been released already.

There are many sources of information on these vulnerabilities being published; not all of which can be assumed to be totally correct (this posting included).

Links to further information :-

Posted in Technical | Tagged , | Comments Off on Processor Bugs: Meltdown and Spectre

The New Mirai

According to one news report, a new version of Mirai has recently been released causing an increase in the number of scans against port 2323 and port 23. According to our firewall logs, the number of scans against tcp/2323 has increased over the current month :-

There is indeed a big increase on the 22nd when the new malware was released, but interestingly enough, there is also a big increase in the week before, indicating that perhaps the new Mirai variant was released earlier than the researchers identified.

As a comparison, the same graph for tcp/22 – ssh, and a very heavily probed port looks like :-

Posted in Active Attacks, Technical | Tagged , | Comments Off on The New Mirai

Serious OSX Vulnerability – Get Root Without A Password

Apple’s latest version of their OSX (or macOS) operating system – High Sierra – has been found to have a serious vulnerability that allows anyone with access to the device to have full administrative access (“root”) without a password.

On any vulnerable device, you can login as the root user without a password from the lock screen (or login screen). A software update to fix the problem is being prepared, but it would be very sensible to apply a fix in the short-term.

To fix the problem, simply set a password for the root user; start a Terminal and from the command-line, run the following command :-

sudo passwd root
Password: {Enter your own password here}
Changing password for root.
New password: {Enter root's new password}
Retype new password: {Enter it again}

You should probably store the new password for the root user in an appropriate password store (Keepass, or KeepassX), although you will probably never use it.

Links for further information :-

The vulnerability is an interesting one in a sense – in theory there is no need for the root user to have a password as it is not intended for direct use, but if the account accidentally becomes enabled then it becomes a dangerous (and easily exploitable) security hole. To be safe, Apple should not only have disabled the root user, but also generated a random password for that account.

The vulnerability can be exploited locally (with access to the keyboard) and in some instances remotely.

Posted in Active Attacks, Passwords | Tagged , , , , | Comments Off on Serious OSX Vulnerability – Get Root Without A Password

BadRabbit Up And Running

According to reports, a new ransomware infection dubbed “BadRabbit” is spreading in Russia and Ukraine, and one or two other places further afield. Early indications are that this is not going to become a really nasty problem, but that could be wrong.

The infection spreads via one of three methods known :-

  1. Via email promising an update to Adobe Flash player, which is a widely exploited piece of software that has had many updates distributed although not in this way.
  2. By scanning for and exploiting an old vulnerability in Microsoft’s file sharing protocol (“EternalBlue”).
  3. By making use of MiniKatz to break in with compromised credentials.

Of the methods, the last is the most serious as it would allow the infection to spread within the University. But the most likely method to break in from outside the University is the first method.

Once a machine is infected, it will immediately try to spread itself, and infect local files.

In terms of genuine measurements of how bad this problem is, the firewall is blocking incoming traffic to the Microsoft file sharing service, and the sum of each day’s block over the whole of October amounts to about 15-25 million per day. Whilst there is some increase in the last week, there is nothing to indicate that BadRabbit is having a significant effect on the network.

Posted in Active Attacks, Malware | Tagged , | Comments Off on BadRabbit Up And Running

KRACKing Wireless

The latest big security exploit is a mechanism by which WPA2 secured wireless networks can be compromised to disclose previously encrypted traffic in the clear, and to insert malicious traffic. The original web site announcing the vulnerability can be found here with a translation into more ordinary language here.

Although a serious vulnerability, there are several elements that make this attack somewhat harder to carry out :-

  1. It is a very technical attack that has not been “bundled” into a ready to use form.
  2. The attack involves creating a “fake” access point with the same name as the network under attack. This implies physical proximity, although with wireless networks that can be a great deal further than you imagine – an attacker able to use this vulnerability is quite likely to be more sophisticated than usual, and have access to specialist wireless equipment that can extend the range of wireless networks.
  3. Whilst all WPA2 networks are vulnerable, impersonating a enterprise wireless network is somewhat more complex than impersonating a personal/home wireless network. This means that the EDUROAM wireless network may be somewhat safer than your home network.

Having said that, this vulnerability is harder to fix than usual and is likely to remain around long enough that it will be regularly used. Fixing just the wireless access points isn’t sufficient; it is necessary to fix those and the client devices connecting to the network. And in many cases (IoT devices and/or older Android phones), the client devices will never be fixed.


To prevent this attack there are a number of things you can do yourself :-

  1. Use a VPN. The University runs a VPN service, and any traffic that goes over the VPN is not subject to this attack. To put it another way, if you have the VPN turned on, an attacker can be busy compromising your wireless network as much as she likes, but your traffic will be safe. We recommend the use of a VPN when working whilst travelling anyway.
  2. Upgrade your wireless router’s firmware as soon as possible. We are. If your wireless router is supplied by your ISP, nag your ISP about an update. Otherwise check with the manufacturer for a firmware update.
  3. Upgrade all your client wireless devices – laptops, phones, and all those “IoT” devices that you have.

Bear in mind that advice elsewhere suggests using tethering; if you set up your phone as a mobile wireless hot-spot then you may still be vulnerable if one of the phone or the connecting device has not been updated.

Posted in Technical | Tagged , , , | Comments Off on KRACKing Wireless