SysAdmin Blog

SysAdmin Blog

No title specified

bochmann Wednesday 21 of April, 2004
by using a "route add" with the wrong parameters, I today produced the following route on my MacOS X 10.2 box:

Destination Gateway Flags Refs Use Netif Expire
0&0xd5a443f1 UGSc 0 0 en0 =>

(...where isn't even on the local net for that machine.)

Curiously, 0xd5a443f1 is in the standard notation, but I don't know why MacOS suddenly chose to use a hex string in the route print output...


BGP MD5 frenzy

bochmann Wednesday 21 of April, 2004
So now we know (cache) why everyone has been scrabmling to implement MD5 auth on their bgp peers in the past weeks...

Now, TCP reset attacks aren't exactly a new game (see here (cache) or even here (cache)), but Paul A. Watson (cache) presented why such an attack is feasible in real-world environments in his "Slipping in the Window: TCP Reset Attacks" CanSecWest '04 paper.

Apparently he shows that for an RST (or SYN) attack on a TCP connection, you don't need to hit the exact current sequence number, but merely a range defined by the window size & window scale parameters of the connection.
If the TCP stack additionally has a weak ISN generation scheme and a predictable algorithm for the selection of ephemeral ports, there's obviously a real threat for any kind of long-living TCP connection. And then, Cisco seems to use an "insanely huge" window size.

There's also this IETF draft (cache) with a description of the attack and possible defenses (didn't have the time to thoroughly read the text yet, though).

What makes this problem worse for BGP is the widely used practice of flap dampening (cache), which can result in routes from your AS being not globally routed anymore after only a few successful RST attacks on the BGP connection, but other core network protocols using TCP connections are also affected. MD5 auth helps, but at the cost of additional CPU usage, which may open an additional resource starvation attack vector on the router, so filtering transit networks used for bgp peers is probably the cheaper defense.

Another potential victim are VPN connections using TCP connections, as for example with OpenVPN or IPSEC over TCP for NAT traversal (or ssh sessions). There will shurely be a few more papers on this in the coming months...

wireless blues

bochmann Sunday 11 of April, 2004
The wireless world doesn't seem to get any better - here's (cache) the description of a tool called asleap (cache), which exploits weaknesses in Cisco's proprietary LEAP protocol (advertized as a "secure 802.1X EAP authentication solution").

It seems that Cisco tried to make shure that the successor to LEAP was widely used before this tool was made available, but didn't succeed. Their current recommendation (from last year, when the problems with LEAP first showed up, here (cache)) is to use better passwords. Hah.

I have no idea about how widely LEAP is used in the wild, but probably some companies bought into the idea after the WEP insecurities were public, and never upgraded their setup.

Also during the last week, Max Moser made available (cache) his tool HotSpotter (cache), which is able to lure Windows XP clients away from their EAP/TLS authenticated home network and make them connect to a rogue access point simulated by hotspotter.

Lots of new fun with "secure" wireless networks out there.


bochmann Tuesday 23 of March, 2004
Ausnahmsweise mal auf Deutsch hier...

Diesen Abend habe ich mich mal ernsthaft damit beschaeftigt, warum ich IPFilter nicht auf meiner Solaris Schuessel zum laufen bekomme, wodurch es zu folgender Unterhaltung auf dem IRC kam:

20:18 @Galaxis> Hm. Wie kann ich in nem binary nen memset call drin haben wenn
im source nichts in der Richtung vorkommt?
20:18 @double-p> bzero?
20:18 @Galaxis> Stimmt.
20:20 @Galaxis> Lustig. Entweder hat noch nie jemand ipfilter 4.1.1 unter
Solaris 9 compiliert oder man muss nur bei mir string.h dafuer
includen :)
20:21 @Galaxis> strings.h even
20:21 @double-p> Galaxis: :}
20:29 @Galaxis> Hm, strings.h ist auch bloedsinn, das ist das falsche bzero
20:31 @Galaxis> ne, ist ja nen kernel driver, da gibts bzero(9f)
20:31 @Galaxis> Vielleicht macht gcc und/oder der Linker was falsch
20:32 @double-p> oh
20:32 @Galaxis> (fuer bzero(9f) hat er die richtigen includes dabei)
20:32 @triple-n> bzero is builtin bei gcc afaicr
20:32 @Galaxis> Vielleicht sollte ich doch einfach nen binary package irgendwo
suchen :)
20:33 @triple-n> oder halt muehsam alle bzero()s durch memset()s ersetzen
20:33 @triple-n> wobei das stinkt, bzero() ist wunderschoen und jeder weiss
was es tut, memset hab ich oft genug mit vertauschten
parametern gesehen
20:34 @Galaxis> triple-n: solaris solaris solaris
20:34 @triple-n> galaxis, shouldn't matter, unix unix unix
20:35 @Galaxis> triple-n: Ja, aber solaris hat nen spezielles bzero fuer
kernel device driver, und da will ich natuerlich nicht das
builtin vom gcc haben
20:35 @triple-n> . o O (auf der hardware tut bestimmt auch OpenBSD... )
20:36 @triple-n> "spezielles bzero"
20:36 @triple-n> ha ha ha
20:36 @triple-n> interessant
20:36 @Galaxis> triple-n: aber nicht mit 2 CPUs
20:36 @triple-n> das braucht 4 CPUs um die memory pages mit random zeros zu
20:36 @triple-n> firewall mit 2 CPUs, sehr sinnig
20:36 @double-p> RANDOM ZERos
20:36 @double-p> MUHAAA
20:36 @triple-n> genau
20:36 @Elwood_G> nnn: der eine firet der andere walled \:)
20:37 @Galaxis> Wo ich das gerade sage faellt mir auf, dass ich es vielleicht
mal mit -fno-builtin versuchen sollte
20:37 @triple-n> *slap*
20:37 @double-p> gack
20:38 @Galaxis> triple-n: einmal ist das ne SS10 mit zwei SM51 (50MHz, yummi,
da verzichtet man nicht gerne auf die zweite CPU) und zweitens
geht es mir gerade nciht darum, irgendwas sinnvolles zu machen
20:39 @triple-n> aeh, I see. da braucht solaris schon beide CPUs zum verwalten
der CPUs


Siehe SolarisIpfilter :)


bochmann Monday 15 of March, 2004
Ok, so you should exclude stuff like /proc when trying to duplicate complete system to another machine with tar (dump/restore wasn't an option, because the filesystem layout on the target was quite different from the original, and the filesystem too - xfs instead of ext3 on Linux boxen).

Unfortunately I didn't think about it until tar freaked out because the target / fs was full...

Tiki image galleries

bochmann Sunday 07 of March, 2004
Since I first installed TikiWiki, the image galleries didn't work - until now. Just upgraded to the latest version from the BRANCH-1-8 cvs branch, and now scaled images are actually displayed.
There's still some problems with the tiki stylesheet I'm currently using, should have started customizing it long ago. But, I'm just not interested very much in this html stuff - much more in the backoffice software that makes a CMS tick.

Solaris install horror

bochmann Sunday 07 of March, 2004
Yesterday, I tried to install Solaris 9 on my old Sparcstation 10. Certainly this is not the hardware this OS was developed for (the installer complained about not enough memory, 96MB being the minimum), and two SM51 CPUs are not blindingly fast either. Nevertheless, when booting from the Software CD 1, the installer starts and works without problems. Because I don't have too much disk space either, I chose only the core install with a few additions (thankfully, the Solaris installation CD now contains a lot of basic tools that had to be built from scratch in earlier days, like a quite current perl. tcsh, wget, ncftp, less).

All in all, including package selection, installing the first CD needs about 1 1/2 hours on this hardware (and with a 2x CDROM drive). Eveything looks fine until this message comes up right before the final reboot:

Unable to run Launcher without Java.
The following CDs will not be installed: Solaris 9 Software 2 of 2 (12/03 SPARC Platform Edition)
syncing file systems... done

At no time before that point the installer complained that java was a required package for the installation to complete. Ok, the system was bootable at that point, but it's a quite bare basic solaris install without all the fine goodies (and without manpages and development libraries). Great.

I went home and watched some TV.

ESRs CUPS horror story

bochmann Sunday 29 of February, 2004
Today, everyone and their dog is writing about Eric Raymond's CPUS story (cache). I didn't have his problems yet, as I only have used CUPS as print server for Windows Clients accessing it through Samba, and UNIX Clients via standard BSD lpr/printcap setup.
Oh yes, and I think the MacOsX print support is based on CUPS, but the interface is obviously a lot better than the one supplied with Redhat's Fedora setup.

By the way, I was quite surprised with the quality of the OS X help - after having found dozens of documents on, for example, enabling root access or booting to single user mode on the web, I took a look at the integrated help and found everything there (try looking up "root access" or "single-user mode" in Mac Help). Seems like I'm already spoiled by the "help" supplied on Microsoft OSes, which mostly fails to have any sort of technical documentation targeted at system administrators. But then I chose a Mac system, because I knew I would mostly have positive surprises (and because I used to work with NeXT machines and I'm still kind of NextStep affictionado - the overall feeling is quite comparable, and lots of old knowledge comes in quite handy on OS X)...

linux kernel upgrades

bochmann Friday 27 of February, 2004
The 2.4.25 Linux Kernel (cache) has been out for some time now, and after the corresponding Grsecurity (cache) patch has been made available, it was upgrade time.
I had been waiting with the upgrades for a few weeks now, despite several local root holes in recent kernels, as 2.4.25 was the first kernel with the xfs filesystem included, which I use on several important servers. The risk in waiting for so long was limited, as none of the affected systems had local users besides the system administration, and on the other hand, merging the xfs and grsecurity patches always needed quite a bit of manual intervention, as they collided in some places (mainly the ACL code).
I'm still building custom kernels for the more important systems, but it seems this is getting out of style. Perhaps some leftover from a time, when saving a bunch of kBytes on the kernel memory footprint could really make a difference.
Nowadays, I hear statements like "we don't support custom built kernels, the users are usually fucking them up anyway, and GENERIC just works" even from some of the OpenBSD people, who perhaps should know better.