FreeBSD Disk Performance on a Cloud VPS with vfs.read_max
After getting setup on a new VPS running in the cloud via ToggleBox, I was browsing the Knowledge Base and came across this interesting tidbit:
Our SAN is optimized for random IO as that is more typical in a hosting environment. Enabling readahead under Linux will greatly increase sequential reads.
blockdev --setra 16384 /dev/xvda1Replace /dev/xvda1 with /dev/sda1 on older distributions. You can add this command to /etc/rc.local to make it persistent across reboots.
Because I am running FreeBSD 8.2-STABLE, the above tweaks do not apply to me. However, FreeBSD does have a vfs.read_max kernel tunable that behaves in much the same way. The default setting is very low, being set at a value of 8.
Some benchmarks of various settings I tried using bonnie (-s 8192) because I have 4GB RAM on this machine:
vfs.read_max=8 (default):
File './Bonnie.1614', size: 8589934592
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---------------------Sequential Output-------- ---Sequential Input-- --Random--
---------------Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
......8192 49868 24.6 50477 10.1 15540 4.0 33310 18.2 40572 7.0 235.9 1.5
vfs.read_max=128
File './Bonnie.2275', size: 8589934592
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
---------------------Sequential Output-------- ---Sequential Input-- --Random--
---------------Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
.......8192 48717 24.0 52936 10.9 15433 3.9 58900 33.9 66069 13.0 406.7 2.4
As you can see, sequential input and random seeks and reads are much, much faster with a higher read_max value set, while writes remain about the same.
Encode Video for Android using Handbrake
Here's a quick one-liner to encode videos for playback on Android phones using Handbrake:
HandBrakeCLI -i "$1" -o "$2" -I -e x264 -q 0.61 -a 1 -E faac -B 128 -R 44.1 -6 stereo -f mp4 -X 800 -m -x level=30:bframes=0:cabac=0:ref=2:vbv-maxrate=1500:vbv-bufsize=2000:mixed-refs=1:analyse=all:me=umh:no-fast-pskip=1:psy:0:psy-rd=0,0:subq=6:subme=6:no-dct-decimate=0:8x8dct=0:trellis=0:weightb=0
Blocking SSH Brute Force attempts with OpenBSD’s pf
As anyone with a public facing IP address knows, you will eventually see massive amounts of bruteforce attempts on your SSH port by script kiddies attempting to gain access:
...
Mar 15 12:02:34 prime sshd[6518]: Invalid user nagios from 50.23.135.86
Mar 15 12:02:35 prime sshd[6520]: Invalid user nagios from 50.23.135.86
Mar 15 12:02:36 prime sshd[6522]: Invalid user weblogic from 50.23.135.86
Mar 15 12:02:37 prime sshd[6524]: Invalid user weblogic from 50.23.135.86
Mar 15 12:02:38 prime sshd[6526]: Invalid user weblogic from 50.23.135.86
Mar 15 12:02:39 prime sshd[6528]: Invalid user ftp1 from 50.23.135.86
Mar 15 12:02:39 prime sshd[6530]: Invalid user ftp1 from 50.23.135.86
Mar 15 12:02:40 prime sshd[6532]: Invalid user ftp1 from 50.23.135.86
...
While there are several methods for blocking these attempts, such as denyhosts, I was looking for a simpler solution. I am already running OpenBSD's pf on my FreeBSD VPS, so a solution using pf seemed like the way to go. While FreeBSD has a handbook entry on how to accomplish this, I found a site that explains how to do this with two simple rules.
The first rule, which should be early in your rules configuration will block all inbound traffic from hosts that are in the ssh-bruteforce table:
block drop in quick on $ext_if from <ssh-bruteforce>
The rule says "block all packets from any hosts in the ssh-bruteforce table without processing any more filter rules." This rule is useless without anything in the ssh-bruteforce table, so the next rule is where the magic happens:
pass in on $ext_if proto tcp from any to ($ext_if) port ssh \
flags S/SA keep state \
(max-src-conn-rate 3/30, overload
This rule uses pf's max-src-conn-rate to start populating the ssh-bruteforce table. This rule tells pf to allow inbound connections on port 22 but if any host tries to connect more than 3 times in 30 seconds, add that host to the ssh-bruteforce table, effectively blocking that host from connecting at all. Examining the table after a few hours or days, we see:
prime# pfctl -t ssh-bruteforce -T show
24.222.76.98
58.68.231.29
60.191.121.170
61.180.240.17
88.191.63.71
...
This table can fill up fast if you have a lot of bruteforce attempts, so a cron script to flush that table at times may be necessary.
Of course you can tune your rule for different time lengths and number of connections, but be careful not to lock yourself out by setting the values too low. To an attacker it appears as if your server disappeared and they will move on to the next target and leave you alone. I think this is a clean, elegant solution, and works well.
SSH through an ISA proxy with NTLM Authentication
The problem arose as I was trying to connect to my home computer and VPS via SSH at work and was blocked by an ISA proxy with NTLM authentication. Although programs like puTTY can use a proxy for connections, they cannot authenticate against NTLM, effectively blocking outbound connections.
After searching around on Google for a while, I ran across a NTLM Authorization proxy written in python that authenticates to the ISA proxy and creates a local proxy for your programs to use. To get it running, you simply edit a small configuration file, enter your relevant details, and then run the server. It runs in a Windows command prompt and creates a proxy on the port you specified in the configuration file.
After you get the proxy server running, getting puTTY to connect is a breeze. Simply tell putty to connect via your local proxy, and it will instantly go through the ISA proxy, connecting to your outside host.
The next problem I encountered after getting the proxy setup was the ISA's refusal to allow a secure connection on port 22. The error message I got was:
Proxy error: 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
Basically, I couldn't go through the proxy on the standard SSH port 22. A simple sshd_config tweak fixed that:
/etc/ssh/sshd_config
Port 22
Port 443
This tells the OpenSSH daemon to listen on both ports 22 and 443. Of course, if you have an SSL enabled webserver running, this won't work for you, but if not, it works great.
After you restart your SSH daemon, you should be good to go. Hopefully this helps you out in defeating your school or workplace's draconian ISA server.