NOTE: This is about a hardware web filter I am sadly stuck behind. #Bugs in the iBoss home 1.

it does deep packet inspection on too many protocols - Just because the packet is UDP does not mean the packet is trying to be used to bypass filtering. It might be VPN traffic or torrent traffic. - Voip programs like teamspeak, mumble and skype use udp for a valid reason, it is faster. Having such an underpowered processor do deep packet inspection for time-critical data like that is a waste of time and makes those protocols unusa ble. It also messes with torrents and rsync. - This also slows down the device and kils the internet connection for everyone else. 2. It inspects TCP packets too deeply - I can understand this for protocols like HTTP where the data being sent can b e vital to the filtering (EG the HTTP client commands to the server), but you do not need to inspect every single TCP packet that goes through. I was able to t est this by changing the destination address of one packet to a site that is blo cked by the filtering rules (4chan). The connection was killed, proving you do D PI on every TCP connection. 3. The device is running an old kernel - 2.4 series kernel. The latest is 3.5 4. Blockpages do not return a HTTP error 451 - http://tools.ietf.org/html/draft-tbray-http-legally-restricted-status-00#sect ion-3 5. A comprehensive nmap scan on the device kills internet access. #!/bin/bash function kill_internet { sudo nmap -A -p 1-65535 -sV 192.168.1.10 # this kills internet access fo r everyone behind the filter } 6. No IPv6 support 7. Configuration requires a reboot to commit. 8. Hamachi access is broken 9. You don't kill XMPP sessions 10. Deep Packet Inspection likely done in the wrong place 11. Buffer overflow possibility on the blockpage --#List of games and programs the filter interferes with: Dota 2 (unplayable, lag spikes) Left 4 Dead 2 (lag spikes, causes more deaths than would normally occur) Team Fortress 2 (Effectively unplayable due to the random lag spikes) Saints Row: The Third (will not connect to other player) Mumble (audibly stretches voice) Skype (We gave up after about 5 minutes of trying to talk) Steam Game Downloads (note: slows down other user's connection as well)

- Killing Floor (lag spikes) - Garrys Mod (lag spikes, does make the game interesting though) - SSH sessions (it can lag while I type the word "pizza") - IRC sessions (i've gotten a ping timeout because the iBoss did not forward my client's PONG fast enough) - modern Bittorrent due to its use of UDP and micro transport protocol (see foo tnote) - rsync (makes gentoo useless) - League of Legends (will not update) - Quake Live (again, latency issues in a fast paced game like quake is bad) tl;dr: It affects every single protocol that uses UDP as a transport layer proto col for speed --#Suggestions for fixing this: 1. DNS is only done over UDP port 53. Any UDP packets not sent over port 53 are fine and should be immediatly passed on. If a developer is using UDP in 2012, t hey have a good reason and that should be respected. This is a major problem th at affects everyone behind the filter's access to the internet, whitelisted or n ot. 2. With the exception of a couple major web protocols (HTTP comes to mind the mo st), You don't need to inspect every packet in order to make sure the client is being restricted. At bare minimum (which is better given the terrible processor ) you need to inspect the initial SYN packet sent out to the server. This would contain the port information and give the iBoss unit an idea of what traffic is being sent. Exceptions can occur, but this would be something to implement as a user-level setting. 3. This would be near trivial if you have kept your kernel build config up to da te. 4. This is not an essential change, but it would look good for the company to su pport this new web "feature". 5. This probably stems from the terrible processor and ancient kernel issues. Fi xing either one of them will make this better and the included bash code not wor k 6. Again this probably stems from the old kernel. At least return AAAA records in DNS so IPv6 DNS lookups work. 7. It's 2012. Figure out how to not have it reboot to apply config, it's not tha t hard. Using a recent kernel might help. 8. Hamachi is a valid and useful tool for getting access to machines you or your friends own to access resources remotely in the name of network transparency. It is a good thing and is sadly blocked by your filtering devices, making some o f my server unusable. 9. I am currently incubating it, but with this leak you could proxy a tor connec tion over XMPP to get around the filter. Currently this only works with the Goo gle Talk XMPP servers. 10. To do your deep packet inspection, you likely store and forward the packets through the DPI layer then shoot them out. It would be a better idea to have th e packets be inspected as they enter. This would be easiest with the mac-addres

s based group filtering, as you could read the mac address, check it, then cheat if you don't need to filter it. Otherwise then you check the IP layer, then th e UDP/TCP layer if needed and finally the application layer data only if absolut ely essential. 11. Try this: add "%00This%20text%20will%20not%20be%20shown." to the blocked rea son on any blocked url page. The text is not shown. This represents that you h ave been treating the URLs as safe and not been checking for the user having ami cious intentions. --#Proof of bittorrent slowdowns Before: http://www.speedtest.net/result/2087544594.png I then started 5 random torrents from the pirate bay that had at least 100 seeds each (contents do not matter, we are testing the filter's poor handling of UDP traffic, not how fast you can illegally download films). After: http://i.imgur.com/iaF5h.png http://www.speedtest.net/result/2087538220.png http://i.imgur.com/21CIb.png When your connection is like this, you tend to notice.