Log <-

Archive for November, 2007

chkrootkit false positives filtering

Thursday, November 29th, 2007

Chkrootkit is a tool that searches for rootkits, trojans and other signs of break-ins on your system. Like most security scanners, it sometimes generates false positives. Chkrootkit doesn't have a native way to filter those out. From the FAQ:

[Q:] chkrootkit is reporting some files and dirs as suspicious: `.packlist', `.cvsignore', etc. These are clearly false positives. Can't you ignore these?

[A:] Ignoring some files and dirs could impair chkrootkit's accuracy. An attacker might use this, since he knows that chkrootkit will ignore certain files and dirs.

This is true, but getting an email every day is simply too annoying, and makes me skip chkrootkit generated emails on occasion because "It's probably a false positive anyway". So here's a small guide for setting up a filtering of chkrootkit's output.

First, we create a file /etc/chkrootkit.ignore which will hold a bunch of regular expressions that will match everything we don't want to be warned about. For instance, I've got a machine that needs to have a dhcp client installed. Chkrootkit keeps on generating emails with these lines:

eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

So what we do is create the file /etc/chkrootkit.ignore and put the following in it:

/etc/chkrootkit.ignore

^eth0: PACKET SNIFFER\(/sbin/dhclient\[[0-9]*\])$
^eth1: PACKET SNIFFER\(/usr/sbin/dhcpd3\[[0-9]*\]\)$

In order to test if the rules we created are correct, we put the two lines with false positives in a separate file (/tmp/chkrk-fp.txt) and run the following:

test:

[root@sharky]/etc# cat /tmp/chkrk-fp.txt | grep -f /etc/chkrootkit.ignore
eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

The lines that should be filtered out of the chkrootkit output should appear here. If nothing appears, or if not all of the lines that you want to filter appear, there's a problem. Refine your regular expressions in /etc/chkrootkit.filter until it works.

Now we need to modify the chkrootkit cronjob so that the false positives are filtered. To do this, we edit /etc/cron.daily/chkrootkit. Below is a patch that shows what should be changed. You can apply the patch with the 'patch' command, or you can manually add the lines that start with a '+', replacing the lines with a '-'.

--- /home/root/foo      2007-11-21 11:53:58.532769984 +0100
+++ /etc/cron.daily/chkrootkit  2007-11-21 11:54:00.689442120 +0100
@@ -1,27 +1,28 @@
 #!/bin/sh -e

 CHKROOTKIT=/usr/sbin/chkrootkit
 CF=/etc/chkrootkit.conf
+IGNOREF=/etc/chkrootkit.ignore
 LOG_DIR=/var/cache/chkrootkit

 if [ ! -x $CHKROOTKIT ]; then
   exit 0
 fi

 if [ -f $CF ]; then
     . $CF
 fi

 if [ "$RUN_DAILY" = "true" ]; then
     if [ "$DIFF_MODE" = "true" ]; then
-        $CHKROOTKIT $RUN_DAILY_OPTS > $LOG_DIR/log.new 2>&1
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF > $LOG_DIR/log.new 2>&1 || true
         if [ ! -f $LOG_DIR/log.old ] \
            || ! diff -q $LOG_DIR/log.old $LOG_DIR/log.new > /dev/null 2>&1; then
             cat $LOG_DIR/log.new
         fi
         mv $LOG_DIR/log.new $LOG_DIR/log.old
     else
-        $CHKROOTKIT $RUN_DAILY_OPTS
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF || true
     fi
 fi

Next, we try running chkrootkit, to see if anything shows up:

[root@sharky]/etc/cron.daily# ./chkrootkit
[root@sharky]/etc/cron.daily#

There is no output, so our false positives are now being ignored.

WordPress

Monday, November 19th, 2007

I just finished writing an article for my blog. It took me most of the evening. Researching, writing, proof-reading, rewriting, linking to articles, etc. I click save, and only one-third of the article shows up in WordPress. The rest? Gone. Hours of my hard work? Gone. Careful proof-reading, rewriting, analysis, unbiasing, rereading? Gone.

THANK YOU WORDPRESS, YOU PIECE OF SHIT SOFTWARE!

I'm guessing it's wordpress' auto-save functionality. This isn't the first time this has happened (it happened about six times so far, always with articles that I spent the most time on), but it will be the last. This will be the last article I ever write using WordPress. I hate the product, and from now on, I will use every means at my disposal to discredit it as a useful piece of software.

WordPress sucks, and you shouldn't use it! Spread the word people!!

I'm starting a conversion of my blog to MvBlog tomorrow.

Why Ethernet didn't work, the real story

Monday, November 19th, 2007

I was just browsing around on Slashdot a bit, and I found an article on the topic of Token Ring Networks.

We all know that back in the day, Token Ring was considered 'better' than Ethernet because Ethernet would start colliding like mad under heavy (60/70% and higher) loads. This was because there was no central authority on who was allowed to send over the wire with Ethernet, so nodes on the network had to duke it out amongst themselves using Carrier Sense Multiple Access with Collision Detection. The more nodes on the network, the more collisions. Token Ring didn't suffer from the same problem, giving higher possible loads on a network.

But this interesting comment on Slashdot claims something else:

In theory, Ethernet on coax should be stable under heavy load. But in the late 1980s and early 1990s, it wasn't, due to defective design of some widely used interface chips. Here's the actual story. See this note by Wes Irish at Xerox PARC [link dead, so not included]

The worst device was the SEEQ 8003 chip, found in some Cisco and SGI devices. Due to an error in the design of its hardware state machine, it would turn on its transmitter for a few nanoseconds in the middle of an interframe gap. This noise caused other machines on the LAN to restart their interframe gap timers and ignore the next packet, if it followed closely enough. This happened even if the SEEQ chip was neither the sender or the receiver of the packets involved. So as soon as you plugged one of these things into a LAN, throughput went down, even if it wasn't doing anything. A network analyzer wouldn't even see the false collision; this was at too low a level.

This was tough to find. Wes Irish worked on the problem by arranging for both ends of Xerox PARC's main coax LAN to terminate in one office. Then he hooked up a LeCroy digital oscilloscope to both ends. Then he tapped into a machine with an Ethernet controller to bring out a signal when the problem was detected and trigger the oscilloscope. Then, when the problem occured, he had a copy of the entire packet as an analog waveform stored in the scope. This could then be printed with a thermal printer and gone over by hand.

Because he had the same signal from both ends of the wire, the wierd SEEQ interference mentioned above appeared time-shifted due to speed of light lag, making it clear that the interference was from a different node than the one that was supposed to be sending. You could measure the time shift and figure out from where on the cable the noise was being inserted. Which he did.

It took some convincing to get manufacturers to admit there was a problem. It helped that Wes was at Xerox PARC, where Ethernet was born. I went up there to see his work, and once I saw the waveforms, I was convinced. There was much faxing of waveform printouts for a few months, and some vendors were rather unhappy, but the problem got fixed.

So that's why.

I'm not completely convinced that is the real reason why Ethernet didn't perform well under high loads back in the day (these days, switches take care of the problem of high levels of collisions on Ethernet networks), but it does make for an interesting read.

Customers…

Monday, November 19th, 2007

Customers (as well as business partners, prospects, etc) are not:

  • Aliens
  • Humour impaired
  • Poisonous
  • Unreasonable
  • Inhuman
  • Somehow invulnerable to the same problems we all face in day to day business.

Even if they're wearing suits!

It's not a Problem; it's a Challenge!

Wednesday, November 14th, 2007

I finally have a reply to the oft-heard managerial "It's not a Problem; It's a Challenge!":

"ITIL doesn't define 'Challenge'. ITIL only defines incidents and problems". That outta shut them up. :-D

SSH + SOCKS5 = Universal proxy

Wednesday, November 14th, 2007

I didn't know it, but (Open)SSH supports setting up a Socks5 proxy:

-D [bind_address:]port
  Specifies a local ``dynamic'' application-level port forwarding.
  This works by allocating a socket to listen to port on the local
  side, optionally bound to the specified bind_address.  Whenever a
  connection is made to this port, the connection is forwarded over
  the secure channel, and the application protocol is then used to
  determine where to connect to from the remote machine.  Currently
  the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
  as a SOCKS server.  Only root can forward privileged ports.
  Dynamic port forwardings can also be specified in the configura-
  tion file.

Socks5 is pretty neat, as it allows you to proxy stuff without the server having to know anything about the way the client works. For instance, if we give the following command:

$ ssh -N -D 127.0.0.1:8080 todsah@sharky.electricmonk.nl

We can now tell all kinds of clients such as web browsers and instant messaging clients that there is a Socks5 proxy running on the localhost at port 8080. SSH will forward all connections made to port 8080 to the sharky.electricmonk.nl host (all encrypted of course).

So, say we tell Pidgin that it should connect your MSN account through the Socks5 proxy at localhost:8080 by opening the Accounts (Ctrl-A) → Click MSN account → click ModifyAdvanced tab → Proxy options → Proxy type = SOCKS5 and setting it to Host: localhost, Port: 8080. Now, when we reconnect to our MSN account, all MSN traffic will be routed over an encrypted SSH tunnel to the sharky.electricmonk.nl host, and will enter the public Internet from there.

This works great if you don't trust the network you're currently on, but don't have access to a VPN for instance. You also don't have to specify a single forward for each application/port like you have to do when you use ssh -L. You can use the same SOCKS5 proxied port with multiple applications, as long as they understand SOCKS5.

Android

Monday, November 12th, 2007

Android is here.

There's been a lot of rumours about a Google mobile phone. Now, it appears that there is no gPhone (thank god), but there is a Google Mobile Phone Software Development Kit!

The SDK appears to have everything you need to build third-party applications for your mobile phone. The SDK is created in Java, has rich 2D and 3D graphics layers and, naturally, the default Google API stuff such as Google Maps. There's also an emulator that allows you to test your application. Why can't all SDK's be as cool as this one? And the best thing: it's Open Source!

So, here's the homepage; the presentation by Sergei Brin and an overview of the architecture (Part 1, Part 2, Part 3).

Not only is Google providing this SDK for free and as Free/Open Source Software.. they're also offering a total ten million dollars in sponsoring to the best and most original mobile applications built with it! Put that in your pipe and smoke it Apple!

Now, all we need is a phone that runs Android. Are you listening mobile phone builders? Nokia? HTek?? We need a phone that can run Android!

New site

Monday, November 5th, 2007

Well, the big day is finally here. I revamped my homepage.

The real problem with Wikipedia

Saturday, November 3rd, 2007

According to many, Wikipedia's biggest problem is that it can't be trusted because anybody can edit it. Personally, I feel that the problem is that experts are allowed to edit it.

Hypercholesterolemia
Conditions with elevated concentrations of oxidized LDL particles, especially "small dense LDL" (sdLDL) particles, are associated with atheroma formation in the walls of arteries, a condition known as atherosclerosis, which is the principal cause of coronary heart disease and other forms of cardiovascular disease. In contrast, HDL particles (especially large HDL) have been identified as a mechanism by which cholesterol and inflammatory mediators can be removed from atheroma. Increased concentrations of HDL correlate with lower rates of atheroma progressions and even regression. The relation of cholesterol to CHD, termed the "lipid hypothesis," is still hotly debated.

This is from the article on Cholesterol – from the 'clinical significance' section. I mean, really, is there anybody who hasn't got a PhD in biology that understands all this? All I want to hear is if/why cholesterol is bad for you. 'Hypercholesterolemia'?? Why not just say 'high blood cholesterol'?

Now, this is one of the easier articles (I picked it because I happened to have it opened in my browser), but there are tons out there that are a million times more complicated. (for instance, check out this section which has no introduction and almost no explanation. Compare it to the section before it, which is much better). That's the problem with experts: they tend to lose sight of the overview and can only focus on details. But Wikipedia is an encyclopaedia, not a textbook on transfinite recursion.

Then again, Wikipedia hasn't been an encyclopaedia for a long time. Wikipedia's is quickly becoming the largest collection of human knowledge there is. It's got information on traditional encyclopaedic topics, movies, books, comics, everything. I guess having all this information available in one place is better than not having it available at all or having it available in a million different places.

Come to think of it.. Wikipedia is what the Internet should have been: A big collection of information. The Internet, instead, has become something entirely different: A big collection of advertisements. I guess Wikipedia isn't so bad.

Python web app server in 48 lines

Saturday, November 3rd, 2007

I needed to write a little application which would be accessible from a remote client, and which wouldn't need any custom software running on the client. I needed a web application. But I didn't feel like setting up a whole Apache web server with mod_python and whatever.

Of course, there's CherryPy, but it feels a bit heavy for the very simple application I required. So I wrote TinyWAPP: Tiny Web App. A tiny web application server in Python in only 48 lines.

(more…)