codeblog code is freedom — patching my itch

December 10, 2014

Open EVSE

Filed under: Blogging,Networking,Ubuntu,Vehicles — kees @ 12:53 pm

Needing a new car, and wanting to never purchase another gas-fuelled motor, I bought a Nissan LEAF. (Trivia: LEAF appears to be a backronym for “Leading, Environmentally friendly, Affordable, Family car”.)

LEAF

This vehicle has effectively a 22kWh battery and goes maybe 80 miles on a charge, which is more than enough for running errands.

The 15-Amp (“Level 1”) EVSE (Electric Vehicle Supply Equipment) that comes with the LEAF plugs into a standard wall socket. It tells the car’s charger to draw only 12A, so it doesn’t pop the house’s circuit. This will fully charge the batteries in about 20 hours, which is not sufficient for daily use.

15A EVSE

The thing on the end that plugs into the LEAF is the J1772 connector. You’ll note it is not just an extension cord, even though it feeds the car AC power. The EVSE communicates with the vehicle to negotiate a charging current. Then the LEAF’s on-board charger takes the AC the EVSE makes available, converts it to DC, and stores it in the batteries. (My model LEAF also has a second plug for DC fast charging, which uses an entirely different connector: CHAdeMO.)

Most folks with an Electric Vehicle end up installing a “Home Charger”. (Though calling it a “charger” is a misnomer since, as mentioned, the charger is in the car.) This is actually a “Level 2” wall-mounted EVSE, which uses a dedicated high-amperage circuit. Like the Level 1, it has communication logic to do the protocol negotiation with the vehicle. However, the price of Level 2 EVSEs is crazy high (low-end $1000, high-end $3000), and that doesn’t even include the cost of getting the dedicated circuit run by an electrician.

To make matters worse, none of the standard EVSEs are Open Source, and only the high-end ones have remote access, etc. Luckily, I am hardly the first person to notice this, and since I’m so “late” to the EV world, there are several Open projects for building one’s own EVSE.

I went with OpenEVSE, since I can build it (so I understand all the components in the system), and I can change/improve the firmware (like adding a wifi board). Under Ubuntu, I was up and running after installing the arduino and avrdude packages.

Now I can charge from empty in under 8 hours, since the 30A unit charges at 24A nominal.

30A EVSE

While I was at it, I 3D printed a socket to hold the J1772 plug when it’s not in the car.

J1772 Holder

© 2014 – 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

November 26, 2013

Thanks UPS

Filed under: Blogging,Debian,Networking,Ubuntu,Ubuntu-Server — kees @ 8:25 pm

My UPS has decided that every two weeks when it performs a self-test that my 116V mains power isn’t good enough, so it drains the battery and shuts down my home network. Only took a month and a half for me to see on the network graphs that my outages were, to the minute, 2 weeks apart. :)

APC Monitoring

In theory, reducing the sensitivity will fix this…

© 2013 – 2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

November 10, 2010

TARPIT iptables target

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 9:21 am

Want to use a network tarpit? It’s so easy to set up! Thanks to jpds for this whole post. :)

sudo module-assistant auto-install xtables-addons-source
sudo iptables -p tcp ... -j TARPIT

Though no such thing exists for IPv6 yet.

Here it is watching over the SSH port:

iptables -N INGRESS-SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j INGRESS-SSH
iptables -A INGRESS-SSH -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set
iptables -A INGRESS-SSH -p tcp --dport 22 -m state --state NEW -m recent --name SSH --update --rttl --seconds 60 --hitcount 4 -j LOG --log-prefix "[INGRESS SSH TARPIT] "
iptables -A INGRESS-SSH -p tcp --dport 22 -m state --state NEW -m recent --name SSH --rcheck --rttl --seconds 60 --hitcount 4 -j TARPIT

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 9, 2010

easy example of filesystem capabilities

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

Instead of using setuid programs, the goal for the future is to use fine-grained capabilities. For example, here is /bin/ping:

$ ls -la /bin/ping
-rwsr-xr-x 1 root root 35680 2009-11-05 00:41 /bin/ping
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms

$ sudo setcap CAP_NET_RAW=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms

$ dmesg | tail -n1
[212275.772124] warning: `/bin/ping’ has both setuid-root and effective capabilities. Therefore not raising all capabilities.

The best part is that the kernel will choose the set of least privileges when both setuid and capabilities exist. Easy way to transition!

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 24, 2010

Google is wardriving

Filed under: Blogging,Debian,General,Networking,Security,Ubuntu,Web — kees @ 8:28 pm

So, a while back, Google started providing location services. This seemed pretty cool, but I kind of ignored it until recently when I was playing with my Android’s location API. With the GPS off, and no cell towers visible (my basement gets terrible cell service), my phone knew within about 500 feet of where it actually was. All I was connected to was my wifi.

Bottom line: it seems that Google, among other methods, is likely wardriving while photographing for Street View. They are now able to pinpoint wifi access points if they happened to see it while driving through your city.

I’m really rather astonished that no one is freaking out about this; I’m a bit unnerved. I implemented the location-of-your-wifi API quickly, so I could terrify myself further. You can do lookups via my location website too, if you want.

UPDATE: yeah, it would seem to be crowd-sourced wifi and cell tower triangulation data. I should say “Google is WarCrowding”.

© 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 13, 2009

ETOOMANYCERTS

Filed under: Debian,Networking,Ubuntu,Ubuntu-Server — kees @ 10:46 pm

After upgrading an Ubuntu mail server from Hardy to Intrepid, two users could no longer connect via SSL to send email though sendmail. One was using msmtp and the other was using Outlook Express. The msmtp issue was tracked down as a supposed deficiency in msmtp. However, this left Outlook, which is neigh-impossible to debug. From the Debian msmtp bug linked from the Ubuntu bug, it seemed that the root cause was the server sending too much data during the initial connection. Packet captures of an Outlook connection seemed to back this up: Outlook negotiated STARTTLS fine, and then just never responded to the SSL handshake.

It seems that something (openssl? sendmail?) changed between Hardy and Intrepid so that instead of using the /etc/ssl/certs/ca-certificates.crt file just for verification, its contents were now being sent during the SSL handshake. (I reduced the number of configured certs with “sudo dpkg-reconfigure ca-certificates“, and checked on the size of the handshake with “openssl s_client -connect server:port | wc -l“.) It spewed 143 certs sent at every connection. Unsurprisingly, it seems some clients were choking on it (I would like to note that Thunderbird behaved correctly).

In the end, I configured my sendmail’s CAfile (“confCACERT”) to aim at just a single CA (the CA used to sign the server’s SSL key), and that fixed both msmtp and Outlook. How fun.

© 2009 – 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

November 3, 2008

days since last incident…

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

If I made one of those work-site signs that tracked “Days since last incident”, and made one for “Days since last in-the-wild remote-root worm” for Windows and Linux, what would they each say? 0 and 7304 respectively?

Update: while the post was tongue-in-cheek (everyone suffers when any large subset of computers is being attacked), I should lower the Linux days count to 2783 (for L10n on March 23, 2001, which is slightly newer than Ramen on January 17, 2001). Thanks for everyone’s comments. :)

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

August 5, 2008

dbus session access from remote

Filed under: Blogging,Networking,Ubuntu — kees @ 8:49 pm

In order to turn off the music playing on my desktop (in audacious) from my laptop in another room, I must figure out the DBUS session, and set it up before using the audacious session management control (like “--play-pause“).

$ ssh MACHINE "set -x
export DISPLAY=:0.0
PID=\$(pidof audacious)
if [ -z \"\$PID\" ]; then
    rhythmbox-client --pause
else
    export \$(xargs -0 -n1 /proc/\$PID/environ | grep ^DBUS_SESSION_BUS_ADDRESS=)
    audacious --play-pause
fi"

(Updated to shorter version, thanks Kirikaza.)

© 2008 – 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

December 18, 2007

force sendmail to deliver a specific item from the queue

Filed under: Networking,Ubuntu — kees @ 8:11 pm

In case I or someone else ever needs this trick again, here’s my quick solution to work around QueueAge limits, and only force a specific queue id to get delivery retried:

/usr/sbin/sendmail -v -o MinQueueAge=0 -qI${ID_GOES_HERE}

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 28, 2007

CUPS banner template variables

Filed under: Networking,Ubuntu — kees @ 5:51 pm

A while back, I wanted to design some banner pages for a shared network printer that would show the name of the host that sent the request (none of the standard CUPS banners report this). It was easy enough to define a custom banner page:

<Printer lj4200>
...
JobSheets shared-banner none
...
</Printer>

Then, I could drop a modified banner into /usr/share/cups/banners with the filename “shared-banner”. The banner is just a regular PostScript file, so I could muck around with it. While looking at the “standard” banner, I saw some PS variables being used that had been defined by CUPS:

...
  (Job ID: ) RIGHT
  2 copy                % Copy X & Y
  moveto
  ({printer-name}-{job-id}) show
...

I couldn’t find documentation on the available variables, but managed to track down some of the list at cupsGetJobs2 in cups/utils.c:

job-id
job-priority
job-k-octets
job-state
time-at-completed
time-at-creation
time-at-processing
job-printer-uri
document-format
job-name
job-originating-user-name

None of these had the sending host listed, so I continued searching. Additional ones are defined in scheduler/ipp.c, including:

printer-name
job-id
job-billing
job-hold-until
job-sheets
job-media-sheets-completed
job-originating-host-name

“job-originating-host-name” did the trick for my banner:

...
  (Host: ) RIGHT
  moveto
  ({job-originating-host-name}) show
...

I’ve seen some other partial lists, but I haven’t found an official complete list. It’d be handy to see this documented better, since some variables aren’t valid until after the job is processed (job-sheets), so it’s only valid in the trailing banner, not the leading banner.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

December 7, 2006

filtering email body URLs with whois

Filed under: Networking,Ubuntu — kees @ 10:21 pm

I use SURBL filtering for my inbound email. It’s very handy except when my domain receives the leading edge of a new spam campaign. Whenever spam with a URL got through the filters, I’d go look it up and discover that it was added to the block lists about 20 minutes after I got the email. I’d think to myself, “dang, if only I had greylisted that email”.

Well, I got to thinking: all the URL-based spam campaigns have one thing in common: the domains they’re spamming have been recently registered. So now I greylist any email whose body contains a recently registered domain in a URL. It gets delayed just long enough that the SURBLs catch up, and when it is finally reattempted, it gets permanently rejected. Unfortunately, I have not found a common API for querying the registrars for a domain’s creation date, so I wrote an insane script to make a best-effort guess:

$ ./whois-created kernel.org 2>/dev/null
‘kernel.org’ created on: 1997-03-07
$ ./whois-created outflux.net 2>/dev/null
‘outflux.net’ created on: 2000-03-17
$ ./whois-created hosteije.net 2>/dev/null
‘hosteije.net’ created on: 2006-12-01

Any URLs with kernel.org or outflux.net I’d let through, but I’d greylist anything mentioning hosteije.net (which is now listed on the SURBLs).

Most of my email filtering is based on some heavily modified MIMEDefang code (which handles hooking to my script and doing the greylisting), but I’m figuring this sort of thing should live in some optional routine in SpamAssassin so more people can benefit.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 9, 2006

metalink

Filed under: kernel.org,Networking — kees @ 10:47 am

I’ve been watching metalink for a while now, and was urged to write about it, so I am! If you want to download something large that isn’t available via bittorrent, you can still get the distributed download benefits of bittorrent. Basically, metalink-aware downloaders split up your download across many mirrors of the resource you want, using existing protocols.

Bittorrent is great for “new releases” or other similiar things that are currently “in demand” by a large number of people. For older stuff, especially large trees of files, as found on many mirrored archives, you won’t find a bittorrent, and metalink can really distribute and speed up the download.

OpenOffice is using it, and I hope to figure out a way to incorporate it into kernel.org directly. There are already places hosting auto-generated metalink files for various projects, including the linux kernel. I’m hoping kernel.org can publish more complete metalink files since we should be able to build them more easily, having the list of which mirrors are in which countries, their access mechanism, and if they carry bz2, gz, or both. We’ve talked about it briefly, but haven’t finalized the plans yet.

You can even generate your own metalink files online.

Another blog has other details, so I hope I’ve not been too redundant. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

August 9, 2006

talk to me about Sendpage

Filed under: Blogging,Networking — kees @ 4:50 pm

Like I mentioned before, I’ll be in San Francisco at Linux World Expo next week. Besides presenting, I’ll also be at a Birds-of-a-Feather on “Network, Device, and Environment Monitoring” on Wed (8/16) at 6pm in Room 309, where I’ll be talking about Sendpage. I’ve been told this BoF is open to anyone with an “exhibits” pass which, prior to LWE starting, is free! So, if you’re in the area, come hang out. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

July 30, 2006

jabber to IRC bridge

Filed under: Inkscape,Networking — kees @ 11:16 am

I wrote a Jabber to IRC bridge a while back. It’s currently being used to bridge communication between the #inkscape freenode channel and the inkscape Jabber conference room. I’ve finally gotten around to cleaning up (read: getting configurable variable out of the script into a .conf file) and publishing it.

It’s a bit fragile since the POE/Jabber code seems to explode once in a while, and it doesn’t like losing connections with the Jabber server, but it works most of the time. Several people had asked me for copies of it, so there it is. Please don’t laugh at it/me too hard. Just send me lots of patches. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

July 29, 2006

encrypted network filesystems

Filed under: Networking,Security — kees @ 11:59 am

I run a machine in a colo across the country from me, and I wanted to have some backups closer to the machine. So I signed up for a NAS login with my provider. Since I didn’t want to leave all my files sitting on their disks in the clear, I built up an encrypted volume over the network. It’s not fast, but it works.

Here were the setup steps:

  1. mkdir -p /mnt/nas-raw /mnt/backups
  2. smbmount //backup.server.at.my.isp/mount.source.path /mnt/nas-raw -o username=myaccount,password=mypassword
  3. modprobe loop && sleep 2
  4. dd if=/dev/zero of=/mnt/nas-raw/volume bs=32k
  5. losetup /dev/loop0 /mnt/nas-raw/volume
  6. cryptsetup create crypt-backups /dev/loop0 –cipher=aes-cbc-essiv:sha256
  7. Type volume pass-phrase
  8. mkfs.ext3 /dev/mapper/crypt-backups
  9. mount /dev/mapper/crypt-backups /mnt/backups

To unmount it:

  1. umount /mnt/backups
  2. cryptsetup remove crypt-backups
  3. losetup -d /dev/loop0
  4. umount /mnt/nas-raw

And then to remount it later:

  1. smbmount //backup.server.at.my.isp/mount.source.path /mnt/nas-raw -o username=myaccount,password=mypassword
  2. modprobe loop && sleep 2
  3. losetup /dev/loop0 /mnt/nas-raw/volume
  4. cryptsetup create crypt-backups /dev/loop0 –cipher=aes-cbc–essiv:sha256
  5. Type volume pass-phrase
  6. mount /dev/mapper/crypt-backups /mnt/backups

By scripting the “remount” steps, I can actually echo the volume password into an ssh connection:

echo ‘my volume pass-phrase here’ | ~/bin/do-crypto-mount
ssh root@colo.machine.isp “/etc/dirvish/dirvish-cronjob && df -h /mnt/backups”
~/bin/do-crypto-umount

Very handy!

Update: I added the --cipher option to include the essiv type, which should be used.

© 2006 – 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

July 28, 2006

airodump channel hopping

Filed under: Networking,Security — kees @ 7:14 am

The “airodump” tool, part of the aircrack wireless analysis suite, is like “tcpdump”, except that it can perform channel hopping. Since channel hopping is a “lossy” way to do wireless sniffing (you’re only listening on each channel for a few hundred milliseconds before moving on to the next channel), it doesn’t make sense to listen to channels that you know will contain no traffic. However, there was no way to specify a range of channels. airodump would either listen on 1 channel or hop across all channels.

I wrote a patch to allow for a comma-separated list of channels to be specified. Now I can tell airodump to spend all of its hopping time on 6, 11, and 1, for example:

airodump ath0 /tmp/ath0-logs 6,11,1

UPDATE: Here’s a patch that does that same for aircrack-ng.

© 2006 – 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

May 24, 2006

easy wordpress anti-spam

Filed under: Blogging,Networking,Security — kees @ 11:06 pm

After getting about 40 moderation requests a day, I figured I should spend some time finding some anti-comment-spam plugins for WordPress. After digging around a while, I found one that doesn’t require JavaScript, doesn’t perform vision tests, but works just fine for the kind of comment-spam-bot that seemed to have taken a liking to my blog (even though no spam ever appeared in my comments ever…)

I found lr2Spam which has a great setup, but an incomplete final step. I merged it with ideas I saw in the RBL measures plugin, and got some good results. By replacing lr2Spam’s comment_post with pre_comment_content (see the WordPress Plugin API), I was able to redirect spammers away from from my site with PHP’s header("Location: [URL]") technique. (This is what I borrowed from the RBL plugin.) The patch is almost as big as lr2Spam itself (both are very small). Honestly, I’m surprised it works at all. Someone wrote a comment-spam bot that can’t correctly parse a totally valid HTML form, but does correctly handle a 302/Location redirect. Weird.

I thought briefly about redirecting all the spammers to http://fbi.gov/i-am-a-spammer/?ip=[IP] but then realized their requests’ referer header would show my URL still. On further thought, I realized that comment-spam is very different from email spam because the bot has to implement a much larger set of protocol elements. Since they must respect the 302/Location redirect, someone who is getting hit really hard with comment spam could effectively DDoS somone’s link by redirecting to somewhere with big files. Say, for example, instead of using fbi.gov above, I used http://mirrors.example.com/iso/DVD-distro-image.iso. Every spam bot in their network would start a giant-ass download from example.com after hitting my anti-spam system. Ewww.

Implemented early on May 20th, after 4 days, I’ve seen 250 comment spam attempts from 162 unique IP addresses (most in China — maybe they need to turn their firewall around). The volume of spam isn’t big when compared to my daily email spam statistics, but each one of those would have been an email in my inbox, asking for moderation. Interestingly, they all stopped on May 23rd. Maybe they got a clue.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

May 22, 2006

TiVoConnect dissector for Ethereal

Filed under: Multimedia,Networking — kees @ 9:03 pm

Over the weekend, I coded up a protocol dissector in Ethereal for the TiVoConnect Discovery Protocol. The protocol is very simple, but I still wanted the satisfaction of seeing it listed by name when scanning through my home network captures while debugging Galleon/TiVo traffic.

Ethereal has great developer documentation. It was easy to find and got me coding right away with a skeleton dissector. I just love the projects with these kind of to-the-point examples. The only thing I felt was missing from their README.developer was something showing that the dissector routine could return gboolean, letting a dissector reject being attached to a given packet.

There were other clearly written dissectors that I used for reference: DNS, Yahoo, and Syslog. They seemed to answer most of the more subtle questions I had about rewriting column text, scanning the packet, and dealing with other special cases.

Hopefully the patch will get accepted. I even did the randomized testing the wiki recommended. :)

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

April 30, 2006

slow debian mirror avoidance

Filed under: Networking — kees @ 8:02 pm

ftp.us.debian.org has 4 mirror servers in their DNS round-robin. One of them (216.37.55.114) is very slow (25Kb/s) for me. The others are blazing fast, especially 204.152.191.7 (800Kb/s). I’ve gotten sick of having to hit Ctrl-C to abort an apt-get, and then restart it, hoping to get a better server out of the DNS.

Today, I added the following to my machine’s iptables config, so that it will just redirect all attempts from the slow mirror to the fast mirror:

iptables -t nat -A OUTPUT -p tcp -d 216.37.55.114 –destination-port 80 -j DNAT –to-destination 204.152.191.7

If I wanted to do this for my whole network, I’d just slap this rule on my firewall and change “OUTPUT” to “PREROUTING”.

I love iptables.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 16, 2006

kernel.org and sendfile

Filed under: kernel.org,Networking,Security — kees @ 4:50 pm

The “sendfile” system call is a way to send file contents directly out to a network socket. This saves time in userspace (so it doesn’t have to copy buffer contents around), and was one of the reasons I upgraded kernel.org‘s Apache to version 2.x at the end of 2003 (because version 1.x doesn’t have sendfile support). A few weeks ago, one of the other kernel.org admins discovered that files greater than 2G were not being delivered by Apache.

I had a lot of fun tracking down the issue. The “amount to send” argument in the sendfile call is a “size_t”, which is basically an “unsigned long”. Having a 2G limit didn’t make sense, since even with 32 bits, that should be a 4G limit. However, the kernel.org servers are both 64bit, so as it turns out, “size_t” is a full 64 bits. After writing a quick test, I was able to verify that it was, indeed, a 31 bit limit on both 64 bit and 32 bit kernels. Peter Anvin took it from here, and tracked down the origin of the problem: filesystem operations greater than 31 bits in offset were being rejected deep in the kernel. He suggested truncating the request instead of returning a failure.

Seems as though Linus decided to limit the size of filesystem calls to make sure there aren’t security problems (signed vs unsigned overflows) in the various filesystem drivers, while people using the Linux kernel migrate more from 32bit to 64bit systems. Personally, I don’t agree with this, but from a practical stand-point, it hardly makes a difference. Instead of sending all 4G out the pipe and returning to user space, it just returns twice, sending 2G per call.

This should be fixed in 2.6.16. Until then, we could patch Apache to keep it’s offset request under 31 bits, but we’ll probably just tell people to use FTP, since vsftpd doesn’t use sendfile yet.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

September 30, 2005

80mph blogging: 41.75095N 89.85223W

Filed under: Blogging,Networking — kees @ 11:39 am

Technology is a beautiful thing. Right now, I’m on the passenger side of a vechile purchased in Pennsylvania, over EBay. The new owner is driving. This post is being made via a transparent proxy (via iptables) to Squid running locally on my laptop. Squid then forwards the proxy on to the SSH tunnel I’ve got up, which lands on a server in Texas, where another Squid is waiting for it, and handles the request. The SSH tunnel is set up over a PPP connection on top of Bluetooth to the driver’s cell phone, which is sending traffic via GPRS to his provider. I can hardly believe it works, but it’s actually rather quick.

Additionally, I’ve got my wireless card scanning for networks in kismet, with a USB-to-serial converter plugged into my GPS, with gpsd running, and gpsdrive telling us where we are. (And, of course, we’re downloading maps for gpsdrive via the previously mentioned abomination of a network connection.)

We just finished searching for hotels on the western edge of Nebraska that have free wireless Internet access.

Kick ass. I am such a geek.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

August 7, 2005

quick guide to encryption

Filed under: Networking,Security — kees @ 11:02 pm

I should qualify my comments from my prior blog entry and say that I’m appalled at Service Providers (not users) that continue to offer insecure services to their clients. Users, however, should be asking their Providers for secure services. Most don’t know to ask this, and that’s why I think the responsibility falls on the Provider.

Here’s my crash-course in simple anti-sniffing techniques.

  • Evaluate your network: if you’re on open Wireless, any one interested can see all communications to/from your computer. Be paranoid. If you’re on a wired network, your communications can still be seen, but it tends to be much less likely.
  • Evaluate your services: do you care about your various services? Do you have a different password for each service? Details below…

Evaluating your services requires creating a short list of all the things you send over the network from your computer. For basic anti-sniffing, there are two types of “encryption” available for most services:

  • Authentication: logging into anything. Checking email, logging into IM, logging into websites, etc. Some services offer “encrypted” authentication. Modern AIM clients, “APOP” POP clients, etc. If your authentication is encrypted people can’t just sniff your account/password off the wire.
  • Communication: all the traffic to any site/service. All services have a fully encrypted counterpart. Almost everything uses SSL for encryption, and appends an “S” to the protocol name. HTTP has HTTPS, POP has POPS, IMAP has IMAPS, SMTP has a TLS mode, Jabber has an SSL mode, good IRC networks have an SSL mode, etc. These SSL-protected services encrypt ALL of your communciation, including the username/password authentication.

It’s best to have fully encrypted communications, but if you can’t, just getting some kind of obfuscated authentication mechanism is better than nothing. Just ask yourself any time you type in a username/password, “How is this being sent to the remote server?”

So, here are some specifics to various common services:

  • Receiving email: POP and IMAP have SSL modes that run on different ports. See if your email Provider offers these services and switch your client to using those instead. If that’s not available, see if POP or IMAP support other authentication modes besides the clear-text “Plain” and “Password”. For example CRAM-MD5, Challenge/Response.
  • Sending email: SMTP has an SSL mode too. This is either called “STARTTLS” or “SSL”. A good Provider will offer SMTP on port 587 with STARTTLS. Hopefully your Provider requires you to authenticate before sending email. Instead of SSL, like POP/IMAP above, they may offer CRAM-MD5, etc.
  • Web sites: only use “https://” for logging into websites. If there isn’t a little lock in the corner of your browser, don’t log in. The browser folks have done a lot to help folks with this part. Ecommerce has caused a huge push to avoid in-the-clear authentication on websites. Unfortunately, some sites will still let you log in without SSL. (Like flickr, it seems.)
  • IM: I’m not sure about ICQ, MSN, etc, but Jabber offers a full SSL mode. The “old” style runs on a separate port (5223). The “new” style gets “turned on” during the initial jabber session setup. This would give you fully encrypted communications. I know AIM has both a Challenge/Response and MD5 mechanism for logging in, so at the very least, use those.

If you’re not sure if your communication is being encrypted or not, it’s very easy to install a network sniffer. Ethereal is available for almost every platform around, via the libpcap libraries. Just start it capturing before you use a service, use the service, and then go find the traffic in the capture log. Ethereal will identify almost all services by name (“HTTP”, “POP”, “IRC”, “AIM”, etc.) To see the traffic, click on the “Analyze > Follow TCP Stream”. This will show you all the communication for a given connection. (Click on “Clear” in the Filter bar to see all your traffic again.)

If you want to browse the traffic more easily, you can type in other filter terms. For example, to make sure your POP password isn’t being sent in the clear, enter “pop.request” in the Filter, and click “Apply”. Pick a packet, and select the “Request” section in the Packet Tree. If you see:

Request: USER omfg

Request: PASS intheclear

Then your “omfg” account is showing it’s password to the rest of the network. :)

Another alternative to all this pain is to have a VPN connection to some other network that you trust. This is the easiest to configure on the client side. If that’s not available, you can also tunnel all your traffic through an SSH connection. This is easiest to configure on the server side (no config). Here is an example of tunneling your POP service through SSH:

ssh -L 2110:pop.example.com:110 account@example.com

That’ll set up a local port 2110 that gets forwarded to “pop.example.com” port 110 (POP) after logging you in to some SSH account. This means you have to configure your POP client to use “localhost” port 2110 instead of “pop.example.com” on the regular POP port. And then you can only POP when your SSH connection is up.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

oscon 2005 wireless sniffing

Filed under: Networking,Security — kees @ 9:03 pm

OSCON’s wireless network was okay. It didn’t seem to handle the load very well, but generally you could pick out an Access Point that was still responding to DHCP, and it would work well enough.

I feel like I’m beating a dead horse, but I’m appalled at how many people continue to not use encryption. I spent some time yesterday going through my 4.1G of packet capture logs. Generally, I scanned POP, SMTP, IRC, and HTTP traffic. I should probably find better tools than just ethereal, but after finding 45 different POP accounts that were authenticating in the clear, I stopped counting. That put me half way through Thursday, so that’s only a day and a half of OSCON wireless traffic. No one seems to protect their nick on FreeNode, so at least no one’s nick password was sent in the clear. One person logged into Flickr in the clear. One of the accounts was for the speaker I was listening to at one point. I recognized the POP account because it was up on his slides.

What’s really interesting is the number of people that didn’t authenticate in the clear but ran the rest of their traffic in the clear. For example, many people used various challenge/response systems to authenticate to POP, IMAP, SMTP, and AIM, but then all the traffic continued to stay in the clear. All their email and AIM buddy information was out on the wire.

I know there was at least one other person doing network sniffing, since I saw him running EtherPEG (which makes a live collage of all the incoming HTTP images on the wire). I started up a heavy download of images just for him, but I think he had bored himself with enless slashdot and oreilly GIFs and never looked back to see the fun I had sent over the air for him. :)

(If you don’t have a Mac and you want EtherPEG functionality, there is also DriftNet.)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

August 5, 2005

defcon 13 patch round-up

Filed under: Networking — kees @ 7:38 pm

In (useless) preparation for DefCon 13’s CTF this year, I hacked at ettercap and Snort. Since the TTL filtering trick was out of the bag, I figured I’d implement the other idea I had. Since the score bot generally is a short-lived connection to a service in CTF, it would be great if Snort-inline rules could be written to detect how long a conenction had been around for. Initially I hacked at ettercap, but that was mostly so I could build a quick-and-dirty TTL statistics gatherer. In ettercap, I had to add session time tracking, but in Snort, it was actually already there. There just wasn’t anything that could be matched against in the rules section. I lifted the TTL matcher from Snort and just used the existing connection timers to do the work and created the “age” rule. Works like a charm. I hope they take my patches.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

February 16, 2005

Hitchhiker’s Guide to Reverse Engineering

Filed under: Networking,Reverse Engineering — kees @ 7:53 pm

Well, I got annoyed that I couldn’t watch the SWF-based HitchHiker’s trailer on the Amazon.com main page. swf_play failed miserably. Most of the crap Apple pulls for their movie trailer stream-hiding is simple enough to work around. Generally I just keep downloading the MOVs, running strings on them until I find the actual MOV with the movie trailer in it, but Amazon’s wasn’t so easy. I found the base URL to the video easily enough in the XML parameters file. The hard part was figuring out what the hell “rtmp” is. mplayer didn’t recognize it, and after a quick nmap of the media server, I just got more confused. nmap listed a port 1935 called “rmtp”. Digging around a little it became very obvious that nmap’s services entry was just a typo. So I sent in a quick patch, and Fyodor accepted it within minutes. Pretty cool.

Anyway, on to the protocol dissection. I set up tcpdump to record everything sent to fcs.amazon.speedera.net, and took a look at it in Ethereal. Seeing that it was mostly binary, I looked around for something that would dump the data portion of a packet stream, but ended up empty handed. I’ve repeatedly wanted this, so I finally broke down and read up on coding with libpcap. It’s easy enough to use, but I floundered with the packet headers for a while. Eventually I managed to find the data portion of the packets, and was able to dump the client stream and the server stream separately. I wish there was a button on Ethereal’s “Follow TCP Stream” window that would just let me save the data. My tool doesn’t at all track sequence numbers or retransmissions, etc, so I worry that in some situations I won’t get a “true” stream dump. I suspect Ethereal handles that correctly, but I couldn’t tell you for sure.

After looking at this protocol dump, it seems like it ends up turning into some kind of SOAP-like communication, with function call literals like getStreamLength, createStream, play, and closeStream. There’s even a _result variable mentioned. The Flash coding docs I’ve found that talk about stream display don’t seem to mention this stuff at all, but maybe I didn’t dig far enough.

Since RTMP appears to be capable of streams, etc, I think the next step is to figure out how it reacts to things like “Pause” and “Stop” during playback. Clearly there is a stream-identification system in the headers, and there must be stream length indicators. I’m so annoyed that there is absolutely no discussion of RTMP anyway. I should go look at the swf_play source before I go much further.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 8, 2005

madwifi

Filed under: Networking — kees @ 9:59 pm

Woohoo! I found Macrus Crafter’s blog (and webpage) describing how he got a decent wireless miniPCI card (Proxim ORiNOCO 802.11a/b/g) working in his Dell 8500, and I figured it was worth a shot. It worked great in my Dell 8600! One kernel compile later, and the madwifi drivers are in great shape. I just have to test WEP and monitor mode. What a relief after the disappointment of the broadcom chipset. I won’t be buying from them ever.

The soldering was very straight forward. There were 3 solder points on the back holding the EM shield in place over the miniPCI card. Once the solder was wicked off there, I used an exacto blade to lift the tabs up, and continued to wick solder until the cover popped off. Then I wicked solder off either side of the miniPCI card where the card holder fingers had snapped into place. All in all, it took about 15 minutes, and most of that was fighting with the solder on the EM shield tabs.

On the PCI card, the antenna was plugged into the right-most antenna plug. (If looking at the PCI card with the slot down and antenna wire leaving the card to the left.) On the Dell miniPCI card, the plugs are labelled “MAIN” and “AUX”. Since I figured the current plug on the Proxim must be the “MAIN”, I plugged the white cable from the Dell (the one NOT marked “AUX”) into the right-most, and the black cable (marked “AUX”) into the left-most. This was rather awkward, since that required the cables to cross over eachother. So far, so good. I figure it just plain wouldn’t work if I screwed that up. Since I’m currently posting this from my laptop over wireless, I think I got it right. :)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

January 5, 2005

SuSE Firewall

Filed under: Networking,Security — kees @ 5:08 pm

Started looking at the SuSE firewall scripts today. They’re quite nice, actually. So far, they look like they’ll support everything I want to do without any trouble. What’s really nice about it is the resulting script is much more readable than a string of iptables commands (where I’d have to specify the ACCEPT, NAT, and FORWARD for inbound services generally in different places).

What I’d really like to see would be an m4-based version of the script. It’s good enough for sendmail and autoconf, why not iptables? :) That would totally rock, because then I’d be able to see the resulting list of iptables commands. I bet there’s a place somewhere to see them now; but I just haven’t looked.

I’m hoping that this firewall configuration will play nice with heartbeat, which I’ll be using to do some high-availability work on the firewall pair. I’ve had to fight a little with SuSE over the interface names (I want to name the network interfaces after their function, not their boot order). udev has been quite friendly, but SuSE seems to have special meanings for various separator characters. I wanted to have “eth-internal”, etc, but it seems to strip “eth-“. And “eth_internal” turns into “eth/internal”. So, I’m just using “etinternal” instead. :P

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
CC BY-SA 4.0

Powered by WordPress