Xkcd.com has a very true comic on the practical side of security.
Archive for the ‘Networking & Security’ Category
When troubleshooting a slow network connection I wanted to get an idea of the link load. Usually I power up my linux-based Virtual Machine which polls the SNMP interface counters and draws nice graphs. But I was working remotely over an RDP connection, so SNMP was not possible.
So I had to use the build-in tools of the ProCurve switch. The “show interface” output looks like this:
Status and Counters - Port Counters for port 24 Name : Link Status : Up Totals (Since boot or last clear) : Bytes Rx : 819,265,344 Bytes Tx : 1,217,179,587 Unicast Rx : 4,052,391 Unicast Tx : 5,062,876 Bcast/Mcast Rx : 1,142,020 Bcast/Mcast Tx : 7,390,717 Errors (Since boot or last clear) : FCS Rx : 0 Drops Rx : 0 Alignment Rx : 0 Collisions Tx : 0 Runts Rx : 0 Late Colln Tx : 0 Giants Rx : 0 Excessive Colln : 0 Total Rx Errors : 0 Deferred Tx : 0 Rates (5 minute weighted average) : Total Rx (bps) : 501944 Total Tx (bps) : 504256 Unicast Rx (Pkts/sec) : 0 Unicast Tx (Pkts/sec) : 0 B/Mcast Rx (Pkts/sec) : 0 B/Mcast Tx (Pkts/sec) : 4 Utilization Rx : 00.04 % Utilization Tx : 00.04 %
Note the values on the bottom indicating the “Rates”? They’re not what they claim to be! This particular interface has approximately 1kbps input (Rx) and 3kbps output (Tx); not exactly the 500kbps the output claims. Also, try to explain how to receive 502kbps of data with less than 1 packet per second…
This particular switch is a 2610-24PWR with firmware R.11.16; but it’s probably a more general problem.
Everyone with some basic knowledge on the TCP/IP protocol knows that TCP can cope with lost packets. The lost packet is retransmitted, the send-rate is throttled back a bit and on it goes. I just found this usenet-post by stanislav shalunov giving a formula to calculate just how much bandwidth remains after all that “throttling back”:
Standard TCP has throughput that’s limited by approximately MSS/(RTT*sqrt(loss)). Therefore, if your MSS is 1460B and RTT 70ms (typical for a cross-continent path), you need no more no more than 0.0003% packet loss to get 100Mb/s or 0.03% to get 10Mb/s. Note that, because of that square root, every doubling of required throughput means dividing permissible packet loss by four.
Recently Bruce Schneier has posted some very good and readable posts on biometrics and impersonation, explaining the difficulties with security systems. Recommended reading for everyone in security!
In my home setup, the Wireless LAN and the Wired LAN are on different subnets. The communication between the two is fully routed, so from the IP point of view, this works perfectly. Most protocols just use DNS and just work. There are, off course, some exceptions to this rule that needs special treatment. One example is, big surprise, Microsoft’s name resolution which works by using broadcasts. Since routers don’t forward broadcasts, you need a trick to get this to work across subnet boundaries: a WINS server.
Another example is Apple’s Bonjour protocol (aka Zeroconf aka Avahi aka Rendezvous). The technical details are a bit different (multicasted instead of broadcasted; based on DNS instead of proprietary protocols), but the result is the same: it doesn’t work across subnet boundaries. Obviously, this protocol is extended to work over a Wide Area Network (WAN), but for some reason, Apple decided that iTunes (and iChat) only supports local Bonjour. (It won’t surprise me if the RIAA has something to do with this.)
Continue reading ‘Sharing iTunes across subnet boundaries’ »
Recently I was troubleshooting a networking problem from my work, Windows notebook: an FTP server behind a firewall was not reachable. FTP is known to be a tricky protocol to get through firewalls (it opens a second connection on random ports), so I went straight into troubleshooting bottom up.
First step is to verify the control-connection. I usually test this by manually connecting to port 21 using netcat (or telnet). netcat reports that the connection is open, but shows no server-header. Normally one would assume that the firewall allows the connection, but there is something wrong with the FTP server. If only it would be that easy…
I’m a bit paranoid when it comes to security. For example, I don’t allow passwords to log into my computers via SSH but use RSA keys instead. Besides added security (there is no password to guess), it has a lot of other advantages as well. I normally run an ssh-agent (both on linux and Windows) which caches my credentials so I can log in without password.
On my desktop system, this was automatically secure against theft. Since the key is stored in RAM (or encrypted swap), it is flushed the moment the computer looses power. Since it was a desktop system, it’s fairly safe to assume that the power will be cut when someone steels my computer.
On my new MacBook Pro, things are a bit different: most of the time, my notebook is in standby and has an integrated UPS (its battery). So I was looking for something to get me the same security.
I often need to work with IP addresses and IP subnets. Somehow humans are not very good at binary arithmetic, so converting from 255.255.192.0 to /18 does take some time. Calculating how many hosts could fit in there and what the address-range is, is an even bigger challange.
Luckily there exists a nice tool called the subnet calculator, which does all of these calculations in an instant. The Internet offers lots of these; some are Win32 applications while others run online; Some require to input each octet individually, others are more liberal.
After some hours of search, I didn’t find a subnetcalc that fits my needs. I’m sure it exists somewhere in the 427000 hits, I just didn’t find it. Instead, I wrote my own one.
Recently I had to configure a router serving as an IPsec-GRE endpoint. So far, nothing special. The interesting part is that the terminating router is behind a NAT-device which changes the outer IP-header of the IPsec tunnel. Of course, the GRE-header is NOT affected by the NAT (since it is encrypted).
To summarize, the device needs to:
- terminate an IPsec tunnel between 172.16.2.2 <-> 10.0.0.4 (its own IP); but authenticate as 172.16.2.4
- terminate a GRE tunnel between 172.16.1.1 <-> 172.16.2.4 (a public IP that is NATed towards it)
The diagram is shown below:
172.16.x.x addresses are “public”; 10.x.x.x are private.
Continue reading ‘Terminating an IPsec-GRE tunnel behind NAT’ »
When studying for my Cisco ISCW exam, I wanted to get somewhat more in-depth information on the different DSL-techniques.
First of all, there are different DSL techniques, ranging from IDSL (providing 144/144kbps) over the popular ADSL (somewhere around 1/10Mbps up/down) up to the newer VDSL variants (around 50Mbps). Within each technique, there are different modulation schemes.
I decided to explore what my Alcatel SpeedTouch modem (now Thomson) had to tell me; here is the report.
