Hacker Halted – Day 1

I attended Day 1 of Hacker Halted today. I signed up for Workshop 1 – on web-application hacking – because I wanted to learn more about it. Our morning started with mainly basic stuff on the underlying mechanism behind web applications – HTTP protocol, DNS services and what nots.

Our afternoon session was more interesting, with our trainer – Sean Arries – showing us the information gathering aspect of web-application hacking (vulnerability analysis). This is done in order to increase the attack space of the target. The thing that I learned from this section of the training is that – sites are far more vulnerable from side-channel and internal attacks than direct external attacks.

The tools that I already knew (and are part of every System Admin’s arsenal) were things like whois, dig, nslookup, host and other network layer stuff. However, at the application level, I learned how to use XSS ME. Manually testing cross-site scripting (XSS) is quite fun.

The basic techniques shown were really useful. We even practiced it on a number of prominent local Malaysian sites. Very interesting. Tomorrow, we get to the actual act of attacking web applications (penetration testing) and see if we can pwn any machines. I am looking forward to hacking my own websites.

FreeNAS with D410PT

I bought myself a D410PT and 1GB of DDR2-800 memory yesterday for only RM290! I decided to use it to build a better NAS for my home. However, there were some issues and I thought that I should note them down here.

Power Supply
My first problem was the ATX power supply. For this purpose, I decided to use an old 120W power supply that I had lying around from an old VIA machine. Turns out that it only had 20 pins while the D410PT had a new 24 pin power socket. However, with some research I found out that the extra 4 pins were not strictly necessary as they were there for extra current. Seeing that this is a low-power design, the extra current was not quite necessary. According to the D410PT user manual, it only takes up 40W under full load with a bunch of devices connected. So, safe.
Network Chip
Another problem happened when I started up FreeNAS. It could not load up the built-in network. Turns out that the chipset used on the D410PT was not recognised by FreeNAS 0.7.1 (latest stable). However, after using the latest nightly build (5266), the link activated. So, I was able to get the network working. Unfortunately, the D410PT only has a 100Mbps chip but that is good enough for my home NAS.
Old Config
At first, I tried importing the old config backup from my previous 0.6.9 server but that caused more problems than it solved. It made it difficult to make configuration changes as the 0.7.2 server would complain about config errors. I guess that something must have changed in between. So, I ended up resetting the configuration and doing all of it manually. The trickiest part was to make sure that the old drives that I moved over from the old machine did not get reformatted or deleted by accident. Otherwise, it worked fine.

Exascale Communications

I got the opportunity to attend a short training and workshop on computing on a massive scale conducted by SGI. The speaker was a highly technical guy, Michael A. Raymond, who delivered a very good presentation. Personally, I learned some things and got some of my queries answered.

He mentioned that the main issue in large scale computation today is communication and not computation. While I can understand his logic in saying that, I am hazarded by the thought that these two things tend to take turns being the problem. Once communication problems are slowly chipped away, the computation problem will recur.

Actually, I would say that the computation problem is already recurring – with the introduction of heterogeneous computation into the mix. These days, lots of computation are off-loaded onto computation engines, which may be made up of custom microprocessors, FPGAs or even DSPs and GPUs. Not only that, the number of cores available may not be a nice friendly number – like 6 cores in newer Intel/AMD chips and 7 cores in a IBM Cell processor.

These little things do tend to throw a wrench in a works a bit.

I wanted to attend this talk in order to learn a bit more about multi processing because my next generation of AEMB will definitely feature more and more parallelism features and I wanted to get an overview of how things are like in this area. However, much of the talk focused on HPC applications, which may not be what I am interested in. That said, I still learned some interesting things about how they solved certain problems.

I intend to introduce multi-process, in addition to multi-threading already on the AEMB. It is the next logical step to improve the processor before moving it up to multi-core. I will probably need to build in some sort of fast inter-core interconnect to enable multi-core processing on multi-threaded and multi-processed AEMBs. My littlest processor may just end up being the world’s leader in on-chip parallelism.

Fun days ahead!

Network Disk Cloning

I had occasion to clone a hard-disk over the network today. I wanted to replicate a VM setup that I already had running in one machine, over onto another, which will save me time from setting it up again. So, I checked the internet about using dd with nc to clone over the network. Most places gave the following info:

Target:

# nc -l -p 9000 | dd of=/dev/sda2

Source:

# dd if=/dev/sda2 | nc serverip 9000

However, trying that set of commands would fail. So, checking the man pages for NetCat revealed that you cannot use both the -l and -p parameters together. So, the correct set of commands should be as follows:

Target:

# nc -l 9000 | dd of=/dev/sda2

Source:

# dd if=/dev/sda2 | nc serverip 9000

Which worked out just fine in the end. Thought I’d share it.

Broadcast Storm

Learning about networking is not very fun unless you actually get to see it in action, which is the opportunity that I gave my apprentice today. A few months ago, the corporate network at the place where I am doing public service and paying my dues, went down when a low-level tech accidentally connected the network in a loop.

When that happens, it becomes possible to send packets round and round in a loop. This is not so much a problem with proper network connections because the packets will be terminated at the destination. However, it is a problem for broadcast packets as they could possibly be broadcast in circles – ad infinitum.

First, I got two computers with two network ports each. Then, I bridged the ports together so that br0 on each computer bridged eth0 and eth1 together. This is the example configuration for Debian networking:

auto br0
iface br0 inet static
bridge_ports eth0 eth1
bridge_stp off
....

Next, I connected one network port from each PC together with a LAN cable. I asked my apprentice to observe the lights on the network ports. They blinked a few times when the cables were first attached due to hand-shaking of the network capabilities. Then, all activity stopped.

So, I initiated a broadcast packet by performing a ping to a random IP address. Because the PC does not know the destination machine, it will send an Address Resolution Protocol (ARP) broadcast packet asking for the destination machine for a reply. We could have just as easily done this with an arping command instead.

The lights on the network ports began to blink with activity and we managed to observe things. After my apprentice got a good look, I stopped the pinging and we confirmed that all activity stopped.

Then, we connected the other two network ports from each PC together with a second LAN cable. Now, we have got ourselves a network loop. Again the lights blinked a few times during hand-shaking and then all activity stopped. I initiated another broadcast and the lights began to blink again. So far so good.

Now, it was time for the broadcast storm. I stopped the pinging like before but this time around, the lights did not stop blinking. The broadcast packet was moving round the network in a loop. My apprentice got all excited that the network ports were blinking rapidly even when there was no application sending out any activity.

Then, I disconnected one port and the blinking stopped – magic!

Finally, I showed my apprentice how the network would work with STP enabled. I changed the settings above and set bridge_stp on instead, restarted the network stack and reconnected the network cable. With STP in place, there would be periodic network activity when the STP packets were sent out but these were easily distinguished from the crazy blinking broadcast storm.

I repeated the whole experiment again, but this time, the broadcast packets stopped after the pinging application was stopped – success!

I think that this would make networking subjects more interesting. This experiment was fairly simple to conduct and took nary five minutes. It would demonstrate networking concepts in a very visual and visceral manner. It does away with the whole idea of imagining how network packets moved through a network. Beautiful simplicity.

IPv6 Stress

I was reading this article on seven IPv6 myths today and a random thought entered my head. The article seemed to stress that the only real difference that IPv6 makes in this world is extending the address space from 32-bits to 128-bits. This is a 4x increase in the address space currently used.

This instantly triggered a yellow-flag in my head. This also means that there will be a marked increase in the memory space on networking devices, coupled with an increase in memory bandwidth consumption on the said devices.

What many people may not know is that on a networking device like a router, routes need to be maintained for the duration of a connection. This is usually maintained as some sort of table in the memory. When a network packet comes into a router, its header is examined for the destination address. This is then used to look-up the route to take in the routing table. Then, the network packet is forwarded onto the route on its way to the destination.

So, an IPv6 routing table would need to quadruple its memory space requirements. This would not be so bad if we didn’t take the real-world performance of memory into account. It would also mean that the amount of memory transfers would be quadrupled as well, assuming similar table and lookup patterns.

While I have not researched into this, I do think that there is room for innovation here. We could possibly change the routing table structure by dropping off some of the bits or to partition it up into directories indexed by the significant bits of the address or to hash the IP addresses in such a way as to reduce memory requirements.

This may not mean much to a lot of people but if the route look-up process slows down by a factor of four, it will significantly affect the latency of the network even if its effects on throughput may be minimal. Latency is very important for certain applications, anything that requires near real-time feedback like first-person shooters.

Interesting…