Archive for the ‘encryption’ Category
Fixing the “Heartbleed” OpenSSL Bug: A Tutorial for Sys Admins
The following article is a guest post from Toptal. Toptal is an elite network of freelancers that enables businesses to connect with the top 3% of software engineers and designers in the world.
So what exactly is the bug anyway?
Here’s a very quick rundown:
A potentially critical problem has surfaced in the widely used OpenSSL cryptographic library. It is nicknamed “Heartbleed” because the vulnerability exists in the “heartbeat extension” (RFC6520) to the Transport Layer Security (TLS) and it is a memory leak (“bleed”) issue. User passwords and other important data may have been compromised on any site affected by the vulnerability.
The vulnerability is particularly dangerous for two reasons:
- Potentially critical data is leaked.
- The attack leaves no trace.
The affected OpenSSL versions are 1.0.1 through 1.0.1f, 1.0.2-beta, and 1.0.2-beta1.
Who is affected by the problem?
Short answer: Anyone and everyone who uses these versions of OpenSSL.
And that’s a LOT of companies and a LOT of people.
Before we get into our Heartbleed tutorial, here’s just a brief sampling of major companies and websites that are known to have been affected and that needed to patch their sites: Gmail, Yahoo Mail, Intuit TurboTax, USAA, Dropbox, Flickr, Instagram, Pinterest, SoundCloud, Tumblr, GitHub, GoDaddy, Boingo Wireless, and many more.
Many, many corporate websites, of companies of all sizes, have been (or still need to be!) patched to fix the Heartbleed vulnerability.
The vulnerability has existed since December 31, 2011, with OpenSSL being used by about 66% of Internet hosts.
As a user, chances are that sites you frequent regularly are affected and that your data may have been compromised. As a developer or sys admin, sites or servers you’re responsible for are likely to have been affected as well.
So what do I need to do to protect myself if I use any of the affected sites?
The main thing you should do immediately is to change your passwords for any of the affected sites for which you have a login account.
And what do I need to do to fix and protect against Heartbleed if I’m the sys admin for a site that uses OpenSSL?
If you’re using OpenSSL 1.0.1, do one of the following immediately:
- Upgrade to OpenSSL 1.0.1g, or
- Recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
If you’re using OpenSSL 1.0.2, the vulnerability will be fixed in 1.0.2-beta2 but you can’t wait for that. In the interim, do one of the following immediately:
- Revert to OpenSSL 1.0.1g, or
- Recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
Most distributions (e.g., Ubuntu, Fedora, Debian, Arch Linux) have upgraded their packages already. In cases like Gentoo, you can upgrade to a patched ebuild.
Once you’ve upgraded (or recompiled) and have established a secure version on your server:
- Be sure to restart all potentially affected processes. Major daemons affected by the bug include Apache, Nginx, OpenVPN, and sshd; basically anything and everything linked against
libssl
. (Note that a restart of these daemons should be sufficient. There should be no need to rebuild these binaries since they are dynamically linked with the openssl libraries.) - Verify that you are no longer vulnerable using tools like this online test or this tool on GitHub or this tool on Pastebin.
If your infrastructure was vulnerable, there are Heartbleed tutorial steps that you can and should take. A useful list of such mitigations is available here.
More gory Heartbleed details, for those who are interested…
As explained in the GitHub commit for the fix, a missing bounds check in the handling of the TLS heartbeat extension could be exploited to reveal up to 64k of memory to a connected client or server.
While the exposed memory could potentially just be garbage, it could just as easily turn out to be extremely valuable to a malicious attacker.
Here’s how the Heartbleed vulnerability works: An attacker provides the payload as well as the payload length. However, no validation is done to confirm that the payload length was actually provided by the attacker. If the payload length was not provided, an out-of-bounds read occurs, which in turn leaks process memory from the heap.
Leaking previous request headers can be a very serious security problem. Specifically, a prior user’s login post data might still be available with their username, password, and cookies, all of which can then be exposed and exploited. Moreover, although private key leakage through Heartbleed was initially deemed to be unlikely, it has been verified that private SSL keys can be stolen by exploiting this vulnerability.
The vulnerability is also made possible due to OpenSSL’s silly use of a malloc() cache. By wrapping away libc
functions and not actually freeing memory, the exploitation countermeasures in libc
are never given the chance to kick in and render the bug useless.
Additional details on these ways to fix Heartbleed are available here and here.
And, for what it’s worth, here’s a more amusing perspective.
Kudos to the discoverer, Neel Mehta of Google Security, as well as Adam Langley and Bodo Moeller who promptly provided the patch and helped sys admins determine how to fix Heartbleed. I also encourage you to educate yourself on some of the other common web security vulnerabilities to avoid issues in the future.
The Role of WebRTC Technology In Online Security
WebRTC technology is rather new (spearheaded by Google in 2012 through the World Wide Web Consortium). It is a free project that provides browsers with Real-Time Communications. The technology is now widely used in live help customer support solutions, webinar platforms, chat rooms for dating, etc. But there are too little solutions for enhanced safety. It’s weird. Since this technology offers great opportunities in this field.
WebRTC opens great opportunities in secure communications online
In the case of WebRTC technology to create a communication channel between subscribers is used Peer to Peer method. At the same time, there is no data transfer to any server. It is a great advantage. This ensures the confidentiality of transmitted information.
The majority of modern communication services works through central server. It means that all history is stored on the server and third parties can get access to them.
Using WebRTC technology security provider Privatoria.net developed a solution for confidential communication online in 2013. The main difference is the absence of data transfer to the server. Only the subscribers’ web browsers are used.
Chat service provides users with an opportunity to exchange messages by establishing a direct connection between their browsers and uses Peer to Peer method to communicate online.
To create a communication channel between subscribers it is enough to get a one-time key, and pass it to the called subscriber by any means of communication available. When the communication session is over, the history is deleted and the browser is closed, all correspondence between the subscribers disappears from the system.
In such case, no one can gain access to the content of communications.
A user will benefit from:
- Secure text messaging
- Secure Voice Call
- Secure Video Call
- Secure Data Transfer
As WebRTC supports not all browsers, Secure Chat solution works only in Google Chrome, Opera and Mozilla. At now developers are working on beta application for Android which will be available in Google Play Market in the nearest month.
Therefore, it is good chance for all us today to communicate securely online.
Data and Web Security in Business
Not all businesses are aware of just how much of their data is potentially at risk within their own systems and even their website; there simply isn’t the education in place to identify the flaws in one’s system before it’s too late in most cases, which results in compromised data, stolen data, loss of trust from customers and potentially a loss of funds or profits for the business in question; usually because of issues that could have easily been avoided.
First of all you need to secure the internal workings of your business; which means users and data storage. One of the biggest threats to your computer and data security systems is actually the people that you give access to those systems; the human element is less predictable so be sure to take the necessary precautions that will prevent or limit damages should an employee choose to act maliciously. Start by ensuring logins are required and are unique to each user, this allows you to control exactly what each person has access to, and means that it is easier to trace who is responsible if damage is caused. You should also be very careful about providing permissions to these users; consider what they absolutely must have access to, and why, and consider whether or not they really need access to everything they can access. Limitations are the first step towards protection.
Once you have this much protected you can start to think about how to avoid unauthorised access; password protecting everything is a good start, and encrypting sensitive information can be a fantastic way to avoid giving away data that is particularly valuable to your company. These are generally very easy systems to implement, and most security organisations you may choose to work with will help you to set up systems for encryption, data recovery, remote destruction (allowing you to delete data on a stolen device), as well as other aspects of data protections that can be very important to your business. These are important if your business handles a great deal of sensitive information, and of course if that is the case and security is of particularly importance you will want to get a security firm to help you protect it, however in a lot of cases your own IT department can set up the encryption, passwords, firewalls and defences needed to protect basic levels of data against reasonably tough attacks.
Of course your online systems can require something a little different in order to keep them safe, and this is true of your website as well as any online content management, project management or other systems you might be using in the day to day running of your business. Again it is important that everything is password protected to keep things safe and secure as far as your users and their access levels are concerned, but you should also ensure that the development of the websites and tools are done with a certain level of security in mind. There are some rules to this, but in general it isn’t too difficult if you can already develop a website.
No WordPress. If you want a secure website to handle lots of valuable data then WordPress isn’t for you, no matter how easy you think it makes your life. The problem with WordPress is that literally anyone can get it, and they all get the same version. Within a short time the vulnerabilities of that version will have been discovered and likely shared among hackers and other such people, meaning that you can either update or remain vulnerable – your only hope is that WordPress and you update often enough to stay one step ahead of the hackers. This is an issue that exists with a variety of similar platforms and would be difficult to keep yourself secure using these platforms – the best option is to use a secure platform and your own web development team or company.
The variations in the programming that come from using your own team help to create diversity online, which means that it is much harder for hackers and malicious users to find the ways into your system; thus keeping you protected for longer. Of course even with your own website you are likely to be working with systems like Magento for database integration and content management, which will need to be updated every so often but are considerably more secure than systems like WordPress, and you will have to keep certificates up to date, particularly your SSL certificates.
Kate Critchlow is a freelance writer with a passionate interest for technology covering everything from web development to IT security services.
Hardening guide for NGINX 1.5.8 on RedHat 6.4 (64bit edition)
This document explains the process of installation, configuration and hardening of NGINX server from source files, based on CentOS 6.4 default installation (IPTables and SELinux enabled by default), including support for TLS v1.2 and protection from BEAST attack and CRIME attack
Some of the features explained in this document are supported by only some of the Internet browsers:
- X-Frame-Options – Minimum browser support: IE 8.0, Firefox 3.6.9, Chrome 4.1.249, Opera 10.50, Safari 4.0
- TLS 1.2 – Minimum browser support: IE 8.0 on Windows 7/8 (Need to be enabled by default), Firefox 24.0 (Need to be enabled by default), Chrome 30, Opera 17, Safari 5.0
- Installation Phase
- Login to the server using Root account
- Install pre-requirement packages:
yum install policycoreutils-python-* -y
yum install setools-libs-* -y
yum install libcgroup-* -y
yum install audit-libs-python-* -y
yum install libsemanage-python-* -y
yum install setools-libs-python-* -y
yum install gcc* -y - Create a new account:
groupadd nginx
useradd -g nginx -d /dev/null -s /sbin/nologin nginx - Upgrade the Openssl build:
rpm -ivh --nosignature http://rpm.axivo.com/redhat/axivo-release-6-1.noarch.rpm
yum --enablerepo=axivo update openssl -y - Download Openssl source files:
cd /opt
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz - Extract Openssl source files:
tar zxvf /opt/openssl-1.0.1e.tar.gz -C /opt
- Remove Openssl source file:
rm -rf /opt/openssl-1.0.1e.tar.gz
- Download PCRE source file into /tmp, from:
http://sourceforge.net/projects/pcre/files/pcre/
- Compile PCRE from source file:
tar zxvf /tmp/pcre-8.34.tar.gz -C /tmp
mv /tmp/pcre-8.34 /usr/local/pcre
cd /usr/local/pcre
./configure --prefix=/usr/local/pcre
make
make install - Remove PCRE package:
rm -rf /tmp/pcre-8.34.tar.gz
- Download Nginx 1.5.8:
cd /tmp
wget http://nginx.org/download/nginx-1.5.8.tar.gz - Extract the nginx-1.5.8.tar.gz file:
tar -zxvf /tmp/nginx-1.5.8.tar.gz -C /tmp
- Move to the Nginx source folder:
cd /tmp/nginx-1.5.8
- Edit using VI, the file
/tmp/nginx-1.5.8/src/http/ngx_http_header_filter_module.c and replace the following section, from:
static char ngx_http_server_string[] = "Server: nginx" CRLF;
To:
static char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;
static char ngx_http_server_string[] = "Server: Secure Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Secure Web Server" NGINX_VER CRLF; - Run the commands bellow to compile the Nginx environment:
./configure --with-openssl=/opt/openssl-1.0.1e --with-http_ssl_module --without-http_autoindex_module --without-http_ssi_module --with-pcre=/usr/local/pcre
Note: The command above should be written as one line.
make
make install - Remove the Nginx source files:
cd /
rm -rf /tmp/nginx-1.5.8
rm -f /tmp/nginx-1.5.8.tar.gz - Remove Default Content
rm -rf /usr/local/nginx/html
- Updating Ownership and Permissions on Nginx folders:
chown -R root:root /usr/local/nginx
chmod 750 /usr/local/nginx/sbin/nginx
chmod -R 640 /usr/local/nginx/conf
chmod -R 770 /usr/local/nginx/logs - Create folder for the web content:
mkdir -p /www
- Updating Ownership and Permissions on the web content folder:
chown -R root /www
chmod -R 775 /www - Edit using VI the file /usr/local/nginx/conf/nginx.conf and change the following settings:
From:
#user nobody;
To:
user nginx nginx;
From:
#error_log logs/error.log notice;
To:
error_log logs/error.log notice;
From:
server_name localhost;
To:
server_name Server_FQDN;
Note: Replace Server_FQDN with the actual server DNS name.From:
root html;
To:
root /www;
- Add the following sections to the end of the /usr/local/nginx/conf/nginx.conf file (before the last “}” character):
## turn off nginx version number ##
server_tokens off;
## Size Limits & Buffer Overflows ##
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 2k;
## Timeouts ##
client_body_timeout 10;
client_header_timeout 10;
send_timeout 10; - Create using VI, the file /etc/init.d/nginx with the following content:
#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig: - 85 15
# description: Nginx is an HTTP(S) server, HTTP(S) reverse \
# proxy and IMAP/POP3 proxy server
# processname: nginx
# config: /usr/local/nginx/conf/nginx.conf
# config: /etc/sysconfig/nginx
# pidfile: /var/run/nginx.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0nginx="/usr/local/nginx/sbin/nginx"
prog=$(basename $nginx)NGINX_CONF_FILE="/usr/local/nginx/conf/nginx.conf"
[ -f /etc/sysconfig/nginx ] && . /etc/sysconfig/nginx
lockfile=/var/lock/subsys/nginx
start() {
[ -x $nginx ] || exit 5
[ -f $NGINX_CONF_FILE ] || exit 6
echo -n $"Starting $prog: "
daemon $nginx -c $NGINX_CONF_FILE
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}stop() {
echo -n $"Stopping $prog: "
killproc $prog -QUIT
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}restart() {
configtest || return $?
stop
sleep 1
start
}reload() {
configtest || return $?
echo -n $"Reloading $prog: "
killproc $nginx -HUP
RETVAL=$?
echo
}force_reload() {
restart
}configtest() {
$nginx -t -c $NGINX_CONF_FILE
}rh_status() {
status $prog
}rh_status_q() {
rh_status >/dev/null 2>&1
}case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart|configtest)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force_reload
;;
status)
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload|configtest}"
exit 2
esac - Change the permissions of the file /etc/init.d/nginx
chmod +x /etc/init.d/nginx
- To start Nginx service at server start-up, run the command:
chkconfig nginx on
- To manually start the Nginx service, use the command:
/etc/init.d/nginx start
- Configure IPTables:
service iptables stop
iptables -P INPUT DROPiptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- Allow SSH access from Internal segment (i.e. 10.0.0.0/8)
iptables -A INPUT -m state --state NEW -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
Note: Replace 10.0.0.0/8 with the internal segment and subnet mask. - Allow HTTP access from the Internet on the public interface (i.e. eth0)
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name. - Save the IPTables settings:
service iptables save
- SSL Configuration Phase
- Login to the server using Root account.
- Create folder for the SSL certificate files:
mkdir -p /usr/local/nginx/ssl
chmod 600 /usr/local/nginx/ssl - Run the command bellow to generate a key pair:
/usr/bin/openssl genrsa -aes256 -out /usr/local/nginx/ssl/server-sec.key 2048
Note: Specify a complex pass phrase for the private key (and document it) - Run the command bellow to generate the CSR:
/usr/bin/openssl req -new -newkey rsa:2048 -nodes -sha256 -days 1095 -key /usr/local/nginx/ssl/server-sec.key -out /tmp/server.csr
Note: The command above should be written as one line. - Send the file /tmp/server.csr to a Certificate Authority server.
- As soon as you receive the signed public key from the CA server via email, copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as “server.crt”
- Copy the file “server.crt” using SCP into /usr/local/nginx/ssl
- Follow the link on the email from the CA server, to create the Root CA chain, and save it as “ca-bundle.crt” (Note: The file must be PEM (base64) encoded).
- Copy the file “ca-bundle.crt” using SCP into /usr/local/nginx/ssl
- Combine the content of both the public key (server.crt) and the Root CA chain (ca-bundle.crt) into one file:
cat /usr/local/nginx/ssl/ca-bundle.crt /usr/local/nginx/ssl/server.crt > /usr/local/nginx/ssl/server.pem
Note: The command above should be written as one line. - Remove the key store passphrase:
/usr/bin/openssl rsa -in /usr/local/nginx/ssl/server-sec.key -out /usr/local/nginx/ssl/server.key
Note: The command above should be written as one line. - Remove the original “server.crt”, “server.csr” and “ca-bundle.crt” files:
rm -f /tmp/server.csr
rm -f /usr/local/nginx/ssl/server.crt
rm -f /usr/local/nginx/ssl/ca-bundle.crt - Edit using VI the file /usr/local/nginx/conf/nginx.conf and replace the section bellow from:
# HTTPS server
To:
#
#server {
# listen 443 ssl;
# server_name localhost;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
Note: Replace Server_FQDN with the actual server DNS name.
#
server {
listen 443;
server_name Server_FQDN;
ssl on;
ssl_certificate /usr/local/nginx/ssl/server.pem;
ssl_certificate_key /usr/local/nginx/ssl/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
ssl_prefer_server_ciphers on;
# HTTP Strict Transport Security #
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# X-Frame-Options header #
add_header X-Frame-Options SAMEORIGIN;
location / {
root /www;
index index.html index.htm;
}
} - Configure IPTables – Allow HTTPS access from the Internet on the public interface (i.e. eth0)
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name - Remove HTTP access from the Internet on the public interface (i.e. eth0)
iptables -D INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name - Save the IPTables settings:
service iptables save
- Restart the nginx:
service nginx restart
Hardening guide for Apache 2.4.6 on CentOS 6.4 (64bit edition)
- X-Frame-Options – Minimum browser support: IE 8.0, Firefox 3.6.9, Chrome 4.1.249, Opera 10.50, Safari 4.0
- TLS 1.2 – Minimum browser support: IE 8.0 on Windows 7/8 (Need to be enabled by default), Firefox 24.0 (Need to be enabled by default), Chrome 30, Opera 17, Safari 5.0
-
This document explains the process of installation, configuration and hardening of Apache server from source files, based on CentOS 6.4 default installation (IPTables and SELinux enabled by default), including support for TLS v1.2 and protection from BEAST attack and CRIME attack.
Some of the features explained in this document are supported by only some of the Internet browsers:
-
Pre-Requirements
- policycoreutils-python-* package installed
- setools-libs-* package installed
- libcgroup-* package installed
- audit-libs-python-* package installed
- libsemanage-python-* package installed
- setools-libs-python-* package installed
- gcc* package installed
- gcc-c++* package installed
- autoconf* package installed
- automake* package installed
-
Installation Phase
- Login to the server using Root account
- Upgrade the Openssl build:
rpm -ivh --nosignature http://rpm.axivo.com/redhat/axivo-release-6-1.noarch.rpm
yum --enablerepo=axivo update openssl -y
- Download Apache source file into /tmp, from:
http://httpd.apache.org/download.cgi - Download APR and APR-Util source files into /tmp, from:
https://apr.apache.org/download.cgi - Download PCRE source file into /tmp, from:
http://sourceforge.net/projects/pcre/files/pcre/ - Compile PCRE from source file:
tar zxvf /tmp/pcre-8.33.tar.gz -C /tmpmv /tmp/pcre-8.33 /usr/local/pcre
cd /usr/local/pcre
./configure --prefix=/usr/local/pcre
make
make install
- Extract Apache source files:
cd /tmp
tar zxvf httpd-2.4.6.tar.gz
cd httpd-2.4.6/srclib/
tar zxvf ../../apr-1.4.8.tar.gz
ln -s apr-1.4.8/ apr
tar zxvf ../../apr-util-1.5.2.tar.gz
ln -s apr-util-1.5.2/ apr-util
- Compile the Apache from source files:
cd /tmp/httpd-2.4.6
./configure --prefix=/opt/httpd --with-included-apr --enable-so --enable-ssl --with-ssl=/opt/openssl-1.0.1e --enable-ssl-staticlib-deps --enable-mods-static=ssl --with-pcre=/usr/local/pcre
make
make install
- Remove the source files:
rm -rf /tmp/apr-1.4.8.tar.gz
rm -rf /tmp/apr-util-1.5.2.tar.gz
rm -rf /tmp/httpd-2.4.6.tar.gz
rm -rf /tmp/httpd-2.4.6
rm -rf /tmp/pcre-8.33.tar.gz
- Remove Default Content:
rm -rf /opt/httpd/cgi-bin
rm -rf /opt/httpd/htdocs
rm -rf /opt/httpd/icons
rm -rf /opt/httpd/man
rm -rf /opt/httpd/manual
rm -rf /opt/httpd/conf/extra/httpd-autoindex.conf
rm -rf /opt/httpd/conf/extra/httpd-autoindex.conf.in
rm -rf /opt/httpd/conf/extra/httpd-dav.conf
rm -rf /opt/httpd/conf/extra/httpd-dav.conf.in
rm -rf /opt/httpd/conf/extra/httpd-default.conf
rm -rf /opt/httpd/conf/extra/httpd-default.conf.in
rm -rf /opt/httpd/conf/extra/httpd-info.conf
rm -rf /opt/httpd/conf/extra/httpd-info.conf.in
rm -rf /opt/httpd/conf/extra/httpd-languages.conf
rm -rf /opt/httpd/conf/extra/httpd-languages.conf.in
rm -rf /opt/httpd/conf/extra/httpd-manual.conf
rm -rf /opt/httpd/conf/extra/httpd-manual.conf.in
rm -rf /opt/httpd/conf/extra/httpd-mpm.conf
rm -rf /opt/httpd/conf/extra/httpd-mpm.conf.in
rm -rf /opt/httpd/conf/extra/httpd-multilang-errordoc.conf
rm -rf /opt/httpd/conf/extra/httpd-multilang-errordoc.conf.in
rm -rf /opt/httpd/conf/extra/httpd-userdir.conf
rm -rf /opt/httpd/conf/extra/httpd-userdir.conf.in
rm -rf /opt/httpd/conf/extra/httpd-vhosts.conf
rm -rf /opt/httpd/conf/extra/httpd-vhosts.conf.in
rm -rf /opt/httpd/conf/extra/proxy-html.conf
rm -rf /opt/httpd/conf/extra/proxy-html.conf.in
rm -rf /opt/httpd/conf/original
- Updating Ownership and Permissions on Apache folders:
chown root:root /opt/httpd/bin/apachectl
chown root:root /opt/httpd/bin/httpd
chmod 770 /opt/httpd/bin/apachectl
chmod 770 /opt/httpd/bin/httpd
chown -R root:root /opt/httpd
chmod -R go-r /opt/httpd
chown -R root:root /opt/httpd/logs
chmod -R 700 /opt/httpd/logs
- Create folder for the web content:
mkdir -p /www
- Updating Ownership and Permissions on the web content folder:
chown -R root /www
chmod -R 775 /www
- Fix the SELinux security context on the new web folder:
semanage fcontext -a -t httpd_sys_content_t "/www(/.*)?"
restorecon -F -R -v /www
- Edit using VI the file /opt/httpd/conf/httpd.conf and change the following strings:
From:
LogLevel warn
To:
LogLevel notice
From:
DocumentRoot "/opt/httpd/htdocs"
To:
DocumentRoot "/www"
From:
Listen 80
To:
Listen Server_FQDN:80
Note: Replace Server_FQDN with the actual DNS name.From:
ServerAdmin root@localhost
To:
ServerAdmin webmaster@mycompany.com
Note: Replace mycompany.com with the actual Company DNS name.From:
#ServerName www.example.com:80
To:
ServerName Server_FQDN
Note: Replace Server_FQDN with the actual DNS name.From:
ScriptAlias /cgi-bin/ "/opt/httpd/cgi-bin/"
To:
# ScriptAlias /cgi-bin/ "/opt/httpd/cgi-bin/"
From:
<Directory />
To:
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory />
Options None
AllowOverride None
Require all denied
Order deny,allow
deny from all
<LimitExcept GET POST>
deny from all
</limitexcept>
</Directory>From:
<Directory "/opt/httpd/htdocs">
To:
Options Indexes FollowSymLinks
AllowOverride None
</Directory>
<Directory "/www">
Options None
AllowOverride None
Require all granted
Order allow,deny
Allow from all
<LimitExcept GET POST>
deny from all
</limitexcept>
</Directory> - Comment out all lines inside the /opt/httpd/conf/httpd.conf file, begining with:
ScriptAlias
IndexOptions
AddIconByEncoding
AddIconByType
AddIcon
DefaultIcon
ReadmeName
HeaderName
IndexIgnore
LanguagePriority
ForceLanguagePriority
- Comment out the lines inside the /opt/httpd/conf/httpd.conf file below to disable default modules:
LoadModule cgi_module modules/mod_cgi.so
LoadModule status_module modules/mod_status.so
LoadModule info_module modules/mod_info.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule include_module modules/mod_include.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule env_module modules/mod_env.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule actions_module modules/mod_actions.so
- Comment out the entire section <Directory “/opt/httpd/cgi-bin”> inside the /opt/httpd/conf/httpd.conf
- Add the following sections to the end of the /opt/httpd/conf/httpd.conf file:
# Configure custom error message:
ErrorDocument 400 "The requested URL was not found on this server."
ErrorDocument 401 "The requested URL was not found on this server."
ErrorDocument 403 "The requested URL was not found on this server."
ErrorDocument 404 "The requested URL was not found on this server."
ErrorDocument 405 "The requested URL was not found on this server."
ErrorDocument 408 "The requested URL was not found on this server."
ErrorDocument 410 "The requested URL was not found on this server."
ErrorDocument 411 "The requested URL was not found on this server."
ErrorDocument 412 "The requested URL was not found on this server."
ErrorDocument 413 "The requested URL was not found on this server."
ErrorDocument 414 "The requested URL was not found on this server."
ErrorDocument 415 "The requested URL was not found on this server."
ErrorDocument 500 "The requested URL was not found on this server."
# Configure Server Tokens
ServerTokens Prod
# Disable Server Signature
ServerSignature Off
# Disable Tracing
TraceEnable Off
# Maximum size of the request body.
LimitRequestBody 25000
# Maximum number of request headers in a request.
LimitRequestFields 40
# Maximum size of request header lines.
LimitRequestFieldSize 4000
# Maximum size of the request line.
LimitRequestLine 4000
MaxRequestsPerChild 10000
# Configure clickjacking protection
Header always append X-Frame-Options SAMEORIGIN - Edit using VI the file /opt/httpd/include/ap_release.h and replace the following strings:
From:
#define AP_SERVER_BASEVENDOR "Apache Software Foundation"
To:
#define AP_SERVER_BASEVENDOR "Restricted server"
From:
#define AP_SERVER_BASEPROJECT "Apache HTTP Server"
To:
#define AP_SERVER_BASEPROJECT "Secure Web Server"
From:
#define AP_SERVER_BASEPRODUCT "Apache"
To:
#define AP_SERVER_BASEPRODUCT "Secure Web Server"
- Download the Apache boot script into /tmp from:
http://www.linuxfromscratch.org/blfs/downloads/svn/blfs-bootscripts-20131023.tar.bz2 - Extract and install the Apache boot script:
cd /tmp/
tar xvjf blfs-bootscripts-20131023.tar.bz2
cd /tmp/blfs-bootscripts-20131023
make install-httpd
- Edit using VI, the file /etc/init.d/httpd, and replace the strings below:
From:
/usr/sbin/apachectl
To:
/opt/httpd/bin/apachectl
From:
log_info_msg
To:
echo
From:
evaluate_retval
To:
#evaluate_retval
- Configure the Apache to start automatically:
chkconfig httpd on
- Configure IPTables:
service iptables stop
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
- Allow SSH access from Internal segment (i.e. 10.0.0.0/8)
iptables -A INPUT -m state --state NEW -p tcp --dport 22 -s 10.0.0.0/8 -j ACCEPT
Note: Replace 10.0.0.0/8 with the internal segment and subnet mask - Allow HTTP access from the Internet on the public interface (i.e. eth0)
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name - Save the IPTables settings:
service iptables save
- Start the Apache daemon:
service httpd start
-
SSL Configuration Phase
- Login to the server using Root account.
- Create folder for the SSL certificate files:
mkdir -p /opt/httpd/conf/ssl
chmod 600 /opt/httpd/conf/ssl
- Run the command bellow to generate a key pair:
/usr/bin/openssl genrsa -des3 -out /opt/httpd/conf/ssl/server.key 2048
Note: Specify a complex pass phrase for the private key (and document it) - Run the command bellow to generate the CSR:
/usr/bin/openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout /opt/httpd/conf/ssl/server.key -out /tmp/apache.csr
Note: The command above should be written as one line. - Send the file /tmp/apache.csr to a Certificate Authority server.
- As soon as you receive the signed public key from the CA server via email, copy all lines starting with “Begin” and ending with “End” (include those two lines), into notepad, and save the file as /opt/httpd/conf/ssl/server.crt
- Follow the link on the email from the CA server, to create the Root CA chain, and save it as /opt/httpd/conf/ssl/server-ca.crt (Note: The file must be PEM (base64) encoded).
- Edit using VI the file /opt/httpd/conf/httpd.conf and change the following strings:
From:
Listen Server_FQDN:80
To:
Listen Server_FQDN:443
Note: Replace Server_FQDN with the actual DNS name.From:
ServerName Server_FQDN
To:
ServerName Server_FQDN:443
Note: Replace Server_FQDN with the actual DNS name.From:
#Include conf/extra/httpd-ssl.conf
To:
Include conf/extra/httpd-ssl.conf
From:
#LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
To:
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
- Edit using VI the file /opt/httpd/conf/extra/httpd-ssl.conf and change the following strings:
From:
SSLCertificateFile "/opt/httpd/conf/server.crt"
To:
SSLCertificateFile /opt/httpd/conf/ssl/server.crt
From:
SSLCertificateKeyFile "/opt/httpd/conf/server.key"
To:
SSLCertificateKeyFile /opt/httpd/conf/ssl/server.key
From:
#SSLCertificateChainFile "/opt/httpd/conf/server-ca.crt"
To:
SSLCertificateChainFile /opt/httpd/conf/ssl/server-ca.crt
From:
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
To:
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL:!EDH:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
From:
#SSLHonorCipherOrder on
To:
SSLHonorCipherOrder On
From:
Listen @@SSLPort@@
To:
Listen Server_FQDN:443
Note: Replace Server_FQDN with the actual DNS name.From:
DocumentRoot "/opt/httpd/htdocs"
To:
DocumentRoot "/www"
From:
ServerName www.example.com:@@SSLPort@@
To:
#ServerName www.example.com:@@SSLPort@@
From:
ServerAdmin [email protected]
To:
ServerAdmin webmaster@mycompany.com
Note: Replace mycompany.com with the actual Company DNS name.From:
<VirtualHost _default_:@@SSLPort@@>
To:
<VirtualHost _default_:443>
- Add the following sections to the end of the /opt/httpd/conf/extra/httpd-ssl.conf file:
# Disable SSLv2
SSLProtocol ALL -SSLv2 +TLSv1 +TLSv1.1 +TLSv1.2
# Disable SSL Compression
SSLCompression Off - Comment out the entire section <Directory “/opt/httpd/cgi-bin”> inside the /opt/httpd/conf/extra/httpd-ssl.conf
- Configure IPTables – Allow HTTPS access from the Internet on the public interface (i.e. eth0)
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name - Remove HTTP access from the Internet on the public interface (i.e. eth0)
iptables -D INPUT -m state --state NEW -p tcp --dport 80 -i eth0 -j ACCEPT
Note: Replace eth0 with the public interface name - Save the IPTables settings:
service iptables save
- Restart the Apache service:
service httpd restart
Protecting your backup
One of the things many companies fail to put enough attention is proper protection to their backups.
I recently read an article about large American bank that sent a notification to its customers of losing a backup-tape, with customer’s personal information.
I guess the only reason the bank reveal the information about the security breach is because he had to do so, under a federal law – just think about how many companies keep this sort of information to themselves in-order to avoid lawsuits.
Almost every company perform backup of its data. It can be using commercial software, file copy to a remote site, backup to tape, and now it is becoming more and more common to perform backup to disk, into a large storage device.
Usually, when performing backup to tape, most companies use to move the tapes into offsite storage, such as remote site.
While moving the backup to remote site might be considered as a good security practice against site disaster, there are 2 important things to think about.
The first thing is physical protection during the move, and while storing them on a safe at the remote site.
In this case I strongly recommend document the process – document the labels and dates of the tapes, and maybe even have the person transporting the tapes sign a form, so you’ll have more confidence that the tapes were actually being transported to their destination.
Another thing you should consider is encryption to the data itself.
You don’t want to be in a situation where somebody steals a suitcase full of backup tapes, where all your data is in clear text.
I guess most commercial products allow you to encrypt your backups, but it raises a question about maintaining the encryption.
If you encrypt your backups using the same password or passphrase year after year, and some ex-employee knows the password, it can harm the whole idea behind encryption.
On the other hand, if you change the password from time to time, you need to manage a list of old passwords against list of dates of backup-tape labels, which might become a headache since it is another thing to maintain.
Today more and more companies are moving to backup-to-disk, because the cost of hard disks is very low, and it’s a fast media.
While performing backup to a remote site, you need to consider moving the data over secure or encrypted VPN lines in-order to avoid someone intercepting the data and stealing sensitive files.
Another good practice is to store the data on an encrypted file system. This way you don’t need to worry about some will be able to review your files, but you will have the overhead of maintaining the encryption key, and the copy to the encrypted file system might become a little bit slower on slow machines or slow storage devices.
Remember, keeping your backup safe and secure, enables you to overcome site disaster while protecting from data breach and law suites.