One for the note-to-self file...

Linux's maturing support for POSIX.1e capabilities is cool. Here's how to figure out what capabilities a binary needs, using strace.

From http://www.symantec.com/connect/articles/active-directory-and-linux...

An alternative to allowing anonymous searches on your Active Directory is to allow the nss_ldap routines to bind as an administrator DN to your directory and perform searches in privileged mode. To do this, insert the following lines in your /etc/ldap.conf file:

binddn cn=Administrator,cn=Users, bindpw

You should be used to the "" thing by now.

WARNING: The above example shows that the administrator user name and password have been coded in clear text in the /etc/ldap.conf file! Unfortunately, this file must always remain world-readable, because otherwise users logged on to the system will not be able to read data from the directory. You should not do this on a system where any user has shell access to your system, or can in any other way read this file.

If you've put the Administrator password in a world-readable file, you've already lost.

I saw that the inimitable Steve Kemp has cranked out an RBL for hosts that do brute force SSH attacks within seconds of thinking about doing it.

As I have a passing interest in such things, and discovered that his sample submission client is really more geared towards people using iptables with the LOG target (and I use the ULOG target), I cranked out this moderately flexible Python client for logs written by ulogd this evening.

If you use Netfilter rules like mine, you can use my script after /var/log/ulog/syslogemu.log gets rotated with:

$ ./report_iptables_ulog.py --log /var/log/ulog/syslogemu.log.1 --prefix SSH_brute_force

In light of this Linux kernel local root vulnerability, I thought I should audit the trustworthiness of users with logins on systems I administer, so I slapped together this script to find users who had a valid shell and an unlocked account.

Disclaimer: I wrote it in bed on a Sunday morning. It may be utter crap.

Erich Schubert's two posts about embedding spamtraps in web pages got me wondering about trying to track the web crawlers that harvest such addresses.

If the pages that had the embedded spamtraps could be dynamically generated, it'd be interesting to generate email addresses that encoded the time of the crawl (well the page load I guess) and the IP address of the remote host.

I expect that most of the harvesting is done by botnets, so it possibly wouldn't tell you a lot, but it'd be kind of cool to maintain a central blacklist of known harvesting IP addresses, that sites like mailing list archives could use to try and block the harvesters with.

I'd like to get a Bluetooth keyboard for my MythTV machine. It'd be more convenient to drive it from the couch instead of crouching down in front of the TV on the existing USB keyboard.

Thing is, I'm paranoid about typing passwords over the air. Most of the wireless keyboards at Fry's are either IR (I'd be happy with this apart from the line-of-sight requirement) or running on some 27Mhz frequency I've never heard of, and so am rather wary of.

I'm assuming Bluetooth will be a little more secure given that it supposedly encrypts the communication, but I'm trying to determine how flawed or not that encryption is. This article was an interesting read, but didn't really address any of the cryptography involved.

It suggests that if I don't leave everything discoverable (which I wouldn't) and attackers aren't able to narrow their search space by knowing what sort of keyboard I have (which I'm guessing they could sniff anyway) that just sequentially searching the Bluetooth MAC address space would take over 1000 days.

So I'm assuming that if the keyboard is in use, then its MAC address is going to be known, so the question comes back around to the strength of the encryption...

Apple's website says it's 128-bit.

I guess I could get the gear and do some investigating myself, but I'm hardly a l33t h4x0r, so my self-penetration test would hardly be as comprehensive as being under attack from someone who was.

In recent times I've started seeing something in my logs that I haven't seen before. I'm yet to do any further investigation, but I suppose the next steps would be some packet captures and BIND source code poking...

Nov  8 02:13:16 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov  8 02:13:16 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov  8 02:13:16 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Nov  9 01:08:33 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov  9 01:08:33 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov  9 01:08:33 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Nov  9 10:01:13 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov  9 10:01:13 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov  9 10:01:13 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov  9 10:01:13 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov  9 10:01:13 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov  9 10:01:13 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov  9 10:01:13 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov  9 10:01:13 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Nov 11 00:02:35 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 11 00:02:35 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 11 00:02:35 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov 11 00:02:35 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 11 00:02:35 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 11 00:02:35 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Nov 13 02:05:47 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 13 02:05:47 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 13 02:05:47 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov 13 02:05:48 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 13 02:05:48 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 13 02:05:48 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov 13 23:03:05 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 13 23:03:05 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 13 23:03:05 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Nov 15 02:37:32 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 15 02:37:32 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 15 02:37:32 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov 15 02:37:34 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 15 02:37:34 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 15 02:37:34 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error
Nov 15 02:37:34 daedalus named[6933]: errno2result.c:109: unexpected error:
Nov 15 02:37:34 daedalus named[6933]: unable to convert errno to isc_result: 14: Bad address
Nov 15 02:37:34 daedalus named[6933]: dispatch 0x80f6970: odd socket result in udp_recv(): unexpected error

Best. Read. In a while.

#!/bin/sh
eval ls > $HOME/listing

This is on the cover of a brochure for a "Writing Secure Software" tutorial offered by eSec back in 2001. I kept the brochure because it made me think, and until now, I hadn't been able to find four flaws. I was just doing some cleaning up and I found it again.

So far, I have:

1. relying on $PATH to provide ls (someone can overload it to cause something else to executed).
2. trusting the output of the aforementioned ls command and executing it
3. relying on $HOME to be set to something sane
4. making an assumption about the current working directory of the script (as this is going to influence what ls returns and is thusly fed to eval)

Well, that is four things, but I'm not sure if that was the four things eSec had in mind. Now I think I will throw it out...

I had an interesting discussion this afternoon at work regarding the pros and cons of permitting ICMP messages into the classified gateway environment that we manage.

The necessity came up because something has been changed with the WAN link between the site where I work and the site in Sydney, and the MTU is now something more like 1300.

We're faced with the choice of:

• enabling ICMP Destination Unreachable packets through the firewalls involved
• lowering the MTU on the interfaces of all the servers in the environments affected
• stripping the Don't Fragment bit on all the IP datagrams at some point before they traverse the WAN

If it were up to me, I'd be in favour of complying with RFC 1191 and being done with it, but one of my co-workers piped up about covert tunnelling over ICMP.

I have to admit that I hadn't heard about this until today. I had a read of the Phrack article in question, and it talks about doing it with ICMP Echo Request and Echo Reply packets, because these can readily have data added to the payload.

I'm interested in hearing about any exploitation of ICMP Destination Unreachable packets for such unintended purposes. I've raised this on the SAGE-AU mailing list, and the general consensus of responses so far is that blocking such ICMP messages is going to cause all sorts of breakage, and that if you're going to get paranoid about covert tunnelling over ICMP, you need to start worrying about IP over DNS and HTTPS proxying and a lot of physical security issues.

I agree completely. I'm all for Path MTU Discovery working as intended, unless someone can give me a good reason to the contrary. If I get time over the weekend, I'll have a bit of a play with Ethereal and something like sendip on my home LAN.

I don't normally regurgitate vulnerabilities already announced on Bugtraq, but when one is so blatantly self-deprecating it deserves a special mention:

This is a spectacular fuckup, it pretty much destroys what PaX has always stood and been trusted for. For this and other reasons, PaX will be terminated on 1st April, 2005, a fitting date... Brad Spengler offered to take it up but if you're interested in helping as well, contact pageexec at freemail hu

As I mentioned previously, I recently discovered the wonders of Netfilter's recent module, and have decided to try and employ it to ward off the evil script kiddies and their brute force SSH scripts.

As I like to be able to SSH to my server from where ever I happen to be, and I won't necessarily have the infrastructure to use public key based authentication, I thought I'd see how a bit of selective packet filtering would go.

I'm using:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

This will allow three port 22 connections from any given IP address within a 60 second period, and require 60 seconds of no subsequent connection attempts before it will resume allowing connections again. The --rttl option also takes into account the TTL of the datagram when matching packets, so as to endeavour to mitigate against spoofed source addresses.

As an additional nicety, I could refine this to use a custom chain and a whitelist that exited the chain for source IPs that were trusted.

I'm going to run this ruleset on my server for a while and see if I

1. don't lock myself out
2. make a dent in SSH brute force attacks

Update

After much discussion with Juergen Kreileder, this ruleset would appear to be slightly better:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

This has the (arguably) added benefit of not hosing any established SSH connections from the host that has made too many SSH connections in a short period of time, and allows for whitelisting.

Update

I've had a few people email me and ask about the whitelisting part, which I didn't do a terribly good job of explaining. I should have said that you need to create a custom chain first:

iptables -N SSH_WHITELIST

and then add whitelisted hosts to it in a manner like this:

iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT

this clears the whitelisted host out of the recently seen table, and because is has an ACCEPT jump target, should stop further processing anyway.

That's what I just got when I tried to visit the site. Bugger.

I've recently had the Netfilter recent module brought to my attention, and man, is it neat! The final example on the website for it is a bunch of rules that temporarily open up a hole in the firewall to allow an ident request in when an outbound SMTP connection is seen. Very cool. I'm interested in doing something to mitigate SSH brute force login attempts.

In the beginning, there was iSecure, and it was purchased by SecureNet shortly before I came on board. Shortly before I left to go back to University for a year, Betrusted bought SecureNet, and then bought SecureNet's main competitior, 90east. Now, Betrusted and some company called TruSecure have apparently merged and will become Cybertrust.

Quite the consolidation. Film at 11.

I decided to nmap a couple of the hosts back that have been doing the dictionary attacks on me. Of the two that I scanned, they appear to be Windows boxes, but they've got OpenSSH installed as well. Interesting.

I wonder if the SSH daemon is part of the trojan, or if people are putting SSH servers on their Windows servers these days?

I've been noticing a few SSH login failures for root and guest in both daedalus' and caesar's logs. Then I saw this post on Aussie-ISP, referring to this and this. I hadn't gotten around to disabling root logins since I reinstalled daedalus. Now I have.