Monday, August 29, 2011

This article is in response to a query about securing a FIOS network in a reasonable way for family and home use.




This design will create three separate zones. The first zone is the WAN, which simply picks up the IP address, routing, and DNS information from the FIOS servers. This implements the simple SPI firewall filters.

The second zone is the Trusted LAN, which will be locked down in what it can pass to the other zones. Why treat the Trusted LAN with less trust? Well, if we want to trust assets on that network, we need them to perform in compliant ways. So, instead of inherently trusting assets on that network, we enforce that that segment will act in an assured manner. This means implementing egress controls, limiting weird protocols, and forcing the use of proxies. Think of it less as 'a zone of trusted hosts' and more like 'a zone of hosts I need to trust'. These hosts are subject to more scrutiny as they or their data are more valuable.

The third zone is the DMZ. The hardened proxy/dns server goes in here, but the rest of that segment is for hosts that can't comply with the mandatory restrictions of the Trusted LAN. These are usually consumer appliance devices like iPods, iPads, tablets, video game consoles, Internet-enabled DVD players and the like. My rubric: consumer appliance devices that need Internet access to be useful but are too dumb to print.

I also recommend placing wireless connections into yet another zone to provide granular access controls. Wireless is typically the weakest infrastructure conduit in a home network, excluding PEBKAC. However, attaching wireless access points into the DMZ and Trusted zones may be suitable depending on your ability to secure them.

Pick list:
  • Pentium-3 class computer with 256 MB RAM. As this machine is likely 10 years old, purchasing an IDE-to-Compact Flash adapter with an 8GB CF card will give it some pick-up. Assuming there is already one Ethernet onboard the motherboard, this unit should have at least a PCI expansion port capable of supporting a 2- or 4-port Ethernet card. Keep in mind, three ports are required to make this configuration work. With a minimalist firewall OS, like m0n0wall, this will become a capable firewall.
  • Matching PCI 2- or 4-port Ethernet card. Server-class coprocessors by Intel are desirable.
  • Pentium-4 class computer with 512 MB RAM + 10GB drive. This machine is probably 5-7 years old and needs a little more spunk to deliver layer-7 services. Consider the above-mentioned PCI-to-CF converter for the base OS with a secondary drive for bulk storage. This will become the DMZ proxy and DNS services.
  • Pentium class computer, configuration negotiable, lots of bulk disk (fast I/O preferred). This machine will become the internal security auditor, receiving logs from the DMZ proxy and the firewall.

Bringing in the WAN

My FIOS installation has the unfortunate distinction of not using the Ethernet for the WAN connection, but bringing in the WAN backhaul over the COAX. This requires the use of a MOCA adapter to bridge the WAN to Ethernet. Since I don't have any spare MOCA units around and the COAX LAN to the video set-top boxes run over that same COAX line, that means using the ActionTec in a double-bridge confirguration, as documented in my previous post "Verizon FIOS Faux Paus".

Firewall Installation


Download and install m0n0wall on the firewall host. Once the steps are completed to create the double-bridge, or if you have Ethernet WAN, run the WAN line to eth1 of the firewall host. The default setup via the console of the FW host should allow for easy implementation of the WAN (eth1) and LAN (eth0) ports in simple no-ingress, all-egress configuration. Apply a common RFC 1918 private class-C subnet to the trusted LAN. e.g. 192.168.1.0/24.

Now set up the third interface as a DMZ (eth2). Set it up in standard SPI configuration: block ingress initiates, allow all outbound traffic. This will allow just about anything to work in this network. It also provides a nice guest network for visitors. Apply a different class-C subnet for the DMZ. e.g. 192.168.2.0/24

Connect the switches to the respective ports. You should definitely be using separate physical switches for each segment. Otherwise, employ VLAN tagging for the segments on a single switch that can support it. Wireless routers with integrated switches can serve this purpose, just use the Ethernet LAN ports, not the WAN port to avoid double NAT'ing. If using a switch with node presence, like most consumer-grade [wireless] routers, be sure to set the router IP to a private subnet not routable by that served by the LAN it is on. For example, on a 192.168.n.n LAN with a gateway of 192.168.n.1, the router management IP should be 10.n.n.n. Management of the switch should be performed by a direct hookup to a host with a static IP set to the same class-C subnet. It is not a perfect solution, but it will help prevent drive-by XSS exploits on weak router configuration pages and casual scans. Neither is it invisible, as described later. Routers are noisy things.

Establish Essential Services


With basic services going, it is time to establish control over essential services. This will be done on a host operating in the DMZ. This will provide it the access it requires to the Internet for services, make it available to both TRUSTED and DMZ hosts that might make use of it, and protect the TRUSTED network from probes should the box become compromised. However, if the host becomes compromised, it will give the attacker control over traffic direction (DNS) and content (proxy) for the TRUSTED net. I chose Ubuntu for the easy package management, though any *nix operating system should be appropriate. This box should be hardened and tightly monitored.

Most of the Internet operates via HTTP(S) after performing a DNS resolution. Therefore, controlling these protocols is essential to establishing control in the network. With the intent of completely locking down egress protocols on the TRUSTED LAN later on, a fully-featured proxy server is necessary. Caching is also a nice feature to reduce the load of things like updates, which most of the hosts on the network will be doing from Internet sources. SQUID provides caching support, access enforcement, and robust logging features.

Optionally, one can layer DansGuardian as a free regex-based enforcement layer on top of SQUID. It provides access controls suited for many common web ailments. Be advised, it will require a bit of tuning at setup to keep from blocking things like system updates. It also does not respond well for some foreign-language matches, which can become a burden. Otherwise, if you are technically inclined and have time to maintain your own custom lists, this is a great tool.

On the proxy host, also install DNSMASQ. This is the same utility that provides forwarding DNS and DHCP services on many wireless routers. We will only be using it for its DNS capabilities. Edit the dnsmasq configuration file to manually set OpenDNS as the DNS forwarders. OpenDNS provides filtered DNS resolution for free, protecting against many of the most obvious violations by botnet herders by default, even without an registered account. If you choosed to register and add your home network, you can gain further content control based on their domain categorizations.

Set the logging of both squid and dnsmasq to the syslog daemon. Modern syslog services, such as rsyslog and syslog-ng, are capable of filtering different program's logs into rotated files. Establish log directories and rotated log files for squid and dnsmasq. Also fork these feeds to the central syslog server (audit server) to be established later.

Locking Down

Now that DNS and Proxy services are established, adjust the configuration of the firewall. Change the default DHCP behavior from issuing the firewall's IP as the DNS passthrough to issuing the IP address of your proxy/dns server in the DMZ. This will encourage hosts to use the DMZ DNS server, which provides logging and domain access control. In the TRUSTED LAN, adjust your hosts' settings to use the proxy server in the DMZ. This is typically done by setting the proxy values to "http://proxyip:3128/", and selecting 'apply to all protocols'. For Windows boxes, this must be done in Internet Explorer to make system updates work, as well as any other installed browsers that do not integrate with IE's proxy settings. For Gnome Linux hosts, this is typically under System -> Preferences -> Network Proxy as the administrative user. When prompted, confirm 'apply systemwide'.

With hosts in the TRUSTED LAN using the proxy, the firewall can now be prepared to lock out all outbound protocols for that subnet. Establish a rule allowing http/s and dns traffic to the proxy server. Create a rule allowing syslog from the dmz proxy server into your trusted audit server. Establish another rule allowing SSH from the trusted server to the dmz proxy server. This will allow you to manage the proxy server to manage it after first authenticating to the trusted server. Prepare for a day where you will be able to monitor the blocked traffic from the firewall on your syslog server. There will be a few things like anti-virus software updates and email server access that may not respond well to the demand for a proxy server. These will have to be manually updated in the firewall as exceptions. There may be a rule explicitly allowing traffic from the LAN to the DMZ. It should be disabled. Now, as the last rule, reject everything sourced from the TRUSTED LAN. Apply and start watching the logs.

Wireless

If you have chosen to employ wireless, ensure that the wireless access points are configured to different ESSIDs and encryption keys. They do not service the same networks.

Review

In this post, we've reviewed locking down the network of hosts we need to trust, while still allowing non-proxy-capable devices an allowance to the Internet. The DMZ allows cart-blanche access to all devices, providing a network suitable for Internet-ready appliances and guests. The proxy services enforce proper accesses on the Trusted hosts and the DNS service logs all of the hosts requests.

Next time: Auditing the Logs

Wednesday, August 17, 2011

Review of a Clean Android Installation

After acquiring a new Android device recently, I decided to profile the traffic. Using Splunk to analyze the traffic, I came up with this nice little chart. No surprises here.


Thursday, November 11, 2010

Ecryptfs and profile errors

I recently had an Ubuntu fail on ecryptfs. I would log into the system and it would present a default empty home dir with the Access-ecrypt-fs file. The problem was similar to these discussions on lost ecrypt profiles.


https://answers.launchpad.net/ecryptfs/+question/46307

http://ubuntuforums.org/showthread.php?t=1459250

My profile looked like this:

$ ls
Access-Your-Private-Data.desktop  README.txt

$ ecryptfs-mount-private
ERROR: Encrypted private directory is not setup properly

After running an strace, I finally discovered that my movement of the /home directory contents had upset the delicate balance of ecryptfs. The program was not finding the .ecryptfs files it was looking for. ecryptfs profiles are not stored in your home directory, but rather are linked to another profile store.

$ ls -la
lrwxrwxrwx 1 user user   31 2010-09-07 21:51 .ecryptfs -> /home/.ecryptfs/user/.ecryptfs

The system had lost its way to /home/.ecryptfs/user/.ecryptfs. Fixing the links in /home recovered my encrypted profile.

$ ls -la /data1/home
total 16
drwxr-xr-x  4 root  root  4096 2010-09-07 21:51 .
drwxrwxrwx 11 root  root  4096 2010-09-26 10:42 ..
drwx------  4 user user 4096 2010-09-25 22:00 user
drwxr-xr-x  3 root  root  4096 2010-09-07 21:51 .ecryptfs

$ cd /
$ sudo rm -rf home
$ sudo ln -s /data1/home home

Tuesday, October 12, 2010

Scanning Memory Objects with Yara

Below are some Python inserts to enable yara scanning of in-memory objects while parsing something, like a PDF. This particular example enables Yara signature scanning of parsed, filtered PDF objects via Didier Steven's PDF-Parser.

[...imports...]

import yara
import mmap
rules = yara.compile('path/rulefile')

[...parsing code...]

############################ yara insert around line 558
############################ just before
######### print ' %s' % FormatOutput(filtered, options.raw)

memmap=mmap.mmap(-1,len(filtered))
memmap.write(filtered)
memmap.seek(0)
matches = rules.match(data=memmap.read(len(filtered)))
memmap.close()
for m in matches:
__ print ' yara: %s' % (m)

##################################

[...resume Didier's code...]

print ' %s' % FormatOutput(filtered, options.raw)

Thursday, September 30, 2010

Installing Yara on Ubuntu 10.04

Installation for YARA on Ubuntu 10.04. First you will need the PCRE development and runtime libraries.

$ sudo apt-get install libpcre3 libpcre3-dev

Now acquire the YARA source code.

$ wget http://yara-project.googlecode.com/files/yara-1.4.tar.gz
$ wget http://yara-project.googlecode.com/files/yara-python-1.4.tar.gz

Untar and configure YARA.

$ tar xvfz yara-1.4.tar.gz
$ cd yara-1.4.tar.gz
$ ./configure

If there are no errors, make the executables.

$ make
$ make check
$ sudo make install

Now add python support.

$ cd ..
$ tar xvfz yara-python-1.4.tar.gz
$ cd yara-python-1.4.tar.gz
$ python setup.py build
$ sudo python setup.py install

You should now be able to call YARA from a shell prompt.

$ yara
usage: yara [OPTION]... [RULEFILE]... FILE
options:
-t print rules tagged as and ignore the rest. Can be used more than once.
-i print rules named and ignore the rest. Can be used more than once.
-n print only not satisfied rules (negate).
-g print tags.
-m print metadata.
-s print matching strings.
-d = define external variable.
-r recursively search directories.
-f fast matching mode.
-v show version information.

Report bugs to:

Thursday, September 23, 2010

Installing log2timeline on Ubuntu

Here is a script to ease installation of Kristinn Gudjonsson's Log2Timeline tool on Ubuntu hosts. Tested on Ubuntu Lucid 10.04.

############################################
# log2timeline_ubuntu_deps.sh
############################################
#!/bin/sh
sudo apt-get install libdigest-crc-perl libnetpacket-perl libparse-win32registry-perl libarchive-zip-perl libtimedate-perl libcarp-assert-perl libclass-dbi-perl libdatetime-perl libhtml-scrubber-perl libnet-pcap-perl libparams-validate-perl libimage-exiftool-perl libdbd-sqlite3-perl libdate-manip-perl libdatetime-format-strptime-perl
sudo perl -MCPAN -e 'install File::Mork'
sudo perl -MCPAN -e 'install Data::Hexify'

Tuesday, August 10, 2010

Verizon FIOS Faux Pas

Exemplifying the problem many folks have been having with Verizon FIOS, our router is version C of the Actiontec line. For the first two years of use, the bulk of our bandwidth was light web surfing and providng data to the VOD/Guide service for the DVR. Not very taxing on a 12Mb/s line. However, two things happened this year that started to tax the FIOS service, as provided by Verizon. First, we got an internet-ready DVD player. For this, we also signed up for NetFlix, an online movie service whose monthly subscription for online access to streaming content is less than a couple of video store rentals. We also discovered that our Wii had onboard wireless and had recently had software written for it to make it NetFlix compatible. This increased our bandwidth usage when streaming a movie by about ten fold. Unfortunately, the little NAT table in the ActionTec router just couldn't handle it and ended up crashing about every other day, requiring a manual power cycle. This just wouldn't fly, so, having spare hardware laying around and a desire to amp up the firewall capabilities of the home connection anyway, I decided to attempt to replace the Actiontec.


I followed the advice provided at DSLReports and set up a double-bridge bypass to my own firewall. This worked well for bypassing the NAT table issue... for about 20 days. After that, the Internet continued to work flawlessly, providing plenty of connections for the demands of streaming media, but the VOD/Guide services consistently failed due to the DVR's inability to pull an IP address. After a couple hours of poking at my firewall and the Actiontec, I found that the COAX (Ethernet) connection was not pulling an IP for the Actiontec, nor was it passing the bridge from the MOCA adapter for the STB. When I realized this, I looked at the configuration of the Actiontec router and saw that the COAX (Ethernet) interface was completely disabled. Now how could this be? It worked before. After re-enabling it and some power cycles, I determined that the Actiontec will only enable the device for the time it is powered on. For some reason, every so often it will self-reboot, which resets the device state to DISABLED, killing the VOD/Guide. ARGH!! So, to keep the STB working as it should, I have to attach to the Ethernet switch, manually set my IP address to the 192.168.1.0/24 net, enter the 192.168.1.1 default address, login, and reenable the COAX (Ethernet) device. What a pain, Verizon!


This also brings to light a security vulnerability in this method of double-bridging. The router automagically assigns itself this 192.168.1.1 address available from its Ethernet ports. As the Ethernet switch is bridged to the COAX (Broadband) device, this means that the router may be remotely accessible to an attack should an aggressor push spoofed RFC 1918 packets to your public IP address. They will drop off of the WAN firewall, but will the local ethernet bind to 192.168.1.1 answer? Since the Ethernet ports are set to make up the outer bridge to the WAN, this seems plausible, making for a potential hole in this setup. So much for adding security with a better firewall!