aporem.net

Did you ever wonder why the lights on your network card (respectively your network switch) flickered although you didn’t do anything network based?

There is a neat application called netstat to answer this sort of questions.
A simple netstat will give the complete list of any connections established. Mostly this is not what you want.
To see just the TCP connections (both IPv4 and IPv6), type netstat -p tcp.
This works analogously for UDP packets (there are several other supported protocols, but these should handle all the relevant traffic).
Also you can specify the protocol family to see just IPv4 or IPv6 packets, by executing netstat -p tcp -f inet or netstat -p tcp -f inet6 respectively.

The colums are self-explanatory, so you should get along quite well in a couple of minutes. Just remember that UDP is a stateless protocol and therefore the last column is always empty.

As I’ve pointed out in my last post, it’s obviously a good idea to have an eye on your logs. Also very obvious is the fact that the logs tend to be cluttered with the same sort of message endlessly repeated.

But beware! Since the messages in the logs are automatically generated, they only seem to be the same. The information (although important) is often hidden in the last part of the message, out of reach if you read the logs with a text viewer without line-wrapping. Additionally, you can not generalize from the first 40 lines of a 10MB log file! Sadly, the human perception tends to take the short cut and make generalizations very quickly and tries to look only for similar entries further on.
Hence you need a tool to make a quick search for one type of message, extract the relevant fields and display the results sorted (and counted if appropriate).

I’ve put together a simple shell script looking for failed ssh logins in the auth.log and displaying a short summary of the IP addresses where the requests came from.

#!/bin/sh

grep "Invalid user " /var/log/auth.log | cut -d' ' -f11 > /tmp/$$.list
grep "Did not receive identification string from " /var/log/auth.log | cut -d' ' -f13 >> /tmp/$$.list
sort /tmp/$$.list | uniq -c | sort -n
rm /tmp/$$.list


This is surely not a very sophisticated tool nor are the results relevant without further investigation but it helps to decide if there is action to be taken or not.

From the “lazy administrator” series:
One of the tasks an administrator has to perform on a regular basis is to check on the logs. This is undoubtedly the thing to do for getting an idea what’s going on on the machine. But since it’s such a tedious task skimming through tons of unimportant log entries, enthusiasm rapidly decreases.
Having a heart for the admins, the FreeBSD developers have put together a system of status notification emails mailed to root periodically.
These emails give a short report on things done by the operating system automatically every night such as removing stale files or backing up important ones. Additionally, the disk usage and network status are summarized and an overview of the activity of the mail server is given.
The style of the reports is quite condensed such that one can perceive the important informations quickly. This is also the reason why the security output is mailed separately. (It can be full of uniform warnings.)

While these mails can’t (and never tried to) replace an intrusion detection system, they give surprisingly well hints if something on the box is flawed. And it don’t always has to be an intruder who breaks havoc. Even simple things like a misconfigured program causing mail loops or filling up sensitive parts of the filesystem can be catched reading these mails.

So go out and read your “daily run output” on a daily base!

Generally speaking, there are two incentives to upgrade a port: either there are new features you want or bug fixes you must have.
For high profile applications it’s often not too hard to track the developement process, since major releases and major bugs or security breaches are often covered widely. But what about all the rest? There are 15000 ports available and not every one is as popular (in the sense of: well known and spoken about) as apache or mysql.
That’s where portaudit comes in. It keeps an eye on the FreeBSD VuXML database and alerts you if one of your installed ports has a security issue.
For a first start, simply run portaudit -Fa which will fetch the latest database and give you an output of affected packages, together with a short description of the vulnerability. For consecutive peeks to the database, you can omit the -F option, since the latest version is fetched autmatically by a cron script.
The best thing about portaudit is, that you don’t even have to run it manually because it will hook itself into the “daily run security output”.

Thus using portaudit you will have more time to spend reading feature related update news! (It’s a pity there is no automated tool for this…)

It is rare that quality of code is covered in the press or mentioned in the press release of a programming project. More often than not, it’s used as a pretext for delays.
But the quality of code has little to do with the style of the sources or the number of bugs the program may contain. It’s how easily the idea behind the code can be accessed by the reader.
Although obvious, this point is not well enough appreciated and teached to beginners. More often it’s expressed like a warning, that great care has to be taken up front to avoid problems later, but no specific details are given.

So here is my little check-list for good code:

• First of all, understand the algorithm which should be implemented.
• The coding standard used, should fit the language, the project and the external factors.
• Good code is not necessarily short code, although the building blocks ought not exceed certain limits.
• Explanations should address the motivation behind the code, because it’s already in the sources what it does.

By checking existing code against this list, one has a good reference point to estimate the quality of the code.
And reading good code will make you a better programmer.

But this is another post…

In the documentation of wordpress there is a section called “Planning Session” which asks the following questions:

1. What am I going to do with this?
2. Who is going to read this?
3. What kinds of information will I be posting?
4. Why am I doing this?
5. Who am I doing this for?
6. How often am I going to be posting and adding information?

This is quite a blow to sites like mine, since there is no easy answer to any of the questions above.
So I had to come up with at least one idea of what kind of content I want to put on my site. And that’s where my passion of reading books on programming (although I rarely write code) came in.

Hence here it is: the new category called programming, where I will post my rants and opinions about the writing of code.

“Alas, a new look again!”, the sporadic passer-by might think, and yes, since the change from the self-written to a CMS-managed site this is again a major overhaul of my presence on the web.
And since wordpress is a blog-software, I feel much more obliged to post a rant once in a while.

The old site can now be found at /old/, the former old site at /old/old/.

Eventually, I’ve decided not to transfer anything else than the link collection from my old site here since it isn’t something genuinely new or unique.

One of the first things to change for a new website is to give it a unique look. Or at least to change the default theme to something less generic. Since I’m quite new to wordpress, designing a theme was not quite an option.

Luckily, the community has addressed this problem an set up a site with a bunch of themes to start tinkering with.

So this is it, the shiny new style of my page!

One of the most common tasks for a FreeBSD administrator is keeping the port collection up to date. Traditionally, one uses cvsup as described in the Handbook. But Colin Percival, currently the security officer of the FreeBSD project, came up with an alternative solution: portsnap

The new sync tool addresses directly the drawbacks of cvsup: it is “just” an add on to cvs and therefore designed to check out those parts of the tree that have changed, assuming the developer in front of the machine knows where the changes are. It is quite slow in tracking down small changes in a huge tree (like the ports collection).
Additionally, the transport of the data is not secured by any means, so the admin cannot check if the things he gets are those from the server or a third party.

Changing from cvsup to portsnap is quite easy. Just disable the scripts calling cvsup and portsnap fetch; portsnap extract; portsnap update.
After this first full extraction, one can add a simpe script just calling portsnap fetch; portsnap update.

Mind that in order to avoid peak loads, use porsnap cron in cron scripts.
And don’t call porsnap update automatically, it will undo any changes to the ports tree, work directories included!

These two litte commands can make the life of an administrator much easier, but most admins aren’t even aware of their existence.

pgrep searches the process table and returns a list of PIDs matching the search pattern. Using the -fl option, one can extend the search to the full argument list of the processes. This is equivalent to ps ax | grep, but you don’t get the PID of its own command back as a search result! The well known options -v, -i of grep work as expected, as well as the options of ps, like -t, -u, -g.

pkill acts much like killall, but with the power of pgrep added to it.

All in all these tools come in handy in shell-scripts or as a quicker alternative to ps ax | grep.