Vuurmuur and Centos 6.5

Today I got to play around with my centos box and I decided to install Vuurmuur.  The install on centos is pretty easy.

Basically, go to the site and download the tarball.  Follow the steps located here.  Once you think you have everything ready to go, make sure to start vuurmuur before you run the config.  I know this seems initiative enough, but I was under the impression that I would configure it before I ran it.  Oh well.

The last piece would be installing conntrack-tools.  I did not have this in any repos that I had configured, so I decided to build it from scratch.  Note that the latest version of conntrack-tools requires dependencies greater than that that are included in the base repos (such as libnfnetlink).  You are better off just building everything from scratch.  The default install location for the dependencies are in /usr/local/lib.  Pkg-config will not find this location by default.  I ended up using the PKG_CONFIG_PATH environment variable to set the location of the .pc files.  Conveniently they are located in /usr/local/lib/pkgconfig.

I think the end goal here is to install suricata and plug it into Vuurmuur.  I do want to spend some time playing around with the base features, however.

So far I have built a few rules (SNAT and such) and played around with the logging and connection list features.  They seem easy enough to use and quite powerful actually.  Vuurmuur seems to have some built in anti-spoof protection among other things.  It is interesting to do an iptables --list and check out what Vuurmuur has done to it!

Installing NTOP NG on CentOS 6.4

With my linux router in place between my cable modem and safe@office, I'm ready to start playing around with some network IDS/IPS/visualization tools.  The first one I want to play around with is ntop.

For the most part, I followed this link. 

NTOP has created a couple of YUM repos that store most of the binaries/etc you will need to run ntop on CentOS.  This makes it pretty easy to install.

Here is what my ntopng config looks like:

-G=/var/tmp/ntopng.gid
-i eth1
--data-dir /var/ntop
--local-networks 192.168.10.0/24,192.168.12.0/24,192.168.252.0/24

In my case, my inside interface is eth1.  Cable can be quite noisy, so I rather monitor the inside interface then the outside one.  Local networks just tells ntop what to consider local, and what not to.  Make sure the data-dir is writable by the user that ntop switches to after startup (usually nobody).

Other than that, have fun looking at the flows.  I've noticed that ntop is only taking up about 30mb of ram.  Nice!

Centos 6.3 and static routes

I recently added a centos box inline between my cable modem and my checkpoint safe@office.  One of the things that I want to be able to do is run ntop.  Unfortunately, my safe@office was setup to NAT my wireless and wired connections behind it.  According to ntop, all I had was one host.

Disabling natting on the safe@office is easy, except, but default wireless clients and wired clients connect up on different subnets.  I could probably disable DHCP on the safe@office and have everything run via the centos box...but that is a project for another day.  For right now, I need to configure some static routes so that my centos box will properly relay traffic.

Standard route commands work, and are a great way for getting a configuration up and running.

For example:

ip route add 192.168.111.0/24 via 192.168.11.2 dev eth1

In the above example, I am adding a route for the 192.168.111.0/24 network and instructing all traffic to be sent to 192.168.11.2 via eth1.  Pretty sweet.  The problem is that adding routes like this does not persist the configuration after reboot.

I tried to edit the appropriate files as found in this doc, but I found that the configuration did not persist.  I may have messed up somewhere, but I didn't get that method to work.

I decided to go dirty and add the commands directly to rc.local.

Notes for a BitTorrent Sync Setup

I was looking into a few "self-hosted" cloud services and finally settled on btsync the other day.  I had taken a look at the synology disk station, and seafile / owncloud.  Ultimately I think the fact that btsync has security built from the ground up is why I chose it.  I don't need a ton of advanced features, but I don't want just anyone looking at my data.  I do, however, need something that runs on windows / linux / synology and andriod.  BTSync meets all of that.


Btsync is now at version 1.1.42 and with every version it is getting better and better.  I just recently had a chance to test out the beta app for andriod and it worked great!


A couple of notes to consider when using btsync.


1)  Use separate accounts to run the executable

I think this is important.  If you run btsync as yourself, you are giving it the same access that you have.  In all reality, the btsync application only needs access to the folder it is syncing.  Ideally, you can create "service accounts" for this, but keep in mind that by default btsync tries to create .sync files in home directories.  Not a big deal, this is all configurable (at least in linux).


I set up a btsync account on both my linux and windows box and then gave it access to one folder to sync.  This way, if the executable ever gets cracked, it won't (by default) have access to all of my user settings, etc.


2) TCP over LAN didn't work for me

I'm not sure if I did something wrong here, but I couldn't get my clients to connect using TCP over the lan.  They kept defaulting to UDP regardless of the settings on both clients.  Remember this if your lan isn't working like you planned

3)  Make sure you secure the webGUI

If you are using the webGUI (linux users almost always will) be careful about the webGUI.  By default it listens to 0.0.0.0 on port 8888.  The first thing you can do is ensure your firewall is on and protecting that port from the outside world.  The other thing you can do is set a basic username and password in the config file.  (See the user manual)

4)  Monitor connections from the interweb

Remember, if you open a port on your firewall allowing the internet directly in, it is always good to have that go through some type of proxy.  Ultimately this is not going to be feasible for most people, so we have to rely on the bittorrent coders not making any buffer overflow mistakes!

5)  If you can, stay away from the tracker service and the "relay service"

Try it without those features turned on.  I know in most cases, for most people, those settings are turned on because it will just work.  In the case of the tracker stuff, you are broadcasting that your ip is hosting something and what port it is accessible on.  Yes they may not have the secret, but if you don't need that service, just don't use it.  The second is the relay service.  You will need this if you are behind certain network architectures, but for the most part you should be okay with out.  This way your data is not traversing through a server it doesn't have to.  I know the NSA is watching everything, but we might as well try and limit where we are sending our data.  These days, most "dynamic" ips are fairly static.  There are also a few dns services you could use.

6)  256-bit AES is a great choice

But I wonder how the key is derived from the secret and if this could be figured out some how.  According to the docs you can substitute your own base64 encoded key that is more than 40 symbols long.  This might be easier than sharing the base64 encoded version as you could come up with a poem line or something like that, and share it with friends/family.  I do like how you can change the key at any time, they have really through a lot of this stuff through.

All in all, so far I am really impressed by the product.  It works fast and is configurable to tweak in some of your own settings.  I look forward to future releases!

Fedora 18 and Synology Shares Via CIFS

I finally got around to setting up my synology shares via CIFS on my Fedora 18 box.  I tried following the instructions here, but they didn't work so well.

I kept getting the following:

mount error(5): Input/output error
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

I finally stumbled upon this forum post which helped me out.

It looks like in the newer version of CIFS, the security default has changed to ntlmssp from ntlm.  Switching this back worked. 

It will be interesting to see if the security settings on the synology can be upgraded to support some of the stronger protocols.

Hope that helps!

Two factor Authentication on Fedora 17

It turns out that adding an extra level of security to fedora 17 is quite easy.

The google-authenticator PAM module is easily installed via yum.  Once installed, you simply have to edit the /etc/pam.d/sshd configuration to require the pam module as per the instructions located here.

As the user you wish to use two-factor authentication with, you need to run the google_authenticator bin from the command line.  It will create an address that you can navigate to and take a picture with the google-authenticator app on your andriod device.

Voila, two factor authentication on your sshd!

Enjoy.

mod_security, apache httpd, glassfish - Part 4

Part 4, mod_sec install.

One dependency that I missed downloading earlier was libXML2.  This is a dependency for mod_security.  If you wish, you can also install lua and curl.  Lua is needed if you plan to write your own rules and want to use the new lua engine.  I'm not really planning on writing rules, the base rules are pretty good.  As for curl, it is only needed if you want to send logs to a central repo like loglogics.  Since I don't have that kind of infrastructure setup, I won't worry about that in these posts.  If you wish to install those, simple follow the install instructions and then edit the configure to point to the locations in which you have installed the dependencies.

For now, navigate over to http://xmlsoft.org/downloads.html and download libXML2.

./configure --prefix=/path/to/deps/ --enable-shared 

Now we can install mod_security

CC="gcc -m64" ./configure --prefix=/path/to/deps/ --with apxs=/path/to/httpd/bin/apxs --with-pcre=/path/to/deps/bin/pcre-config --with-apr=/path/to/deps/bin/apr-1-config --with-apu=/path/to/deps/bin/apu-1-config --with-libxml=/path/to/deps/bin/xml2-config

When you untared the mod_security files, there was a rules directory.  We are going to copy that directory to /path/to/httpd/conf/rules.  Next, you are going to copy the modsecurity_crs_10_config.conf.example to the same file name minus the example part.  The purpose of this series of articles is not to go through an indepth setup of mod_security.  Just enough to get it working.  You are going to go into the file you just copied and make the following change.

#
# Review your SecRuleEngine settings.  If you want to
# allow blocking, then set it to On however check your SecDefaultAction setting
# to ensure that it is set appropriately.
#
#SecRuleEngine DetectionOnly 
SecRuleEngine On

This is basically going to turn the rules engine on.  You may want to put it on detection only if you are testing a legacy app.  We are going to create another file by the name of modsecurity_crs_10_global_config.conf.  In this file, we are going to basically setup some more mod_security rules.

SecServerSignature "Microsoft-IIS/6.0"
SecDebugLog /cardlock/httpd/logs/modsec_debug.log 
SecDebugLogLevel 3 

Basically this just sets the server to identify itself as IIS 6.  This is a little "security through obscurity".  Hopefully a few script kiddies will get deterred by this.

We need to add the following to our httpd.conf

<ifmodule security2_module>
 Include conf/rules/modsecurity_crs_10_global_config.conf
</ifmodule>

We need to now actually apply these rules to our site that we have just created.  In our site.conf, we should add the following.

Include conf/rules/modsecurity_crs_10_config.conf
Include conf/rules/base_rules/*.conf
Include conf/rules/optional_rules/*.conf

When you startup your httpd now, you may get some "syntax" errors inside the mod_security configuration files. I just go in an delete/comment out the line in question. This is obviously okay if you are not using the technology the line pertains to. For example, you can probably safely comment out any php rules if you are not using php in your website. One in particular is about a data file missing for comment spam. You can go and get it (say google) or you can just deal with the line that is causing the issue.

After you startup apache, you will notice that the modsec_debug.log is getting populated. Feel free to test out mod_security. You can either use a tool like w3af, or just try putting sql injection as a parameter. You should see mod_security block it.

mod_security, apache httpd, glassfish - Part 3

Part three.

Just to recap, we have now installed Glassfish, Java, all the deps for apache httpd, and the httpd itself.  At this point you can startup apache httpd, and then try to navigate to the main page.  You should get a 403 Forbidden. This is because we have not configured apache yet.

The apache httpd configuration file (located in apache_httpd_root/conf/httpd.conf) is a very well documented file.  I'm not going to go through all of the details in the file, but I will touch on a few.  Ideally, you will make a copy of the httpd.conf and start with a fresh file.  From a security perspective, you want to have the configuration file to contain as little "junk" as possible.  This will assist when you are trying to figure out a problem with your server configuration.  It is just easier to read without all the explanations, plain and simple.

## Sample Apache httpd.conf configuration

ServerRoot "/path/to/apache/httpd"
ServerAdmin "your.address@you.com"
ServerTokens Full
ServerName myserver.myserveraddress.com
Listen 80

User apache
Group apache

LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule rewrite_module modules/mod_rewrite.so

DocumentRoot "/path/to/httpd/htdocs"

<Directory />
     Options FollowSymLinks
     AllowOverride None
     Order deny,allow
     Deny from all
</Directory>

ErrorLog "|/.../httpd/bin/rotatelogs -f /.../httpd/logs/error_log.%Y%m%d  86400"
TransferLog "|/.../httpd/bin/rotatelogs -f /.../httpd/logs/access_log.%Y%m%d 86400"

include conf/site.conf

So basically, the first section is just getting general information.  Don't worry about the ServerTokens Full just yet, we are going to use mod security to change our server signature in order to try and fool the script kiddies.  The next section sets up the user you want apache to run as.  If you want apache to run on port 80, we need to start apache as root.  The user/group defined in the file is what apache will switch to after it binds to port 80.  The load_modules section is simply loading all of our shared modules that we need.  The Directory tag is setting up the base permissions.  Basically, deny everyone for right now, until we get our site configured.  As mentioned before, apache has wicked documentation, so I suggest you read it.  Lets move on.

Our goal here is to get apache httpd talking to Glassfish.  Once we establish that, we can work on implementing the advanced features of mod_security.

There are two ways to get apache httpd to play nice with Glassfish.  One is to use mod_proxy.  The other is to use mod_jk.  Here is a very short list of pros and cons.

Mod_Proxy
pro:  Super simple to setup.
con:  Glassfish will see every request as originating from the apache httpd installation as opposed to someone out in the net.  This is bad if you want glassfish to handle some type of security based on ip addresses.

Mod_JK
pro:  More information provided to glassfish (ip address of originator etc.)  Works on a specific language to connect which is faster than mod_proxy.  Has built in support for workers to help support load.
cons:  Hard to setup

For the purpose of this article, we are just going to use mod_proxy.  I may come back later an make another post on using mod_jk.

We need to create a site.conf file with the following information.

<VirtualHost *:80>
  ProxyPass / http://localhost:8080
  ProxyPassReverse / http://localhost:8080
</VirtualHost>

Start up your Glassfish (and confirm that it is running).  Then start up your apache httpd.  You should be able to go to http://localhost and get served the glassfish page.

mod_security, apache httpd, glassfish - Part 2

Part deux!

Just a recap, part 1 took us through installing glassfish. We now have glassfish up and running on our system.

This part will focus on setting up the apache httpd.

1) Compile and install apr-1.4.2

tar xzf apr-1.4.2.tar.gz
cd apr-utils-1.3.10
CC="gcc -m64" ./configure --prefix=/path/to/deps --with-apr=/path/to/deps/bin/apr-1-config
make; make test
make install

The above code is going to be followed a lot (to a certain degree) so I'm only going to explain it this once.  Untar the archive.  Run the config script based on the parameters you want. The CC is compiler arguments and makes it compile for 64 bit (which is what my machine is).  Make the binary, test it, install it.

You will also want to update your bashrc again.

LD_LIBRARY_PATH=<path/to/deps/lib>

Don't forget to source.

2) Compile and install apr-utils

tar xzf apr-util-1.3.10.tar.gz
cd apr-utils-1.3.10
CC="gcc -m64" ./configure --prefix=/path/to/deps --with-apr=/paht/to/deps/bin/apr-1-config
make; make test
make install

3) Compile and install pcre

CC="gcc -m64" ./configure --prefix=/path/to/deps --enabled-shared

5) Compile and install apache httpd
Now that we have installed all the dependencies, we need to configure and install the httpd.  There are a couple of security issues that come up during the installation phase.  Most admins would say (and I'm sure there is a "principle" written about it somewhere) that you should only compile what you actually need.  Apache httpd comes with several built in modules that you would never ever use in a reverse proxy situation.  You could approach this two ways.
1)  Build all the modules with the --enable-shared=all options.  This will build all modules as shared.  Then you can simply edit your config as to which modules you want to load or not.
2)  Use the configure script to only compile the modules you need
There are pros and cons to both approaches.  With (1), all the modules are still there.  If an attacker somehow got access to the conf directory, they could enable modules that could cause futher holes. More realistically, however, someone could accidently turn on a module, and that module could have a vulnerability.  Option two allows you to have complete control on what is actually on the system.  If you ever needed an additional module, however, you would have to recompile to build it.  Because I'm game for pain, I'm going to go with option 2.

C="gcc -m64" ./configure --disable-autoindex --disable-auth-basic --disable-cgi --disable-cgid --disable-userdir --enable-expires=shared --enable-headers=shared --enable-proxy=shared --enable-proxy-http=shared --enable-rewrite=shared --enable-so --enable-ssl=shared --enable-unique-id=shared --with-apr=/path/to/deps/bin/apr-1-config --with-apr-util=/path/to/deps/bin/apu-1-config --with-pcre=/path/to/deps/bin/pcre-config --with-ssl=/path/to/deps --prefix=/path/to/root/httpd-2.2.17

You can go through the configure options on your own if you wish.  The only real requirements are ssl, rewrite, proxy, proxy-http, and unique-id.

After you have that all installed, you will want to run apache to ensure that it starts up.  Because apache is currently configured for port 80, you will have to run it as root.  Ideally you would get a startup script and sudo access to run it, but in this case, just su to root and run apachectl from the bin directory.  You should get a Forbidden error message when you type localhost into your browser.

In the next part, I will talk about configuring apache httpd and using mod_proxy to connect to glassfish.

mod_security, apache httpd, glassfish - Part 1

This post is going to be about building the above from scratch using as little system dependencies as possible.  You may ask yourself why you need to do this.  Well sometimes you work in an organization where your unix team doesn't do this stuff for you.  If they do, you would be subject to the yum rage that would happen every quarter, even if you didn't really need to upgrade your apache version.  Upgrading certain dependencies could mean having to recompile entire applications in order to meet patching schedules.  Of course, you should be upgrading your installations when new updates are found ..... but I digress.

The setup is going to be quite simple.  We are going to use apache httpd in a reverse proxy configuration with mod_security.  We are then going to use mod_proxy (I'll get to this later) to connect the apache httpd reverse proxy with the glassfish back end.  I am doing all of this on a CentOS 5.5 machine.

Before we start, there are a few dependencies that you are going to have to download:

1) libapr and libapr-util
If you were just compiling apache by itself, you could use the built in modules.  But it is very important that mod_security be compiled with the same versions as apache.  You can download them at http://apr.apache.org/ .  We are going to use version 1.4.2(apr) and 1.3.10(apr-utils)

2) libpcre
A perl regular expression library.  Same as above, it is very important that the same versions be used for mod_security and apache httpd.  http://www.pcre.org/ version 8.11

3) openssl
Any respectable website these days has SSL capabilities.  Even if you are not using it right away, we should configure your reverse proxy to be able to handle it.   http://www.openssl.org/source/ v1.0.0c

4) mod_security
http://www.modsecurity.org/download/ v2.5.13

5) Apache httpd
http://httpd.apache.org/download.cgi#apache22 v2.2.17

6) Glassfish
http://glassfish.java.net/downloads/3.0.1-final.html v3.0.1 (zip)

7) Java JDK
JDK 6u23 (From the oracle website)

That should be good for now.  Lets start getting our environment built.  I'm going to start with getting glassfish up and running since it is nice and easy.  If you are thinking about a folder structure, I usually make a separate folder that I'm going to do all my work in.  I make a files directory (it is ALWAYS handy to have the source with you later on... say when you want to rebuild).  I download all my files in there.  I make a dependencies folder and that is where I will install the dependencies that I need (for the most part).

Glassfish InstallGlassfish depends on a JAVA JDK being installed.  With the way most JAVA stuff is distributed, this is a fairly simple process.

1)  Unpack JAVA JDK
With the bin distribution, this is quite easy.

chmod 700 jdk-6u23-linux-x64.bin
./jdk-6u23-linux-x64.bin
mv jdk1.6.0_23 ../
ln -s jdk1.6.0_23 java

Quick explanation.  I had to make the bin executable (1).  I ran the bin which created the java jdk directory.  I moved that directory one directory back so it isn't under files.  I created a soft link called java.  The soft link comes in handy when you are upgrading versions.  You won't need to keep changing your bashrc to the new java folder, just change the soft link.

2) Update environment variables
Now that you have installed java, you are going to want to update your environment variables.  You can do that multiple ways.  If you are running everything from the command line and are using bash, you need to update your .bashrc in your home directory.
export JAVA_HOME=<path/to/java>
export PATH=<path/to/java/bin>:$PATH

Don't forget to source the bashrc (source ~/.bashrc) when you are done so the changes take effect.

3) Unpack glassfish
You should have downloaded the zip file for the glassfish distribution.  Most linux distros these days come with unzip.  If you don't have it, you'll have to get creative (or go build it...)

unzip glassfish-3.0.1.zip
mv glassfishv3 ../
ln -s glassfishv3 glassfish

Once again you'll want to edit your environment variables.  In this case, you will want to edit your path.

export PATH=</path/to/java/bin>:</path/to/glassfish/bin>:$PATH

Once you have sourced your bashrc, you can now try to run glassfish.

asadmin start-domain

You should see it successful start up.  Try it by trying to hit localhost:8080 and localhost:4848 in a web browser.

Glassfish will need to be secured.  I'm not going to go into this in this series of posts, but you would want to do basic things like (not an exhaustive list):
1)  Block 8080 from being accessible (except for local).  After all, that is why we are installing apache and mod_security
2)  Block 4848 from being accessible  (except for local)
3)  Enable the security manager inside of glassfish