Saturday, June 27, 2015

Inexpensive and power efficient refurb PCs for firewalls

This is a follow-up on my earlier post about the Lenovo M58p (Intel Core2 Duo E8400 @ 3GHz) that I'm using for my home firewall.  It clocks in at 38-40W idle and 50-60W under load (which is rare).

If you go to NewEgg's site and go into the Desktop Computers category, you can find all sorts of refurbished boxes for under $150.

So what sort of CPUs are there and how do they stack up in terms of TDP and idle TDP?

Well, according to various charts on the net:

Intel Core 2 Duo E6600 and E6750 should both draw less power then the E8400 that I'm using.  At a guess, that would put total power draw closer to 30W idle rather then 40W.  The Core2Duo line also performs better then the old PentiumD and Pentium4 chips when under load.

So Core2Duo is better then a Pentium D or Pentium 4 chip, and the slower E6600/E6750 C2D are better then the 3GHz E8400.

The i3/i5 series (Sandy Bridge or later) should offer lower power-draw then the older Core2Duo chips.  Power draw dropped again slightly with Ivy Bridge and Haswell.

That being said, the least expensive i3 refurb is $220-$250, while a Core2Duo unit can be found for $80 or less.  So I think until the i3 units start being retired in another 2 years, the C2D units are going to be the best choice.

Monday, June 22, 2015

Using aliases pfSense to create rules for protocols with multiple port ranges

File this one under "things I wish I had known sooner".  When setting up pfSense firewall rules on an interface, you'll run into protocols which have multiple ports that are not in a contiguous range.  One example of this is the common web server (HTTP) ports of 80, 443 and 8080-8081.

This leaves you with two options.

  1. Setup multiple rules.  This is the best option because you only specify the exact ports that you want, with no extras thrown in.  The downside is that for some protocols, you will end up with multiple rules that have to be maintained.
  2. Specify a rule with a broad port range.  Which is sort of okay if you are only allowing a handful of extra ports, but it is not ideal.
Enter the concept of aliases (under the Firewall -> Aliases menu) in the pfSense web UI.  Here you can create an alias which lists out all of the ports associated with a particular protocol.


After creating the alias, you then create or edit a rule and use that alias in any fields with a red background.  Such as the destination port field.


After clicking the "Save" button, rules that are using port aliases will show up in the rule list looking like:


Needless to say, that can make your life much easier when maintaining large lists of ports as long as all of the ports in question are using the same protocols.

Mail client ports (IMAP/POP3/SMTP) are also good candidates for an alias rule.  One caution is to never allow 25/tcp to egress your network, only your mail server in the DMZ should be allowed to contact other mail servers via port 25.  Every internal client should be forced to either use tcp/465 (SMTP/SSL) or tcp/587 (SMTP Submission) or route their SMTP traffic through your mail server.



Saturday, June 20, 2015

Using badblocks to prepare an offsite USB backup drive

Part of my backup strategy is to write my backups to external USB drives which are protected by LUKS encryption.  However, before I will put a drive into service, I like to heavily test any mechanical drive for a few days to see whether it will hold up to the wear-and-tear of being a portable drive.

(There's little or no point in doing this on a SSD.)

Currently, my preferred method is to use "badblocks" in destructive write-testing mode to test the drive.  For example:

# badblocks -p 3 -wsv -t random /dev/disk/by-id/usb-SAMSUNG_HM502JX_C######-0\:0

The "-p 3" tells badblocks that the drive has to survive (3) passes without finding any new bad sectors before badblocks will stop running.  Most modern mechanical hard drives have spare sectors that can be used when a bad spot is located on the surface.  By repeatedly writing to bad or dying parts of the drive surface, we can force the drive's firmware to remap those failing areas to the spare sectors.

The downside of "-p 3" is that this increases the amount of time needed to test the drive before placing it into service.  A rough estimate is that a 1TB drive over USB 2.0 will require 3-4 days of testing with "-p 3".  If you are using a USB 3.0 drive and it is hooked up to a USB 3.0 port, then it might only take 20-30 hours to test.

The "-wsv" tells badblocks to do write-testing (which destroys all data on the drive), as well as giving status output and being verbose about what it is doing.

The "-t random" specifies that we want to use a random pattern for the test.  Please note that this is not a suitable replacement for "shred" when wiping a disk or preparing it for LUKS.  You should still run "shred" on the drive prior to using it (or giving it away to someone else).

Drives that have started to fail will often sound like they are seeking with big pauses during the badblocks write pass.  If you are seeing big pauses in reads/writes from a drive during testing, it's possible that the disk is damaged or about to permanently fail.  You will have to use your best judgement whether you trust the disk for backups.

(If I think a drive is failing, then it gets a second or third pass with badblocks and the "-p 3" option.  It will usually die during the 2nd or 3rd pass, or all of the bad spots will have been remapped and successive runs will go quickly.)

pfSense rate limiting, egress filtering, opendns filtering for wifi hotspot

One of the experiments that I'm running with the new network is running an open / unsecured WiFi hotspot for the neighbors.

Some of the protections that I'm using:

  • Uses OpenDNS servers with some categories of websites blocked.  I'm using the "OpenDNS Home" service which lets me pick and choose which categories are blocked by default.  In addition, the OpenDNS server will display a "blocked content" page for regular HTTP traffic where users can request an unblock.  Unfortunately, this feature does not work well for HTTPS (SSL) sites, but it still blocks the site.
  • Access to other DNS servers is blocked, clients can only access the two OpenDNS server IP addresses.
  • All rules on the interface are rate-limited to 3Mbps down and 1Mbps up.  This limits bandwidth abuse and slows down file sharing.
  • Heavy egress filtering.  All outbound traffic is blocked by default except for the whitelisted ports/protocols.


Now, this is not 100% foolproof.  But I at least want to limit the possible damage and take at least some steps against abuse.  I'll probably use this setup at a company that I'm consulting for where they want to offer open WiFi in their waiting area.

One thing I would like to do is setup a "Captive Portal" on the interface which forces the user to enter their cell phone number and receive a voucher code via SMS that is good for 3 or 7 days.  I have to figure out how to do that with pfSense and see how it works in practice.

The other thing I plan on doing is setting up a similar SSID/VLAN, but with higher bandwidth limits, more ports and no OpenDNS filtering for authenticated guests.  That would probably be a 20Mbps down / 5Mbps up setup protected by WPA2/PSK.  Think along the lines of "neighbors" or "friends" who you want to allow use of the internet pipe, but do not want to allow onto your interior network.  This would also be a good setup to use in an office environment for BYODs that only need internet access (such as clients).

Sunday, June 14, 2015

pfSense on Core2Duo E8400 refurbished PC

A rough power estimate for my little SFF (small form factor) refurbished PC that I'm using for a pfSense firewall:

  • Intel Core2 Duo E8400 @ 3GHz
  • 4GB RAM
  • 120GB SSD
  • Dual-port Intel PCIe x4 NIC
At idle, it consumes about 38W when the CPU throttles back to 1.8GHz.  That's pretty good for a PC that is not designed to be a low-power / fanless unit.  Under load, that goes up to about 60-65W.

38W @ $0.15/kWh = $50/yr
65W @ $0.15/kWh = $85/yr

So even if I got something that stayed below 15W, I'd only save $50-$60/yr.  A lot of the low power units are $300-$500, which would be a very long time before they'd pay off.

Note: You do need to enable PowerD under System -> Advanced -> Miscellaneous -> Power Savings in order to get the CPU to throttle down when idle.  I recommend "Hiadaptive" for an office firewall, but you might want to experiment.

The biggest CPU hog on my current pfSense setup is "ntopng".  While doing bi-directional gigabit testing, that ate up 10-12% of my CPU power.

Tuesday, June 09, 2015

pfSense Firewall CPU load estimate

According to the pfSense dashboard, I have:

Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
2 CPUs: 1 package(s) x 2 core(s)

When running a quick speed test, "top" shows about 5% system load at 60Mbps.  That gives a rough upper-end of around 1200Mbps (1.2Gbps) for switching speed.  At a guess, that might be closer to only 1Gbps performance under heavy traffic.

1Gbps of capacity is plenty for the moment where I have:

- 50/50 Mbps service from Verizon FIOS (seems to peak at 60/60)
- 802.11 b/g/n (11-54Mbps)
- 802.11ac (tops out at around 1Gbps)

But it may not be enough for connecting together multiple gigabit LAN segments.  So I will need to keep all high bandwidth traffic on the same VLAN so that the traffic gets handled by the switches without touching the pfSense firewall.

VLAN adventures with Netgear GS108T and TrendNet TEW-814DAP

As part of setting up my new home network, I'm experimenting with VLANs.  The pfSense firewall has the following user-defined VLANs on the interior port.  Each of these VLANs has a separate address range (all are IPv4 with a 24-bit netmask, i.e. 192.168.10.0/24). The pfSense firewall is always the ".1" address on each network segment and routes traffic between the segments.

em0 / 12 - Unsecured Guest WiFi
- This will (probably) be the VLAN used for an access point that is not password protected or that encrypts traffic.  I plan on limiting it to 1Mbps, plus put a SMS-authentication captive portal on it, plus point it at OpenDNS with heavy filtering.

em0 / 24 - Secured Guest WiFi
- This will be protected with an easy-to-enter WPA2/PSK password.  Suitable for handing out to people that I marginally trust or know.  No access to the internal LAN, and only selected ports allowed out.

em0 / 36 - Internal Guest WiFi
- Protected with a moderate strength WPA2/PKS password.  Suitable for friends.  Wide open access to the internet, limited access to the internal LAN.

em0 / 48 - Internal WiFi
- Protected via WPA2/PSK with a strong password.  Has full access to the internal LAN.

em0 / 87 - LAN
- This is the internal LAN network.

em0 / 100 - Infrastructure.  In a normal shop, all switches / APs would be members of this VLAN and management would only be allowed via this VLAN.

em0 / 999 - Blackhole VLAN ID (nothing should ever listen here).

That's the easy part, defining the various VLANs.  Those same VLAN IDs have to be configured in the GS108T switch as well.  This is done under Switching / VLAN / VLAN Configuration.


Note that the first three defined VLANs (1/2/3) are hard-coded into the GS108T firmware and cannot be removed.  As I indicated in a previous post on the subject of VLAN security, you should avoid using VLAN #1 for anything.  And now I would amend that to say that you should avoid VLAN IDs 1-9.

There are a few key pieces to think about when setting up VLANs:

Inbound #1 - Are the packets already tagged when they reach the switch (inbound) from another device (i.e. switch or WiFi Access Point)?

Inbound #2 - Should untagged (no VLAN header) packets inbound to the switch be blocked/dropped?

Inbound #3 - What VLAN should untagged packets be assigned to on inbound?

In the GS108T, the inbound concerns are handled under Switching / VLAN / Port PVID Configuration.  This screen will allow you to apply a VLAN tag as packets enter the switch.


In the case of the WiFi Access Point which is attached to "g2", it does not support VLAN tagging of the various SSID networks, so we have to treat it as a "dumb" device.  So when the WiFi sends packets to the switch they get assigned to VLAN #48.

Outbound #1 - Should the VLAN header be stripped as the packets leave the switch via a particular port?

Outbound #2 - Does the device attached to this port understand VLAN tags?

Outbound #3 - Should untagged packets be blocked from exiting via this port?

Egress handling is configured through Switching / VLAN / VLAN Membership and is somewhat unintuitive in the GS108T user interface.  You need to read this screen as:

"If a packet that belongs to VLAN ## is traversing the switch and about to egress (exit/outbound), what ports is it allowed to leave by and what should happen to the VLAN header?"

In the case of VLAN #48 (Internal WiFi), the answers to that are:
  • VLAN #48 is only allowed to egress via port "g2" and port "g3". 
  • "g2" is our "dumb" WiFi Access Point
  • "g3" is the "smart" pfSense firewall that understands VLAN tags
  • Packets going to the WiFi Access Point need to have VLAN headers stripped
  • Packets going to the pfSense firewall should have VLAN headers left intact


The above shows that any packets on VLAN 48 are only allowed to leave untagged (U) via "g2" (WiFi AP) or tagged (T) via "g3" (pfSense firewall).


Monday, June 08, 2015

Checking authorized_keys for duplicate SSH key lines

After a while, unless you are using Puppet or some other tool, your ~/.ssh/authorized_key file will end up with half a dozen or dozens of different SSH public key lines.  And depending on how careful you were, some of them may be duplicates or screwed up.

One way to make sense of the madness is to look at the first N bytes of each line in the ~/.ssh/authorized_keys file and look for strangeness.

$ cut --bytes=1-80 ~/.ssh/authorized_keys 
ssh-dss AAAAB3NzaC1kc3MAAACBAP0090dCcnFwtuP9Rmjgf7eHR20JdmHASXS+un4cAKNYpwHIDlA9
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7
qDkz/87jwJ0jufKy7XQyiiwHGg7GvqMej8enLCN90wc4xOTrFUO9FaSinWGOJmtdjVH8m7oXZ+OfClOX
h1o14nqandnzYPNyOH7iHZyVcAl082Ua1nmsesrAj7ilNPLZFiQhGhPAbWPz/O9dVBvfW+I5stRgb7FD
014

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsrOtkkIXu0ci/8h79/zCFgAoDZgw6yQExBs4o/KjfmB/

Just by looking at the above output, I can see that the second ssh-rsa key line was not placed on a single line as it should have been, but has line breaks.  After a quick edit of the file, now the output looks like:

$ cut --bytes=1-80 ~/.ssh/authorized_keys
ssh-dss AAAAB3NzaC1kc3MAAACBAP0090dCcnFwtuP9Rmjgf7eHR20JdmHASXS+un4cAKNYpwHIDlA9
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsrOtkkIXu0ci/8h79/zCFgAoDZgw6yQExBs4o/KjfmB/

Now I can run the output of that through sort/uniq to see whether I have any duplicate SSH public key lines:

$ cut --bytes=1-80 ~/.ssh/authorized_keys | sort | uniq -c -d
      5 
      2 ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAZB+mI3xeVeYo3B2yJqvQYUpVBrNtMmtd3iAj6O6pMIvRGzm
      2 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC54VI+7J1DoEEiJml8JusdM4M9UNNIA8gv/JER7rQ7

Looks like I do have a pair of duplicated SSH public key lines.  This is a good thing to know because if was trying to remove a particular SSH key pair, I might remove one line but not see the other.

Friday, May 22, 2015

Firewall build (part 3) VLAN Security

Since I plan on using VLANs on the WiFi Access Points to separate guest vs friend vs trusted traffic, I need to make sure that I'm doing VLANs in a secure fashion and not leaving any large holes.

The primary recommendations from the listed sources are:

  • Don't use VLAN 1 (the default VLAN) for anything
  • Any ports that do VLAN trunking should use a dedicated VLAN ID
  • Do explicit tagging of the native VLAN on trunking ports
  • Set all end-user ports to non-trunking (a.k.a. "access ports"?)
  • Disable unused ports and put them in a separate VLAN
  • Disable Spanning Tree Protocol (STP) on end-user ports
  • Use MD5 authentication for Virtual Trunking Protocol (VTP)
  • Physically secure the switch and control access to the management functions


Reference Links:

  1. Virtual LAN Security: weaknesses and countermeasures (SANS)
  2. VLAN Hacking (InfoSec Institute)
  3. VLAN Hopping (Wikipedia)

Thursday, May 21, 2015

Firewall build (part 2) hardware needed for VPN duties

One thing to think about when sizing the hardware for a firewall is how much CPU power will be needed for OpenVPN (or IPSec / L2TP).  OpenVPN comes with a built in "speed" command which will benchmark your system and give you an idea of maximum possible bandwidth.

Just run "openssl speed" at the command line and look for the AES-128 and/or Blowfish results.  I prefer to look at the 1024 byte or 8192 byte columns in the output to figure out the upper range.  While Blowfish is good at the smaller block sizes, AES-128 catchs up and surpasses it with the larger block sizes.

Values at or above 100000k should indicate that the firewall has enough performance to drive an OpenVPN connection at close to gigabit speeds.  Or handle multiple OpenVPN connections at the same time, without completely saturating the CPU.

AMD Opteron 2210 HE @ 1.8GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
blowfish cbc     68358.84k    74350.46k    75845.03k    76373.67k    76556.97k
aes-128 cbc      50477.29k    53816.28k    55093.08k   128709.63k   130465.79k

AMD Phenom II X4 810 @ 2.6GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
blowfish cbc     94477.65k   101825.28k   103154.35k   103857.83k   104060.25k
aes-128 cbc      76376.65k    81608.09k    83915.50k   213516.45k   216016.95k

AMD Opteron 4180 @ 2.6GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
blowfish cbc     93781.75k   101154.41k   102983.68k   103730.52k   103923.71k
aes-128 cbc      76233.64k    81631.07k    83197.52k   213366.89k   215309.87

103720k = 98 MiB/s or ~980Mbps, which is pretty close to gigabit speeds

General guidelines/notes:

  • I'm a firm believer in multi-core for servers and desktops.  So look for hardware that is at least dual-core when shopping.  An inexpensive quad-core would be even better and give a bit of headroom for monitoring tasks.
  • For the AMD CPUs (Opteron / Athon64 / Phenom) made in 2007-2011, you'll want at least a 2.2GHz core.  For Intel Core2 CPUs or 1st/2nd generation i3/i5, try to get at least a 2.0GHz core.
  • Intel Atom CPUs are underpowered, the 1.8GHz dual-core units are reported to top out at around 500Mbps for general routing and definitely can't handle gigabit speed OpenVPN.  But they are low power, so maybe that outweighs the performance issue.  A rule of thumb is that the Atom CPUs are about 1/3 to 1/2 as powerful as i3/i5 for the same clock speed.


Resource links:

Sunday, May 17, 2015

md5sum bash script to create check file for a directory tree

Just a quick script that will run through the current directory and all descendant directories, creating a single "verify-tree.md5" file (using md5sum). If the check file already exists, then the existing one gets moved out of the way to "verify-tree.yyyymmdd-hhmmss.md5" for safekeeping.

Check files are useful for whenever you have a set of files that will not (or should not) change over time.  Such as files written off to an archive tape / disk / optical media / flash drive.  While the media and file system might also do some checking, it's good to have a second layer that is under your control and which can be queried.

(If you want file recovery features, you should look into MultiPar or par2j.)

The script's output looks like:


The file (verify-tree.md5) that is created is a standard md5sum file and can be read by just about any compatible software.  Some software cannot handle sub-folders, however, so you may have to use the md5sum program to do the verification.

----------------------------------------------------------------
#!/bin/bash

# stop script on errors
set -e

PROG=md5sum
FILENAME=verify-tree

if [[ -e "${FILENAME}.md5" ]]; then
    mv "${FILENAME}.md5" \
    "${FILENAME}.$(date --reference=${FILENAME}.md5 '+%Y%m%d-%H%M%S').md5"
fi

echo ""
echo "Output Filename: ${FILENAME}.md5"
echo "Files Found: $(find . -type f -not -name "${FILENAME}*.md5" | wc -l)"
echo "Size: $(du -chs . | grep 'total')"

time find . -type f -not -name "${FILENAME}*.md5" \
    -exec ${PROG} "{}" \; >> "${FILENAME}.md5"

echo ""
echo "Files Processed: $(wc -l ${FILENAME}.md5)"

echo ""
echo "Checking..."
time ${PROG} -c --quiet "${FILENAME}.md5"
echo ""
echo "All files verified."
----------------------------------------------------------------

Note: There are multiple ways to write the md5sum line.  It's probably better to use the xargs method, but I have not tested it out.

find . -type f -not -name "${FILENAME}*.md5" -exec ${PROG} "{}" \; >> "${FILENAME}.md5

find . -type f -not -name "${FILENAME}*.md5" -print0 | xargs -0 ${PROG} >> "${FILENAME}.md5"

find . -type f -not -name "${FILENAME}*.md5" | xargs ${PROG} >> "${FILENAME}.md5"

It's also easy to adapt this script to work with sha256sum or sha1sum.


The verification script is a trimmed down version of the original script:

----------------------------------------------------------------
#!/bin/bash

# stop script on errors
set -e

PROG=md5sum
FILENAME=verify-tree

echo ""
echo "Checking: ${FILENAME}.md5"
echo "File Hashes: $(wc -l ${FILENAME}.md5)"
time ${PROG} -c --quiet "${FILENAME}.md5"
echo ""
echo "All files verified."
----------------------------------------------------------------

I have tested this in CygWin 64-bit on Windows 7 64-bit Professional, but it should also work fine on Linux/Unix/OSX systems as long as the md5sum command is available.  The script is conservative in design with very few "tricks" so it should be portable.

Sunday, May 10, 2015

MD5 vs SHA-1 vs SHA-256 performance

I was curious this weekend about how MD5 vs SHA-1 vs SHA-256 performance stacks up.  If you have the OpenSSL libraries installed, you can run a short test to calculate performance on your CPU.  It gives ballpark estimates, which may or may not carry over to real-world performance on actual file data.

$ openssl speed md5 sha1 sha256

Estimates/Summary:

SHA-1 is about 55-75% the speed of MD5
SHA-256 is about 25-40% the speed of MD5
SHA-256 is about 50-60% the speed of SHA-1

Whether or not you will be CPU-bound in computing the file hashes will depend on where you are reading the files from.  Over gigabit LAN or from older mechanical hard drives, or external USB2/USB3 drives, most modern CPUs can keep up even with SHA-256.  But if you are reading the files off of a local SSD or really fast mechanical drive (or RAID) then you are likely to be bottlenecked by the CPU.

Details (openssl test):

AMD Opteron 2210 HE @ 1.8GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              25350.32k    80336.17k   191208.72k   295806.29k   353239.04k
sha1             27497.51k    77933.74k   168168.28k   235850.41k   268205.53k
sha256           22543.94k    51445.66k    88818.90k   108275.37k   116416.81k

AMD Opteron 6212 @ 2.6GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              45318.86k   134308.27k   324486.83k   493194.58k   582216.36k
sha1             47027.79k   128927.42k   278593.02k   410244.44k   471425.02k
sha256           28690.18k    62662.12k   106333.61k   127998.98k   136325.80k

AMD Opteron 1214 @ 2.2GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              30417.85k    96951.65k   235868.24k   361845.33k   433094.16k
sha1             34126.39k    98072.04k   208456.70k   291041.35k   328654.85k
sha256           27362.92k    63127.50k   108537.35k   132564.38k   142727.86k

AMD Opteron 4180 @ 2.6GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              43180.73k   129437.27k   298339.15k   442248.19k   519602.18k
sha1             45699.96k   123160.41k   255322.20k   347329.88k   390250.50k
sha256           33757.18k    75191.85k   128929.37k   157659.82k   168790.70k

Intel Xeon E5520 @ 2.27GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              25945.50k    88897.43k   220292.01k   354356.91k   430339.41k
sha1             26568.69k    78716.78k   174506.35k   251495.08k   288858.11k
sha256           20495.77k    49206.73k    90735.59k   114904.75k   124605.78k

AMD Phenom II X4 810 @ 2.6GHz
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              42430.27k   130101.07k   301091.11k   444996.84k   522918.05k
sha1             46015.86k   125298.40k   256391.07k   349968.95k   393227.03k
sha256           34432.84k    76378.03k   130828.67k   158859.76k   168782.78k

Additional tests/experiments:

Tests using "(sha256|sha1|md5)sum" programs on Opteron 4180 w/ SSDs, using 133GB of large files.  The CPU core assigned to the task was pegged at 100% utilization according to "atop".  The SSD used has an estimated top speed of 490 MB/s.

MD5: ~318 MiB/s (428 sec)
SHA-1: ~187 MiB/s (729 sec) - 1.7x slower then MD5
SHA-256: ~113 MiB/s (1204 sec) - 2.8x slower then MD5, 1.65x slower then SHA-1

Sunday, April 26, 2015

Firewall build (part 1)

Part of moving to a new place is reevaluating your network.  On my current network, I have a fairly basic setup:

  • One WiFi Access Point (WAP) running 802.11 b/g
  • A Linux server acting as firewall / file share / backup storage
  • A few laptops
  • A few tablets/phones
  • A few other PCs
When I set this all up a few years ago I kept it very simple.  The Linux server is the gateway device with routing / filtering / NAT and other features.  The WAP is part of the internal network running in WPS/PSK mode with a very long and randomly generated password.

After I move, I want to accomplish a few things:
  • Use a refurb or low-power PC to run just the firewall / VPN
  • Put the WiFi access point on a separate NIC
  • Possibly run a DMZ
  • Provide limited guest WiFi
  • Evaluate pfSense instead of Linux+Shorewall
To do all that, I need a minimum of four network ports for perfect security or something with two ports if I use VLANs (not as safe, more difficult to configure and get right).

I've done some looking around and while a low-power 25-35W compact PC for the firewall would be nice, it would cost me around $600.  Maybe $400-$500 if I shop around.  There are also the really tiny units that will run monowall (m0n0wall), but those are also $200-$300 for something that will handle the faster WiFi / FIOS / cable modems.  Plus it can be difficult to find something with four network ports.

Firewalls don't need a lot of CPU power, but a dual/quad CPU Intel Atom isn't enough.  An i5/i7 would likely be complete overkill, even for 802.11ac / 802.11n or gigabit traffic.  The older Pentium / Celeron / Core Duo are probably a bit on the slow side.  The AMD Phenoms or Athlon64 chips are probably okay.

So what I've settled on is a refurbished PC that is at least a Core 2 Duo (2 cores) with 4GB of RAM, along with a refurbished NIC.  The pfSense distro only needs a handful of gigabytes to install, so any unit with at least 40GB of space will be plenty.  The base units can be picked up for as little as $50-$125 for the base computer, and add-in NIC cards are $10-$40 depending on what you use.  If the box dies, I get another and move the drive over.  If one of the NICs fry, I can pickup another NIC.  Power requirements will probably be around 80W to 120W.

For the smaller sized PCs, you might only have 1-2 expansion slots which means you'll need a multi-port NIC. The cost of the dual-port NICs is likely to be more then what you pay for the base PC.  I've seen dual-port refurbished NICs for as low as $50, but paying $100-$150 is more likely.  However, good NICs tend to work fine for close to a decade, and it can be moved from PC to PC.

Friday, August 08, 2014

Postfix: Calculate number of TLS encrypted SMTP sessions

I was curious as to what amount of SMTP traffic is encrypted to our servers.

This assumes that you are running Postfix, and you might need to adjust smtpd_tls_loglevel to be 1 or 2.  I'm not sure if this catches all instances where the SMTP connection switches to SSL, or just those that support TLS.

# fgrep 'postfix/smtpd' maillog* | fgrep ': connect from' | wc -l
# fgrep 'postfix/smtpd' maillog* | fgrep ': setting up TLS connection' | wc -l

One box #1 that we have at the office:

16151 out of 293746 connections were TLS (5.5%)

On box #2:

27485 out of 654294 connections were TLS (4.2%)

A very rough estimate is that one connection = one message delivered to the server.  Assuming that is true, only 4-5% of SMTP traffic to our domains (via port 25/tcp) is sent over an encrypted channel.  On the other hand, probably 90% of all of our connections are spam zombies who probably don't do TLS.  In order to dig deeper, I would have to tie every non-spam message to a specific connection in the Postfix log file.

Thursday, October 03, 2013

Install GRUB onto multiple boot disks in Software RAID-1 (quick reference)

Here is an example where I have a 3-way RAID-1 array. The /boot partition is stored at /dev/md0. This installs GRUB to each disk, so that if one disk fails, you can boot off one of the other disks.

# grub
grub> find /grub/stage1
 (hd0,0)
 (hd1,0)
 (hd2,0)
grub> device (hd0) /dev/sda
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdc
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

With this you should be able to now boot from any of the disks in the RAID-1 array, no matter what boot order you set in the BIOS.

For safety, I suggest using UUIDs in your /etc/fstab file for your /boot and / (root) partitions. This way the machine will boot off the UUIDs of the file systems, even if mdadm (software RAID) decides to renumber your /dev/md# devices. Note: This is the default behavior in RHEL 6 / CentOS 6.

Monday, September 09, 2013

View and changing the SSH HostKey files

With all of the NSA leaks in the past few months, I figured it was a good time to go look at the SSH keys that we use on the servers and decide whether we want to re-key things. Naturally, this is a bit of a PITA because you'll have to let all clients know that the SSH host key changed and users will have to edit their ~/.ssh/known_hosts file.

First off, let's look at the current key information (using the "-l" option to display the signature, and the "-f filename" option to look at an existing file):

# /usr/bin/ssh-keygen -l -f /etc/ssh/ssh_host_dsa_key
1024 86:72:0c:d8:47:ce:c4:4a:79:25:9b:ad:22:1b:de:87 /etc/ssh/ssh_host_dsa_key.pub (DSA)
# /usr/bin/ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key 
3072 2b:3d:27:77:49:bf:05:09:ee:b7:74:68:e8:f3:fc:3f /etc/ssh/ssh_host_rsa_key.pub (RSA)

This displays a few useful pieces of information:

#1 - The key size is 1024 for the DSA key. All DSA keys are 1024 bits in size due to FIPS 186-2 (Federal Information Processing Standard 186-2). While there is a newer FIPS 186-3 and FIPS 186-4 standard that allows larger DSA keys, I'm not sure how well supported it is in OpenSSH.

My RSA key is 3072 bits in size instead of the default 2048 bits in CentOS 6. Older releases had a default of only RSA/1024 bits, which is considered to be a bit weak today. The current recommended minimum is 2048 bits and the maximum in common use is 4096 bits.

A good read is Anatomy of a change - Google announces it will double its SSL key sizes.

#2 - The key signature, which should be communicated to your users via out-of-band communications.

To re-key, I suggest using the following for DSA keys:

# /usr/bin/ssh-keygen -N '' -C 'servername SSH host key Sep 2013' -t dsa -f /etc/ssh/ssh_host_dsa_key
Generating public/private dsa key pair.
/etc/ssh/ssh_host_dsa_key already exists.
Overwrite (y/n)? y
Your identification has been saved in /etc/ssh/ssh_host_dsa_key.
Your public key has been saved in /etc/ssh/ssh_host_dsa_key.pub.
The key fingerprint is:
86:72:0c:d8:47:ce:c4:4a:79:25:9b:ad:22:1b:de:87 severname SSH host key Sep 2013

For RSA keys, you need to change "-t dsa" to "-t rsa", change the filename, and add a "-b 2048" option before the "-f filename" option. Suggested key sizes are 2048 for short-term, 3172 for 1-2 decades, and 4096 for keys that will be in use past 2030. The downside is that as key length doubles, performance drops by a factor of 6-7x.

Friday, August 23, 2013

Linux server partitioning with mdadm software RAID and LVM2

Over the years, I've really come to appreciate what judicious use of LVM (or LVM2) brings to the table when administering servers. If you rely on it heavily and leverage it properly, you can do things like:
  • Snapshot any file system (other then /boot) for backups, or to make images, or to test something out.
  • Migrate a logical volume (LV) from one physical volume (PV) to another, without having to take the file system offline or deal with downtime.
  • Resize file systems that are too large or too small, with minimal downtime (if the file system supports it).
Basically, other then /boot, if you're thinking of creating a separate partition or Software RAID device the you should be using LVM instead of physical partitions or RAID devices. You gain a lot of flexibility in the long-run and setting up LVM on top of hardware or software RAID or plain old disks is no longer that difficult.

These days, when I setup disk partitions to hold a server's boot-up files, I only create (2) partitions on the drive. One for the Software RAID-1 mirror set to hold /boot (usually 256-1024MB) and the rest of the drive is a second RAID-1 mirror set that is turned into a LVM physical volume (PV) and assigned to a volume group. I will usually only partition out to about 99% of the drive size if I'm doing Software RAID, because that makes it easier later to put in a different model disk of the same capacity and still have things work. Drives from different manufacturers have slightly different capacities, so you can run into trouble down the road when you go to replace a failed drive if you assumed all drives were exactly the size as your original drives.

Inside that LVM volume group (VG), I create all of my other partitions. These days, that means:
  • / - the "root" partition, usually 16-32GB for CentOS 6
  • /home - Usually starts at 4GB for a server where people won't be logging in much.
  • /opt - 4-24GB
  • /srv - 1-4GB (sub-directories get their own LV later)
  • /tmp - 4-24GB
  • /usr/local - 8-24GB
  • /var - 4-24GB
  • /var/log - 4-24GB
  • /var/spool - 2-4GB to start
  • /var/tmp - 2-8GB to start
And that's just the basic operating system file systems. For things like squid, e-mail, web servers, samba shares, etc., each of those will get its own LV, allocated from the server-wide volume group.

Follow ups:
  • GRUB2 understands mdadm (software RAID) and LVM. So we will eventually be able to put /boot in an LVM volume. But the GRUB that ships with RHEL6 and CentOS6 is still GRUB 0.97.

Sunday, August 18, 2013

TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48

Here's a fun error message that we're getting on our mail server at the office:

Aug 15 10:52:26 fvs-pri dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=172.30.0.221, lip=172.30.0.1, TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=

The odd thing is that using public SSL testing tools (such as the one at DigiCert) do not indicate any problems with the mail server's SSL configuration. And this only seems to affect some clients, and is possibly only acting up with Dovecot. So my guess is that Apache/OpenSSL is configured correctly, but Dovecot is not.

The key to figuring this out is the "openssl s_client" command:

openssl s_client -connect mail.example.com:143 -starttls imap

This showed us that the openssl library was having problems validating the server's certificate, because the intermediate certificates were not also stored in the certificate file that gets sent to the client. The solution is to adjust the file pointed to by Dovecot's "ssl_cert" argument and add your certificate vendor's intermediate certificates to the end of the file.

The order of the certificates inside that file matters. Your server certificate needs to be first, then list the rest of the certificates in order as you move up the certificate chain to the root CA.

Wednesday, August 14, 2013

LUKS: /dev/mapper "read failed after 0 of 4096 at 0: Input/output error"

We're using external USB drives for our backups, protected using LUKS/cryptsetup. On our 3-4 year old Opteron 2210 HE CPU running at 1.8GHz, we estimate that LUKS can perform about 60-70 MB/s per CPU core. We mount the LUKS volumes automatically (at server boot) by listing them in /etc/cryptsetup and using a key-file instead of having to enter a password and autofs handles the automatic mounting/dismounting of the ext4 file system inside the LUKS volume.

It all works very well, until you remove the USB device and then run pvscan/lvscan commands of LVM. Which then throws the following errors:
# pvscan
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 999201636352: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 999201693696: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 0: Input/output error
  /dev/mapper/USBOFFSITE12B: read failed after 0 of 4096 at 4096: Input/output error
  PV /dev/md12   VG vg13   lvm2 [2.67 TiB / 821.62 GiB free]
  Total: 1 [2.67 TiB] / in use: 1 [2.67 TiB] / in no VG: 0 [0   ]

If 'autofs' would allow us to execute a script after it dismounts the drive from inactivity, it might be a good option for us. But I'm not sure that is possible.

Another option would be that at the end of the daily backup script which copies files off to the attached device, we dismount it automatically.

A third option would be to check every hour and see whether the /dev/mapper/NAME is no longer in use, then tell cryptsetup to dismount it. The command to check that might be "dmsetup ls --tree -o uuid,open | grep -i 'CRYPT-LUKS'".

Still exploring options at this point. I need to do some more testing first. I'm also searching for a way to auto-open LUKS volumes upon device insertion.

Monday, August 12, 2013

Auto-mounted external USB drives with Linux autofs daemon

This explains how to use 'autofs' to automatically mount external USB hard drives at a predictable path under CentOS 6 (but probably also works for CentOS 5, RHEL 5, RHEL 6, etc.). On one of my Ubuntu desktops; file systems on USB drives get automatically mounted, but that requires a GUI environment to be installed. On our servers at work, we generally do not install a GUI environment. We also had some special requirements in order to use the USB drives as backup targets:
  • The USB drive needs to mount at a standard location. Such as /mnt/offsite/LABEL or something. This way the backup scripts are not overly complex.
  • Mounting needs to be automatic, without any user intervention.
  • Ideally, the file system should be dismounted when not in use. That way the user who swaps out the backup drives only needs to check the drive activity light before knowing that it is safe to swap out the drive.

So the standard Ubuntu method of doing things via Gnome comes close, but I explored other options as well. The one I settled on is called 'autofs'. It is a script/daemon that is found in the standard CentOS 6 repositories, so you just need to run "yum install autofs".

Configuration of the autofs daemon consists of two parts:

A. You need to find and edit the master configuration file for autofs, also called the 'master map file'. Under CentOS 6, this is located at /etc/auto.master, or you can look at '/etc/sysconfig/autofs ' to find out the configuration file location.

If you want to mount your USB backup drives at /mnt/offsite/XYZ, then your auto.master file only needs to contain the following:

# USB backup drives
/mnt/offsite            /etc/auto.offsite       --timeout=1800

As you can see, you tell autofs the location, what configuration file to look at for devices that need to be mounted, and optional arguments such as custom timeout settings. Note that you need to create the location directory by hand (e.g. "# mkdir /mnt/offsite") before starting autofs.

B. The second part of configuration is telling autofs which devices should be automatically mounted. It is best if you use either the UUID of the partition (/dev/disk/by-uuid/XYZ) or the device ID (/dev/disk/by-id/XYZ-part0).

OFFSITE1 -fstype=ext4,rw,noatime,data=journal,commit=1 
    :/dev/disk/by-uuid/b5c1db0d-776f-499b-b4f2-ac53ec3bf0ef

Please note that the above should be all on line line, I have broken it up for clarity.

The only real mount options that you need is "fstype=auto,rw,noatime". I have added "data=journal,commit=1" to make the ext4 file system on the drive a bit more resilient.

One limitation of autofs is that if you have multiple USB drives to be mounted, each one needs its own unique mount point (/mnt/offsite/OFFSITE1, /mnt/offsite/OFFSITE2, etc.). However, you could decide to mount all of the drives at the same location if you give them all the same UUID. But I'm not sure how well autofs would deal with two drives, having the same UUID, being hooked up to the server at the same time.



After editing your mapping file, you (probably) need to restart autofs. Assuming that you have done everything correctly, attempting to list the contents 'ls -l /mnt/offsite/OFFSITE1' will cause the drive to be automatically mounted. After the timeout period expires, the drive will automatically dismount.