Networking

Document Storage: Part 3

James Cort 2 Comments

Document Storage Project

This is Part 3: Configuring Apache.

We’re only looking for a fairly simple interface to browse through documents. Apache already gives us that – you just need to enable a feature called “Indexes”. But the default indexing is pretty ugly; it’d be nice to make it look a little prettier and maybe add scope for expanding on functionality.

Initially I was going to design my own style, but it turns out someone’s already done that and he’s done a better job than I could ever hope to. So I took the style setup from Recursive Design and tweaked it slightly to fit in with what we’re doing here.

  cd /home/http/assets
  svn co http://recursive-design.com/svn/misc/apache/index-style
  mv index-style/* . 
  rmdir index-style

The stylesheet really ought to be referenced with a specific path so it can always be found. Edit /home/http/assets/header.html and change the stylesheet reference thus:

Next up, we need to configure Apache. Ignore the instructions on the Recursive Design blog; things are slightly different here. Edit /etc/apache2/sites-available/default as follows:


        ServerAdmin (YOUR EMAIL ADDRESS HERE)

        DocumentRoot /home/http/documents
        
                Options FollowSymLinks
                AllowOverride None
        
        
                AllowOverride None
                Options Indexes
                DirectoryIndex index.html index.php
                IndexOptions FancyIndexing
                IndexOptions VersionSort
                IndexOptions HTMLTable
                IndexOptions FoldersFirst
                IndexOptions IconsAreLinks
                IndexOptions IgnoreCase
                IndexOptions SuppressDescription
                IndexOptions SuppressHTMLPreamble
                IndexOptions XHTML
                IndexOptions IconWidth=16
                IndexOptions IconHeight=16
                IndexOptions NameWidth=*
                IndexOrderDefault Descending Name
                HeaderName /assets/header.html
                ReadmeName /assets/footer.html
                Order allow,deny
                Allow from all
        

        Alias /assets /home/http/assets
        Alias /search /home/http/search

        
                AllowOverride None
                Order allow,deny
                Allow from all
        

        
                AllowOverride None
                Order allow,deny
                Allow from all
        

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

 ..... LEAVE THE REST OF THE FILE ALONE ......

Restart Apache.

Put something – ideally a PDF that was NOT generated from a scan but instead contains searchable text – into /home/http/documents and browse to http://(hostname).local from a separate PC on the network. If all goes according to plan, you should see something a bit like this:

There’s a lot more to do: we still need something that can index this little lot (so we can just punch in search terms) and we need some easy way to get documents onto the server. But they’re a topic for a future post…

Read More

Centralising logs for fun and profit

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.

Read More

Network booting without changing your existing infrastructure

James Cort 16 Comments

There’s lots of instructions out there explaining how to set up PXE booting – but most of them assume you’re happy to mess with a perfectly good DHCP configuration. There’s lots of reasons you might not want to do this, but that doesn’t mean you have to forego the convenience of just hitting a key at boot and booting PCs or servers from the network. In this tutorial, we’ll be looking at setting up network booting from a Linux box without touching your existing DHCP infrastructure. This will work even if you’re using something else entirely for DHCP.

These instructions were originally written for Debian, though they should work equally well with minor tweaks on Ubuntu.

First, you want to install dnsmasq:

apt-get install dnsmasq

(use sudo if you’re not logged in as root!)

Once you’ve done that, you need to configure dnsmasq to act as a Proxy DHCP server. I’ve put this in a separate configuration file in /etc/dnsmasq.d/pxe.conf:

# Put your own DHCP range in here.

dhcp-range=192.168.42.0,proxy
pxe-prompt="Press F8 for menu", 20
pxe-service=x86PC, "Boot from local disk"
pxe-service=x86PC, "Install Linux", pxelinux
enable-tftp

# This can be anywhere you like.

tftp-root=/srv/tftp
tftp-secure

Make sure /srv/tftp exists:

mkdir -p /srv/tftp

That’s the hard work out of the way. All we need now is something that can be served up via tftp, and the nice people behind Debian provide that for us:

cd /srv/tftp
wget ftp://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/netboot/netboot.tar.gz
tar zxf netboot.tar.gz
rm netboot.tar.gz
chown -R dnsmasq /srv/tftp

Restart dnsmasq, check it’s started up using ps:

service dnsmasq restart
ps -ef | grep dnsmasq

Now you can test. Boot a PC from the network; if it all goes according to plan, you should see something like this:

Press F8 as per the instructions and you’ll be prompted to choose between booting from the local disk or installing Linux. Choose install Linux and you’ll drop into the Debian installer menu:

From here, you can install Debian as per usual.

Read More

Reset your ASA5505 Password

Josh Reichardt 7 Comments

If you have forgotten the password to access your ASA configuration or need to perform maintenance on an ASA device but do not have administrative access, this process will guide you through the steps that are necessary to recover the password to administer it.  You must be physically connected to the device for this method to work.  In my case, I am directly consoled to the device through a serial cable connection and using PuTTY to reach into the device itself.

  • Reboot the device.  While it is powering up, press the escape key to enter ROMMON.
  • To tell the device to ignore its normal configuration when the device is reloaded enter the following while in ROMMON:

rommon #0> confreg

You will see the current configuration register (normally 0x00000001) and will be prompted to to change its value.  Be sure to make note of the register value so you can change it back later, when you are finished making changes.

  • Enter Y at the “Do you wish to change this configuration?” prompt to change the register value.
  • Accept the defaults (you don’t not need to specify Y/N, the default is already picked for you, simply hit enter to accept) for all settings except the “disable system configuration?” setting, select Y at this prompt as depicted below.

  • Reload the ASA to have it pick up the changes you just made.

rommon #0> boot

You should now be able to access the ASA by typing “en” to get to enable mode and then “conf t” to enter global config mode.  From here you can paste in the config file you would like to use or simply change the password so you can administer the device as you normally would.

hostname(config)# password password
hostname(config)# enable password password
hostname(config)# username name password password

Finally, to exit out of ROMMON and have the ASA boot with its normal startup configuration, enter “confreg” value, where value is the previously noted registry value we recorded, 0x1.  If you have trouble finding the usage or syntax of this command type “help” to well, help you.

rommon #1> confreg 0x1

Followed by a reload, as pictured below.

The ASA should boot up normally now and you should be able to go about your business without any further complications.  Let me know if you know of any easier or better ways of resetting passwords for ASA devices.

Resources:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/trouble.html#wp1049302

Read More

Setting up an L2TP VPN with pfSense

Josh Reichardt 1 Comment

UPDATE:  I think it is important that I inform readers that this guide is strictly for setting up and using L2TP.  It has come to my attention that many of you are are looking for a L2TP/IPSec solution, which is currently not supported in PFSense as of the version I am using (2.0.1).  I will update this post with full L2TP/IPSec instructions once this functionality has been added in new versions of PFSense.

I’ve been toying around with setting up a home VPN for about a week or so now, which has progressively improved.  At first, I had a working VPN implementation with PPTP and life was good.  But apparently  PPTP is known to be less secure than other methods.  So that got me thinking about beefing up my security.  Here’s a quick summary I found.

PPTP has been the subject of many security analyses and serious security vulnerabilities have been found in the protocol. The known vulnerabilities relate to the underlying PPP authentication protocols used, the design of the MPPE protocol as well as the integration between MPPE and PPP authentication for session key establishment.

After discovering this information I decided to poke around for a little bit to decide what would work the best for me.  There were pretty much two options when it came down to setting up my VPN server the way I wanted it.  L2TP and OpenVPN.  They are both considered secure and from what I’ve read OpenVPN is considered slightly better.  The reason I chose L2TP is becuase it is built in to the VPN client on pretty much every OS these days, making client set up and configuration fairly quick and painless (I’m sure its not difficult to set up and use OpenVPN either but I didn’t get that far, maybe I will experiment with it in the future).

There isn’t really all that much to getting things up and going.  Open up the pfSense management interface and navigate to the L2TP VPN settings.  VPN -> L2TP

Next, we have to configure our settings.

  • Server address – Use an ip address that doesn’t fall into the subnet that the VPN clients connect to.  I used my external IP address to make things easier.
  • Remote address range – This will be the subnet that VPN clients connect to.  I am using the 192.168.2.0/24 subnet.
  • Subnet mask – I am using the entire subnet so I chose /24.
  • Number of L2TP users – pretty self explanatory, I have 10 right now for testing purposes.

>I left everything else as the default initially.  Here is what the configuration page looked like for me when I got everything working.  Remember to change these values accordingly.

Next we need to throw up some user accounts.

So far so good.  Now we need to set up some traffic rules for our L2TP clients that connect.  This is the absolute most basic method you can go with, so if you have restraints here you will need to adjust these settings.

<

The last and most important piece to get this working is setting up the firewall rules for the WAN interface.  I got stuck at this part and didn’t realize there were two sets of ports that I needed to allow through for things to work correctly.  Port 500 for Internet Key Exchange (IKE) UDP traffic and port 1701 for L2TP UDP traffic.  Here’s what the rules look like.

That should be it.  Try connecting to your VPN server with an endpoint client.  I was testing this with my Android phone and had no problems after creating the two firewall rules.  Happy VPNing!

 

Read More