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/xvda1

Replace /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.

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

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 flush global)


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.

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.