Category: Network Connections

Mulling over DDoS

The Wikileaks fracas is escalating, with hacktivists on both sides of the divide working to take down sites that are seen to be on the wrong side of the issue. Personally, I do not have any political opinion on either the Wikileaks issue or the attacks. I leave that to less technical authors to write on. Personally, I just like mulling over the whole problem of DDoS attacks.

Any reader of this blog should be familiar with what a DDoS attack is. But to me, the problem of a DDoS attack is similar to that of an arms race – the side with the bigger gun or bullet wins. In the case of the initial attack, Wikileaks moved over to AWS and was able to hold off attacks for a while. This is because Amazon had bigger pipes and defenses than the attackers. However, the attacks have taken a turn and secondary sites such as credit cards and law-firms are being hit as well. It seems like certain parties are taking this opportunity to settle some beef.

But back to the whole problem with DDoS.

I’ve mulled over this with my former boss and some co-workers, for the purpose of a clandestine project that I was working on. The conclusion that I came to is that a DDoS is effective in its simplicity – the side with the bigger pipes win. The company that I used to work for, has one of the biggest pipes in Malaysia and we could take people down, single-handedly, if we wanted to.

However, there are strategies to mitigate a DDoS attack.

Bigger pipes
Wikileaks moving to Amazon was in effect, buying bigger pipes. This mitigated attacks for a while until they got booted off Amazon. If it is not possible to buy pipes from a single provider, it would make sense to buy pipes from multiple providers and distributing the site across the globe. This is what Wikileaks has now done – distribute its content over a list of hundreds of worldwide mirrors operated by volunteers.

Faster software
DDoS attacks exploit the fact that a computer is kept busy by servicing network packets (either at the application or networking layers). Obviously, the solution to this problem would be to have bigger machines – this means having faster processors, larger memories, lighter operating systems. Surprisingly, some people do not realise that the TCP/IP stack plays an integral role in these attacks and if the OS has a more efficient stack, it would be able to withstand more punishment. Not all web-servers are created equal and some are able to handle concurrency better.

IPv6
One method that is not often thought of, is moving infrastructure over to IPv6. Most of the internet still runs on IPv4 today. In fact, many network providers simply do not cater to IPv6 and simply drop the packets from their network. Therefore, moving a site over to IPv6-only could help mitigate DDoS attacks by limiting the available sources of attack. Compromised botnets would be less effective if most of their machines were still on IPv4 only.

Future clouds
What would have been interesting would be if the attackers had shifted to launching attacks from cloud service providers. In fact, this was one of the queries that I raised once, in a meeting with a local cloud provider – launching attacks from within the cloud provider itself. If the provider is not careful, attackers could buy network and computing resources in order to launch attacks within the cloud itself. This would be difficult to detect because most cloud providers put their metering on external traffic, not internal ones. Imagine the attackers buying EC2s to attack Wikileaks from the inside of Amazon infrastructure. The attack would only need to be bad enough to take down the Wikileaks machines, without compromising the rest of Amazon’s infrastructure. Therefore, it is important for cloud providers to think about isolating their internal machines from each other.

Of course, there are many more considerations that could fit this little blog, but these were just some thoughts that I felt like writing down.

Weird TLD in China

I was reading about a recent Gmail hack from China and they actually showed the IP used to access the account. Since I was fairly curious, I decided to take a look into the IP – 125.45.96.89 – and I was surprised with the result.

inetnum: 125.40.0.0 - 125.47.255.255
netname: UNICOM-HA
descr: China Unicom Henan province network
descr: China Unicom
country: CN
admin-c: CH1302-AP
tech-c: WW444-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CNCGROUP-HA
mnt-routes: MAINT-CNCGROUP-RR
status: ALLOCATED PORTABLE
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks: This object can only be updated by APNIC hostmasters.
remarks: To update this object, please contact APNIC
remarks: hostmasters and include your organisation's account
remarks: name in the subject line.
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed: hm-changed@apnic.net 20051011
changed: hm-changed@apnic.net 20051020
changed: hm-changed@apnic.net 20090507
changed: hm-changed@apnic.net 20090508
source: APNIC

Nothing surprising here since the IP reports itself as being allocated to a Chinese ISP – China Unicom in Henan.

; <> DiG 9.7.0-P1 <> -x 125.45.96.89
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60982
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;89.96.45.125.in-addr.arpa. IN PTR

;; ANSWER SECTION:
89.96.45.125.in-addr.arpa. 85865 IN PTR hn.kd.ny.adsl.

;; Query time: 23 msec

Now, this totally caught my eye. Notice the PTR record shows that the name for that IP is hn.kd.ny.adsl – an uncommon TLD. So, I checked Wikipedia for a list of available TLDs and fair enough, the ADSL TLD does not seem to exist. If I were to try to ping hn.kd.ny.adsl, the address would not even resolve through the normal DNS system.

ping: unknown host hn.kd.ny.adsl

Now, this indicates to me that China is running its own root-servers, which does not surprise me one bit as it uses it to implement the Great Firewall of China. Since it does this, it is free to implement its own list of TLDs that nobody else uses in the rest of the world. This is all fine and dandy until ICANN decides to approve the use of an ADSL TLD in the future.

With the recent WikiLeaks fiasco, people are already talking about fragmenting the Internet. This is proof that the Internet is already fragmented – we just need to take it to the next level. Zero-One-Infinity, anyone?

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.