Using a self signed cert with Nginx

May 5, 2014August 31, 2015 Josh Reichardt 7 Comments

After the recent heart bleed incident (which I’m sure many of you well remember) I had to reassign some certificates. It turns out that this was a great opportunity to create a blog post. Since I do not create and assign certs very frequently it is a good opportunity to take some notes and hopefully ease the process for others. After patching the vulnerable version of Openssl, there are really only a few steps needed to accomplish this. Assuming you already have nginx installed, which is trivial to do on Ubuntu, the first step is to create the necessary crt and key files.

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/nginx/cert.key -out /etc/nginx/cert.crt

Next you will need to tell nginx to load up you new certs in its config. Here is an example of what the server block in you /etc/nginx/site-available config might look like. Notice the ssl_certificate and ssl_certificate_key files correspond to the cert files we created above, which we stuck in the /etc/nginx directory. If you decide to place these certs in a different location you will need to modify your config file to reflect the location.

server {

listen *:443; 
ssl on; 
ssl_certificate cert.crt; 
ssl_certificate_key cert.key; 
ssl_session_timeout 5m; 
ssl_protocols SSLv3 TLSv1; 
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; 
ssl_prefer_server_ciphers on;

}

Just to cover all our bases here we will also redirect any requests that come in to port 80 (default web) back to 443 for ssl. The is a simple addition and will add an additional layer of security.

server { 
listen 80; 
return 301 https://$host$request_uri; 
}

The final step is to reload your configuration and test to make sure everything works.

sudo service nginx reload

If your nginx fails to reload, more than likely there is some sort of configuration or syntax error in your config file. Comb through it for any potential errors or mistakes. Once your config is loaded properly you can check your handy work by attempting to hit your site using http://. If your config is working properly it should automatically redirect you to https://.

That’s all it takes. I think it might be a good exercise to try something like this with Chef but for now this process works okay by hand. Let me know what you think or if this can be improved.

Wireshark Reference Guide

September 23, 2013August 31, 2015 Josh Reichardt 10 Comments

Based on a strange network problem recently I decided to put together some quick notes and a few tips on ways to improve your Wireshark experience based on my own experience with it. There are many, many more features that Wireshark has to offer, these just happen to be the most apparent ones I have found so far. Wireshark is extremely powerful and therefore extremely useful if used properly. At first it takes a while to get used to everything Wireshark has to offer but once you start to get the hang of how things work then it can be a great network troubleshooting tool. Basic knowledge of networking concepts should be assumed as well as familiarity of Wireshark for those who attempt to debug network problems using this tool.

Here is a list of some of the most common and handy features that you can utilize in Wireshark. I am not going to dive into great detail with most of these items because I honestly don’t have a ton of experience with all of them, I basically just wanted to point out the highlights.

Filtering in Wireshark is very handy.
Create custom profiles for different use cases (quickly select from bottom right hand corner).
Color filters are useful! (Right click a field in the packet trace and selelct colorized rule) The bottom left bar will tell you what variable you are looking at to make things easier when customizing.
Use Regex in wireshark using the “matches” clause to turn on regex patterns.
You can extract specific information from trace files on the command line using tshark.
Right click a packet and select “follow TCP/UDP stream” to debug a single network conversation.
Low delta times are good. If you see high deltas you should probably investigate things.

Here are some more concrete examples and a few basics of how to put these tips into practice. In Wireshark you can use either English or code like operators when filtering to help narrow down traffic and interesting networking patterns and issues. So for example, “==” and “eq” will behave in the same manner when applying filters. Other operators include <,>, !=, <=, >=, etc. Just like you would see in a typical programming language.

Use custom configuration profiles. If you look at packet traces often this will save you a tremendous amount of time if you are looking at specific types of traffic or are only interested in certain traffic patterns. For example, you spend a lot of time looking at many traces that fit the same type of criteria; by using custom profiles you can quickly adjust and modify the view in Wireshark to help quickly identify patterns and potentially issues by cycling through different, specific views. To begin creating custom profiles go to Edit -> Configuration Profiles and then either select the custom profile or create a new one to begin changing.

One handy trick is to disable TCP offload checks. If your packet captures are getting clogged up with a bunch of red and black with offload errors, this is place you should go to look first. There are a few places where this option can either be enabled or disabled. The easiest way to check these options is under Edit -> Preferences and then under the Protocols tree for UDP, TCP and IPv4 protocols. The example below shows what the options should look like for the TCP protocol. The TCP and UDP offload checks are disabled by default but the IPv4 needs to be manually unchecked. The specific option under the IPv4 protocol is labeled “Validate the IPv4 checksum if possible”, simply uncheck this and the red and black errors should disappear.

There is a capture option that allows you to resolve IP addresses to hostname, which I find can be very useful. To enable this option open up the Show capture options screen, there should be an option in there under name resolution called “Resolve network-layer names”. Simply check that box and you should have name resolution.

As mentioned in the bullets above, the “follow UDP/TCP stream” option can be extremely useful and is a very quick way to glean information. It is so useful because it is so easy to use. Simply find a traffic conversation you would like to debug and right click the packet number in the top Wireshark pane and choose the follow UDP/TCP stream option and you can get an idea of everything that happened during a particular conversation. For example, using this technique you can follow FTP transactions.

Viewing a breakdown of the packet flow and traffic patterns can be a useful tool as well when diagnosing various network issues. There is an option in Wireshark that shows in good detail the breakdown of various packets and protocols that can be used to troubelshoot the network. This option is called Protocol Hierarchy Statistics and can be found un te Statistics -> Protocol Hierarchy Statistics page.

Only look at traffic for one IP address:

ip.addr==192.168.103.104

Likewise, filter out all traffic from an IP address:

!(ip.addr == x.x.x.x)
!(ip.addr == 1.2.3.4)

filter out all traffic for a specific port

!(tcp.port eq 2222)

Resources:

http://ask.wireshark.org/questions/
http://ask.wireshark.org/questions/
http://www.wireshark.org/docs/

Locking down your WordPress site

April 23, 2013August 31, 2015 Josh Reichardt 8 Comments

Since I don’t really want to get in trouble for this, I need to put in a disclaimer. Some of these tools can be invasive and if you are running them against somebody then I take no responsibility for their actions against you. I am testing these tools against my own site so the consequences are minimal. Just be aware that there can be serious consequences for using these tools on sites and companies against their will. I don’t want anybody going to jail.

The tools

Let’s take a poke around with WP Scan. This tool is a WordPress vulnerability scanner, often packaged together with Backtrack or the newer Kali Linux pentesting distro. WPScan helps find and eliminate security weaknesses in your WordPress site. More information about this tool can be found here.

There are many other tools out there but for basic WordPress scanning this tool should suffice, because it offers a number of things that are of interest in a nice single tidy and clean interface. Other tools that may be of interest include tools like Burp Suite, SQLmap, username enumeration through Metasploit and other reconnaissance tools.

The process

Most real world attacks will reach for the low hanging fruit when it comes to exploiting WordPress sites, typically gaining access to a site through password exploitation. With so many WordPress sites going up it becomes easy to move from site to site trying different password brute forcing attacks, so that’s where you will see a large number of attacks. There are others as well, such as vulnerability attacks, SQL injection attacks, XSS, etc.

To begin the process let’s start gathering some information about the WordPress site that will be the focus of this attack, my blog. Here, I am running WPScan through Kali Linux, so the syntax may change depending on how you decide to use this tool. Let’s see what basic information we can get about my blog. This site scan will attempt to gather the basics of the site it is scanning. For help just type ‘wpscan –help’.

wpscan --url http://thepracticalsysadmin.com

Let’s see how far we can get with the password brute forcing method. To enumerate a list of user account names use the following,

wpscan --url http://thepracticalsysadmin.com --enumerate u

If you get any interesting results from this scan, for example the result returns the username admin, go ahead and see if you can brute force the account.

wpscan --url http://thepracticalsysadmin.com --wordlist /pentest/passwords/wordlists/darkc0de.lst --username admin

There are more features packed in this tool so take some time to explore what all it can do (preferably on a test box). Odds are that on a site that hasn’t been properly locked down you can probably get in, one way or another. I wouldn’t recommend running wpscan against this site though because I have already beefed up the security and temporarily block access if users run malicious scans against the site.

Locking it down

There are a number of techniques to help reduce the attack surface for your WordPress site as well as methods to increase the difficulty of breaching your site. The first and foremost is the use of strong passwords. That should be a given and I won’t get into the details here of how important strong passwords are. Another (hopefully) obvious technique is to keep up to date with your patches. Whether it be on the Operating System or your WordPress site/plugins you should try to be proactive about patching your systems. The third and final obvious solution I will mention are getting good backups. If your site does get compromised then it is incredibly helpful to have a point in time to go back to rather than starting over from square one. There are plugins designed to help with this process and even doing it by hand isn’t that difficult. You can get back on your feet even if you only have a database dump from your site at some point in the past.

I’d like to specifically mention some good tools to use if you have publicly facing SSH; one of which is fail2ban. This tool can be used as a layer of defense to slow attackers down by detecting malicious activity and banning IP addresses. Another great tool, a handy plugin for WordPress sites is called Better WP Security. This is an easy to use site hardening tool that can fill up weaknesses and security holes quickly for somebody that doesn’t necessarily have security in the foreground of their minds.

By utilizing these basic techniques you will infinitely increase your WordPress site’s security and make it much more difficult to attack and exploit. There are of course other techniques to improve security but at a certain point it can become a balancing act. *Most* site admins aren’t overly conscious about security and so do not spend a lot of time on their security efforts, they are more concerned about the content and getting things up. Likewise, some are probably more prone to lock things down more than they perhaps need to. It is important to maximize your effort, and to cover the most important security aspects by implementing the basics.

Centralising logs for fun and profit

October 16, 2012August 31, 2015 James Cort 14 Comments

It’s one of those things that usually gets pushed to the back burner because it seems like too much work for too little gain: setting up a central syslog server which all your other systems can report back to.

This is a shame, because there’s lots of benefits to having such a server:

You can analyse what’s going on in your network from a single, central location – saving you from having to log into a variety of devices for troubleshooting.
Improved security – if you have a security breach, the offender has to break into the logging server as well if they’re to cover their tracks properly. (I wouldn’t recommend re-purposing an existing server for precisely this reason – you want your syslog server to be as secure as possible, which means it needs to be running as few services as possible).
You only need to remember one set of tools to manage logs from a range of devices. Most routers will happily send logs back to a remote syslog server; there are also third-party products you can install on Windows.

It’s trivially easy to set this up in any reasonably modern Linux distribution. Once again, I’m going to use Debian for this example.

Out of the box, Debian uses rsyslog and stores the configuration file in /etc/rsyslog.conf. Fortunately, the default configuration only needs minor changes to two lines as shown in this excerpt:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Uncomment the lines beginning $ModLoad and $UDPServerRun by removing the # symbols:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Restart rsyslogd (service rsyslog restart) and…. that’s it. Done.

Well, that’s not quite it. A remote syslog server isn’t much good unless you have equipment sending logs to it. On any other Debian servers you may have, this is just a matter of adding a line to /etc/rsyslog.conf:

*.* @192.168.42.39:514

(substitute your own logging server’s IP address or hostname for 192.168.42.39).

Restart rsyslog on the server that will be sending logs to your remote syslog server. Now when you check your remote syslog server, you should find logs appearing from both itself and anything else that’s configured to send logs to it.

Advanced Tweaks

Once you’ve got this done, there’s all sorts of things you can add. You can separate logfiles according to the host that generated them, you can have new logfiles created every day with an appropriate filename… or you can just stick with the basic configuration which will put everything in the same set of log files and just use grep to separate the interesting information.

Whatever you do, keep a sharp eye on disk space on your logfile server. Logs can grow very large very quickly, and a syslog server with a full disk won’t log anything at all.

A Brief Overview of the Linux chattr Command

January 22, 2012August 31, 2015 Josh Reichardt 9 Comments

I recently watched a talk given by Raphael Mudge, the creator of Armita, entitled “Dirty Red Team Tricks”. In this talk he basically goes over the basics of how to play the hacker version of capture the flag from the point of view of the offensive team or attackers, the red team (pretty self explanatory right?). It was a really good watch, and he demonstrated some really neat little tricks to the audience, including how to use Armitage effectively. Here is the link If you would like to view the presentation.

There was one very curious trick he mentioned in his talk that I want to focus this post on and to save as a note to myself for future reference. That is the chattr command.

The main use case for this command is to essentially make a file immutable by setting the “+i” flag. This is similar to using the attrib command in dos on Windows. So for instance, you could do something like change the attributes of a password file or any other important file that you didn’t want getting altered by issuing the following command:

chattr +i some_file_name

Note, you must be root or in the sudo group to use this. Until the flag to turn this off is issued, even the root user cannot change the file, how cool is that?! I see why Mudge likes to use this dirty little trick when competing in capture the flag games now. So to check what attributes a particular file has applied to it you can use the lsattr command as follows, notice that the i flag is now set for the file:

lsattr some_file_name ----i------------e- some_file_name

And finally, to switch this flag off use the following command:

chattr -i some_file_name

We can check again to see if the flag actually got turned off:

lsattr some_file_name -----------------e- some_file_name

That’s it. I couldn’t believe how simple this nasty little trick was to use but how effective it may be in a given situation. I hope this post was helpful for you, and seriously, you should check out Armitage if you are messing around with penetration testing tools, Raphael Mudge is a really smart dude.