kerneljack’s diary

On the first day of the UKUUG Spring Conference I attended the OpenBSD and PF tutorial. I was asked to write a short review of that tutorial for the UKUUG newsletter. I’m posting what I wrote below:

The superiority of OpenBSD when it comes to security is legendary. The OpenBSD community continuously do security audits of their codebase and their website proudly boasts of having only two remote holes in the default install, in more than 10 years!” PF is the default packet filter used in OpenBSD from version 3.0 onwards.

Having setup OpenBSD firewalls using PF in the past, I was interested in expanding my knowledge and this tutorial provided the perfect opportunity for me to do so. The tutorial was given by Peter M. Hansteen, who is a consultant, writer and sysadmin based in Bergen, Norway, and also the author of the excellent “The Book of PF“, published by No Starch Press.
Peter started off by answering some common questions that people might have about PF such as: Can I run it on Linux (Answer: No, but some are trying). He recommended not trusting any GUI tools, and simply using a text editor to edit pf.conf as that is simpler and faster. In addition, some tools claim to automatically convert “other” firewall rules to PF, but he recommended implementing a fresh PF config yourself.

The first firewall I ever tried to configure for my home network used iptables; when I had to implement one in PF, I found it to be a breath of fresh air. I have always found the concept of “chains” that iptables uses confusing. PF doesn’t have any concept of a chain; you simply start your rules by first “blocking everything”, then enabling the things you need, one line after the other. Although in principle this sounds exactly like what you are supposed to do with iptables, in practice the rules you generate are much simpler, and easier to understand.
Leading on from this, he showed examples of how PF should be set up in an environment where you need a “gateway” between 2 networks, and how to deal with problems faced by people who try to use FTP from behind a NAT firewall (ftp-proxy). Tables and filtering by services (http, ftp, etc) were introduced next. A table in PF is basically a list of IP addresses; listing them in a table makes it easier to apply a single rule to a collection of hosts.
Peter then moved on to the subject of dealing with the huge volume of spam that besieges us all. The two main concepts that he focused this section of the tutorial on were “tarpitting” and “greylisting“. In tarpitting, when a blacklisted host connects to you, you send replies to them very very slowly, let’s say around 1 byte at a time. When doing greylisting, you lie to unknown connecting clients using SMTP 45n errors (temporary local error). This usually thwarts spammers, who simply want to quickly connect, deliver their payload and leave. Many spammers don’t attempt to reconnect after seeing this error, while legitimate clients will automatically retry after a short period of time. These legitimate hosts are then added to a whitelist, which means that the next time they try to connect, they will no longer be given a 45n temporary error, their mail will be accepted immediately.

We then got a look at how to thwart SSH bruteforce attacks by using rate-limiting, and a short introduction to wireless networking in OpenBSD. The next thing that Peter talked about, authpf, was quite interesting. Basically users need to authenticate to authpf first; once authenticated, only then is traffic generated by these users allowed to pass through the firewall. Special rules can be setup specifically for authpf users.
The next topic was load balancing and Peter showed how to configure a “web server pool” using PF. Requests to this pool were alternated using a form of round-robin. To solve a common round-robin problem where machines in the pool go down, you can use “hoststated“, which monitors the state (up/down) of the certain specified hosts and compensates accordingly. hoststated has been renamed to relayd in OpenBSD 4.3.
You can tag incoming packets, so you can quickly pass/block packets marked with a certain tag. Setting up a OpenBSD bridge was discussed next. A bridge in this context simply refers to a transparent firewall that sits between 2 or more networks and filters packets at the link level.
Using ALTQ, you can do bandwidth allocation and traffic shaping. You can used class based queues (percent, kilo, or mega bytes), priority based or hierarchical queues. In a class based queue, you can say for example that FTP is only allowed 20% of your bandwidth.

The last major aspect of PF that Peter discussed was CARP (Common Address Redundancy Protocol) and pfsync. Put simply, CARP and pfsync allow you to setup 2 redundant firewalls instead of 1, and in case one firewall fails, everything switches over to the other firewall automatically. pfsync is used to keep the rules between the 2 firewalls in sync.

Overall, I am very pleased that I attended this tutorial. Obviously I was familiar with some of the concepts, but things like authpf, hoststated and CARP were completely new to me. I will definitely use the things I learned here when considering any OpenBSD based firewalling solutions in the future.

I’m a member of the UKUUG, and I just came back from their Spring Conference, which was held in Birmingham this year. It was a great conference! I met lots of other Unix/Linux people and learned a lot simply by chatting with people in the corridors! I will try my best to make it to the next one, which I think will be held sometime later this year.

In any case, I was asked by Alain (UKUUG Chairman) to write a few words about one of the tutorials that I attended on the first day of the conference. It will be published in the next UKUUG newsletter. I will make sure I post a copy of what I write here.

I decided to update the “About me” page, go take a look, I think it’s quite interesting …

I’ve just installed Compiz Fusion on my 3-year old ASUS laptop which is running Ubuntu Feisty. I’m quite pleased at how stable it is. I tried Beryl a few months ago and it was not usable at all on the same hardware.

I did run into one problem, though and I couldn’t find any solution to it on either the Ubuntu Forums or anywhere else on the net. My top Gnome panel had a strange white bar under it and all my context menus had white borders. Maybe my google-fu wasn’t very good yesterday, but the only solution that I managed to find after about an hour was this on a Gentoo forum:

This is a known issue. Go to ccsm->Window Decorations and add the string !dock to the value Shadow Windows. I had to enter 2 !dock. First disabled shadows of the context menus and the tool tips, the second stops shadows for the gnome-panel.

I’m just putting this here in case it helps someone with a similar problem.

Technorati Tags: compiz fusion ubuntu beryl

Powered by ScribeFire.

Paul Graham has impressed me time and again with his stunning insight. Whenever I read his writings, it’s as if he plucked his ideas out from my own head and then put pen to paper. His latest, Holding a Program in One’s Head, contains several gems that I personally have experienced several times at work.

The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

This is spot-on, and I notice this a lot during my lunch break. Sometimes I can’t get a program or problem out of my head and occasionally I even come up with a solution not 10 minutes into my lunch break and then I can’t wait to get back and finish it. Other times however, especially if I have lunch with my colleagues the whole ‘problem space’ I’ve built up in my head simply vanishes. Due to the amount of work it usually takes (maybe a half-hour to an hour) to re-load my brain with the problem I was working on, a lot of post-lunch time is wasted and sometimes I can never recreate the problem fully again because I tend to be sharper in the mornings than in the lazy afternoons.

Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones.

I have often wanted to do this, but it’s almost impossible to do. There is always lunch, some other interruption, going home, eating dinner or something similar. On the weekends, however, I sometimes manage to stay up late and can work uninterrupted for quite a while.

Rewriting a program often yields a cleaner design.

True sometimes, but I agree with him that even the process of rewriting a program can lead to significant insights; even if the rewritten program is not a huge improvement.

Instead of summarizing the whole essay here, I highly recommend that all programmers and their managers go read it. Even non-IT staff, such mathematicians, whose work involves long-stretches of thinking, and constructing problem spaces in their heads will benefit from the advice in this essay.

I haven’t been paying attention to my RSS feeds recently and I forgot just how good some people are at writing and expressing their insights Paul Graham and Joel On Software are two blogs (journals?) that I really enjoy reading.

Technorati Tags: coding programming software

I’ve spent the past 2 weeks on and off reading ‘Bugs in Writing’ and have definitely learned about some mistakes to avoid in writing. In order to fix these mistakes, it is best to do a lot of your own writing so you can find them and eliminate them. I will try to write a brief note about some common mistakes here. I haven’t asked the author for permission, so I will try to do it here in a very general and concise manner.

#1. Avoid using passive voice. Passive voice just means that when you say something about the world or some event that happened, make sure you identify ‘who or what’ was involved. The ‘who or what’ is commonly referred to as an agent.

For example,

Wrong:
The tea was made.
The program was written.
The computer was dropped.

Correct:
Mark made the tea.
Jane wrote this computer program.
Christopher dropped the computer.

#2. Speak directly to your reader. Never address your audience as the reader or refer to yourself as the author. You should speak directly to your reader. You should refer to her as you. If you are the sole author of a book, use I and if you have co-authors, use we. In addition, avoid using one, as in One should realize … or One has written.

#3. So, So that and Such that. Just remember the following:

So means therefore
So that means in order that
Such that means in such a way that

#4. Two or more. Use the terms between, each other, either, and a couple to refer to precisely two entities; and you should use among, one another, any one of, and several to refer to more than two entities.

I will add some more tips later on, but probably not many. The problem is that I haven’t gotten permission from the author and several of the tips have examples that are best quoted verbatim from the book.

I know I haven’t updated this blog for a while … in fact I frequently abandon it for a few months while I carry on with life’s struggles. Keeping up with my job, finding time to spend with my beautiful wife, all the while attempting to keep current with the fast pace of technology growth.

Starting today, I will try and change that. You see, in order to motivate myself to keep this blog updated I have decided to set myself a goal and complete it. I will keep updating this blog not only with my progress, but will also write about what I have learned as I go along.

So my first goal will be ‘to improve my writing skills’. I have enjoyed writing stuff for a long time now and friends have occasionally told me that ‘you could be a really good writer’. Well I’ve finally decided I should give it a shot.

To be honest, I’ve never been good at grammar, and people find that hard to believe. I’ve simply developed a good ear for what ’sounds right’ based on my perusal of several newspapers, magazines, novels and books over the years. Learning a lot of vocabulary while preparing for my SATs and reading ‘lots’ has really helped.

The first book I’m going to try and read and understand is going to be Bugs in Writing, which I bought several years ago, but never got around to reading. It is written mainly for people who come from a scientific or technical background and hence is perfectly suited for someone like me. Each chapter aims to analyse and fix a single ‘problem’ and you can read each chapter in whatever order you like.

With that, I bid you farewell. I believe my next post is going to be about ‘passive/active voice’. Exciting times indeed

Fedora 7 is released!: I really liked the last Fedora release, but I believe it was slightly plagued by problems with some of it’s package management utilities. I have already installed this release and am quite impressed. Wireless now works with WPA out of the box and their new re-spinning feature is something I will try out someday.

XML Parser benchmarks: I have always had my own suspicions of which XML parser model would be faster (Sax or StaX), but I’m glad to see this benchmark done by the O’Reilly folks.

Fear and loathing at Cupertino: Jeremy Allison’s terrible experience while trying to prepare a talk for his Apple WWDC presentation. Jeremy works on Samba, along with Tridge, who they all call “the smartest man in Australia” Jeremy works at Google now. Smart man.

I’m going to occasionally post links here that I find particularly insightful, interesting or geeky.

Three things that caught my interest today:

PowerTOP: Released by Intel, this utility builds on work done by kernel developers to make the Linux kernel power-efficient. PowerTOP gives you a snapshot of what apps are consuming the most power. Turn off these apps or modify their behavior, and you’ll notice an instant increase in the battery life.

The Linux SLAB Allocator: Traditional heap memory managers suffer from fragmentation, among other issues. The SLAB Allocator in Linux, inspired by a similar implementation for Solaris and various embedded systems, allocates memory as fixed sized objects and uses caches to reduce fragmentation. It also has options to enable hardware cache alignment which allows objects in different caches to share the same cache lines, thus improving performance.

Advanced Linux Programming: After many years of coding mostly Java, I’ve been meaning to brush up on my C, Assembly and general Unix programming skills. I found this excellent book freely available online and it seems to be getting a lot of praise from reviewers on Amazon so I downloaded it. It has a lot of topics that I’m very interested in, like IPC and threads, and it even has a few assembly oriented chapters. I will definitely be reading this one

We have just come back from a brilliant trip to Switzerland! The weather was awesome throughout our trip. We spent most of the time in Lucerne, where we stayed at the Hotel Drei Koenig. On our first day we decided to wander around Lucerne’s Old Town and see as much of it as possible. We ended up quite dreadfully tired and in the evening we just went back to the hotel and simply crashed.

We went on a trip to Mount Titlis the next day. Mount Titlis is one of the highest mountains in Switzerland, at 10,000 feet. I must admit to feeling quite terrified at that height. I was feeling quite disorientated.

The next day we made a long hiking trip up Mount Rigi-Kulm. To get to the start of the hiking point, you have to take a cruise along the river, then a trip up the mountains by train, before you get to your starting point. This is the day of our trip which I think we enjoyed the most.

We spent the rest of the trip in and around Lucerne and on the last day we made a day trip to Zurich. This allowed us to catch our flight straight from Zurich Airport back to London. All in all, a wonderful and highly recommended to anyone interested