I have talked before about using firehol to configure iptables. I won’t go into all the details about how wonderful and awesome it is, but trust me, it makes configuring iptables a snap.

Firehol includes a script, get-iana.sh, that downloads the IPv4 address space list from IANA and populates a file called RESERVED_IPS that firehol uses when configuring iptables. Basically, any traffic from outside coming from any reserved or unallocated IP block is dropped automatically. As you can imagine, keeping this file updated regularly is important, as previously unallocated blocks are allocated for use. To this end, whenever firehol starts it checks the age of the RESERVED_IPS file and if it is older than 90 days warns you to update it by running the supplied get-iana.sh.

However, there has been a change recently in how the IANA reserved IPv4 address space file is formatted. There are lots of posts on plenty of forums with patches for get-iana.sh to accept and use the new format plain text file (while the default is now XML rather than plain text) and needless to say I tried every single one I could find. None of them worked, so what to do? How about a complete rewrite in Python? And while we’re at it, let’s use the XML format that IANA wants everyone to use.

So, one lunch hour of hacking and here it is, working like a charm. You can copy this, but I recommend downloading it to avoid whitespace issues.

#!/usr/bin/python

"""
file: get-iana.py

Replacement for get-iana.sh that ships with firehol and no longer seems to work.
This is less code, less confusing, uses the preferred XML format from IANA and works.

Copyright (c) 2010 Sjan Evardsson

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
"""

import urllib
import xml.dom.minidom
import os
urllib.urlretrieve('http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml','address-space.xml')
results = []
x = xml.dom.minidom.parse('address-space.xml')
for i in x.childNodes:
    if i.localName == 'registry':
        for j in i.childNodes:
            if j.localName == 'record':
                for k in j.childNodes:
                    if k.localName == 'prefix':
                        prefix = k.firstChild.data
                    if k.localName == 'status':
                        status = k.firstChild.data
                if status == 'RESERVED' or status == 'UNALLOCATED':
                    results.append(prefix)
outfile = open('iana-temp','w')
for r in results:
    hi = int(r.split('/')[0])
    outfile.write(str(hi)+'.0.0.0/8\n')
outfile.close()
os.remove('address-space.xml')
os.rename('/etc/firehol/RESERVED_IPS','/etc/firehol/RESERVED_IPS.old')
os.rename('iana-temp','/etc/firehol/RESERVED_IPS')

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

An article yesterday at bnet.com about Cisco’s patent filing for search has me concerned. Instead of relying on crawling links (and obeying robots.txt) like current search engines do (or at least should), Cisco’s idea is to look into packets at the network level and pull apart network traffic to discover HTTP requests. While that may not sound so terrible, I can see a need to change the way I do some business.

I often have development work, intended for collaboration with clients that is wholly not discoverable via web crawling. It is not that there are any great secrets there (unless the client is particular about not letting anyone know what their new site will look like before it goes live) but it is not meant to be permanent, either. This means that unless you know the full URL to the documents in question you are not likely to find them. These URLs are emailed to the client so they can click on the link in their email and let me know which parts of the app work the way they want, what doesn’t work, UI changes they would like to make, etc. With the standard web-crawlers these pages will never show up in a search listing.

If a layer three network device is picking those URLs out of traffic it is passing, however, those pages might be indexed, and once indexed, added to search. Now, a week later, when the directory x79q3_zz_rev2 is trashed, there are indexed searches pointing at what will return nothing but 404. Not good for me, not good for the client and not good for the individual doing the search.

My second concern is one of bandwidth. Yes, I know, there is lots of bandwidth and “everybody is on broadband these days anyway” (I don’t know how many times I hear that). Be that as it may, the “everybody” that is on broadband is not actually everybody, and anything that adds more delay to packet routing only makes the situation worse. And what happens when user A sends a request through their ISP to get an HTTP resource? How many hops does it cross? And how many of those will be running Cisco devices? (Hint: most). How many of those Cisco devices are going to do introspection on that packet to pull out the URL? How long does that take? Now consider how many HTTP requests your browser actually makes when downloading a web page. The page itself, linked CSS files, linked JS and any images (and let’s please not even consider AJAX requests).

While the idea is novel, I don’t think it is a good idea, and I would actually hope that Cisco gets the patent and sits on it and uses it merely to bludgeon anyone who actually tries to do this.

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

Yesterday evening my roommate’s machine was botted. I got a text message to my phone from Pingdom that my site was down and I did a bit of digging and found that his machine had somewhere in the range of 80-100 open outbound connections at all times.

I notified him and he immediately went to TrendMicro House Call to clean it up. He said it found “a few things,” but he didn’t note what they were, nor did he try to isolate them so I could attempt to decompile and inspect them. Ah well, such is the world, and he had work he needed to be able to finish with his machine.

The odd thing was, once his machine was cleaned and no longer in contact I began to get a flood of TCP SYN packets and UDP packets to the server on port 23130. The size of the UDP packets (between 75 and 196 bytes) leads me to believe they were some sort of botnet commands, while the TCP SYN packets were bots trying to reconnect to their lost buddy. This definitely did not have the marks of a DDoS of any sort, as once the bot on the Windows machine was stopped (and I once again had outbound bandwidth) the packets were hitting the server in a fairly steady fashion, but not in any kind of flooding behavior. In other words, each host was trying no more than 5 times to connect via TCP and no host sent 2 identical UDP packets in a row. The reason they were hitting the server is that the packets were being sent to a specific IP address, and trying to create a new connection with that IP means you are trying to connect to the server. Without the established connections in NAT on the router, all these packets were going to the server. Unfortunately the server in question is not beefy enough to run tcpdump, even for a few minutes, and trying to alter my network enough to get my laptop in where it could sniff the packets was out of the question.

While I didn’t have tcpdumps or even extensive firewall logs I did have the abbreviated logging that takes place in messages. (I also had dmesg logs to look at, but I never realized until last night that dmesg logs are not timestamped. I wonder if that is a configuration error on my part. Right now I am too exhausted to try to figure that one out.) So, I had the log entries in /var/log/messages and there is plenty good information there – and here is what I saw, from the hours of Sep 18, 19:16:59 to Sep 19 03:06:49. (Note that the packets are still coming in, but now at a rate of somewhere around 2 attempts per hour.)

There were a total of 178,335 TCP SYN packets to port 23130, along with 33,894 UDP packets to the same port. These requests came from 1,994 unique IP addresses. Below are some interesting statistics.

Edit: Mostly I am curious about the botnet in question. If anyone comes across a bot that is communicating on port 23130 please let me know what you find out about it.

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

An article yesterday from ars technica got me wondering. In my former position we often “scrubbed” databases for sample data from which to work. And certainly one can see the value in working with data with personally identifiable information removed for the purposes of business or health-care informatics, service level determinations, quality of service surveys, and so on. Yet, according to a study at Carnegie Mellon University:

87% (216 million of 248 million) of the population in the United States had reported characteristics that likely made them unique based only on {5-digit ZIP, gender, date of birth}.

This seems to be the balance point: 3 pieces of non-anonymized data are enough to identify the majority of the population. (Think, “Three Strikes! You’re out!”) So what do we do when we need solid, anonymous data from which to work?

Taking the example of the health records from the article linked above, I would think that the following steps would be enough to fully scrub the data beyond where “reidentification” would not be possible. Since this is medical records we can safely (I feel) assume that randomizing the gender is a non-starter. (“Wow, according to this data 14% of all men went to the Emergency Room with pregnancy-related complications!”)

And since this data is taken from an area where the zip codes are known we are already at two strikes. So why did they not randomize the dates of birth? It would be difficult to do in the case of infants beyond a few days or weeks, since many of the health issues are related to their age in months. But for anyone over the age of 8 it should be simple enough to randomize the month and date of birth, and allow a set of ranges for randomizing the year of birth. If we assume a 20% range up or down we gain a lattitude of possible years of birth which increases the older the patient actually is. Another possibility is to give everyone the same date of birth, differing only in the year. (Jan 1, xxxx).

This of course means that any reporting done on age is meaningless, but it also means that the data can more safely be widely distributed. In cases where exact age and gender are required for study it would be better to merge data from many different areas, covering as many cities, counties, states and regions as possible. In this case we would still need to weigh the risks, as all three pieces of data would still be available, although at a much higher level of trail and error. In the case mentioned by ars technica the study covered seven zip codes. Perhaps spreading the information over a few hundred would make it much less worth the effort to sort through them all to try to identify individuals, and even then one would expect multiple possible hits.

The need for real data for statistical analysis and study is not going to go away. When you are considering releasing scrubbing data to release a “sanitized” version it would be good to keep the mantra “Three Strikes! You’re out!” in mind. When it comes to data for testing software operation, however, I still think the better method is complete randomization. Totally bogus data that has the look and feel of “real” data. (Which is no doubt why all the bogus users in my test dbs live in different cities, in different states, and at addresses ranging from 123 to 999 on Any Street!)

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

While trying to debug the Shorten2Ping plugin (a really nifty thing, if I could get it working) I went digging through my Apache error logs looking for any PHP errors. (Well, okay, I didn’t actually dig, I just did a last on the file.) What I saw was interesting, even though it did not help the debugging at all. In fact it kind of derailed the whole process. What I saw was an obvious attempt to find Horde on my server (which I did run temporarily a few years ago). My first guess was that there was a new exploit out for Horde. I did some digging around and found that, yes, indeedy, there is. I found the details of the exploit at securityvulns.com (which is a mirror of or mirrored by www.security.nnov.ru which is where the first relevant Google link took me.) Oddly enough I have not seen this show up on any other security sites yet, even though I see that the report on securityvulns.com is from March.

Anyhow, in case you are curious, here are the relevant lines from the log. (IPs have not been changed to protect the guilty.)

[Sat Jun 06 01:46:53 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/README
[Sat Jun 06 01:46:53 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde
[Sat Jun 06 01:46:54 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde2
[Sat Jun 06 01:46:55 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde3
[Sat Jun 06 01:46:56 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde-3.0.5
[Sat Jun 06 01:46:57 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde-3.0.6
[Sat Jun 06 01:46:58 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde-3.0.7
[Sat Jun 06 01:46:58 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde-3.0.8
[Sat Jun 06 01:46:59 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/horde-3.0.9
[Sat Jun 06 01:47:00 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/mail
[Sat Jun 06 01:47:01 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/email
[Sat Jun 06 01:47:02 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/webmail
[Sat Jun 06 01:47:03 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/newmail
[Sat Jun 06 01:47:03 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/mails
[Sat Jun 06 01:47:04 2009] [error] [client 81.210.76.194] File does not exist: /var/www/localhost/htdocs/evardsson.com/mailz

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

While dangling pointers are a common coding error (especially in C++) there has previously been no way known to exploit them. In fact, they were generally considered a quality control issue rather than a security issue. That is all set to change. According to an article today from SearchSecurity Jonathan Afek and Adi Sharabani of Watchfire Inc have uncovered a way to exploit generic dangling pointers to run shell code on a server in much the same fashion as buffer overflows. According to Danny Allen (also of Watchfire) this technique can be used on any application with dangling pointers.

Afek will be giving a presentation on the technique in August at the Black Hat Briefings in Las Vegas.

Technorati Tags: security, dangling pointers

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

A white paper from Fortify Software outlines a major Web 2.0 Vulnerability. According to the white paper, all current frameworks that use JSON for data communications are vulnerable. They have released the information to all the major framework developers so that this can be addressed within the AJAX frameworks. They noted, however, that one quarter of the participants in an AJAX survey hosted by Fortify did not use any framework at all. Fortify recommend a two-pronged mitigation approach:

• Include a hard-to-guess identifier, such as the session identifier, as part of each request that will return JavaScript. This defeats cross-site request forgery attacks by allowing theserver to validate the origin of the request.
• Include characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a <script> tag to witness the execution of the JavaScript.

Computer Business Review has a more extensive write-up available.

Technorati Tags: AJAX, Web 2.0, JavaScript hijacking

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

At least 3 of the 13 global root servers were briefly overwhelmed in a sustained attack last night, lasting, in some cases, as long as 12 hours. Looking at the RIPE NCC DNS monitoring service it seems that 2 of them, G (US Dept of Defense) and L (ICANN) were having the most difficulty dealing with and recovering from the attack.

At this point the attacks seem to have been aimed at UltraDNS, which primarily handles traffic for .org sites.

While there is as yet no mention of who is suspected or what their motives may be, there was a similar attack last year on UltraDNS.

The AP’s report is here.

Technorati Tags: DNS, UltraDNS, security, analysis

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

Talk about fast! George Ou at zdnet posted an article about this particular gem.

Essentially, a user with the Speech Command feature enabled can browse to a web page which starts a sound file (like just about every mySpace page) containing clearly recorded commands, and the Speech Command feature will execute those commands without any other user interaction. While not every command is enabled through Speech Command, George explains why you should disable Speech Command until there is a fix:

The fact that a website can play a moderate level sound file to
interact in a way with the desktop by activating an idle speech
command system and be able to delete user documents with zero user
interaction is serious by any stretch of the imagination.

Update: Microsoft has confirmed this exploit.

Technorati Tags: security, windows, vista

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post

A discussion on Slashdot earlier today brought up the question. It seems that Eric McCarty, a student at Purdue University in Dr. Pascal Meunier’s CS390 – Secure Computing, discovered, and reported, a flaw he found on the Physics department website. When that site was hacked two months later (most likely through a different flaw, since the one reported by McCarty was patched) law enforcement came looking for Mr. McCarty. In this particular case McCarty came forward, and was eventually cleared. However, it did change how Dr. Meunier teaches his class. He no longer recommends disclosure, but recommends that one eliminates all evidence of the discovery from their computer and say nothing.

I see this as a particularly disturbing direction in which to move.

Buzz This Post Delicious Digg This Post Ping This Post Reddit Stumble This Post