Categories
System Administration

Rate-limit for swatch

At work, we installed swatch to have a look at our combined logfiles. (see techrepublic or linsec for a swatch intro.)

But contrary to most of the examples, we’re using swatch not to check for known events, but to look out for unexpected entries. So basically our config is “ignore the known, send mail for the rest”:

ignore=/…/
ignore=/…/

watchfor=/./
mail=…..

This has one severe drawback: every single unexpected line in a logfile will send one mail. This just doesn’t scale.

The threshold feature won’t really help us, as it rejects notifications over its limit, whereas for email notifications it’s better to collect more messages into a single email.

So I dived into the code and added a ratelimit feature for the mail Action.

Apply the patch in Actions.pm.diff and then you can write:

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo

and joe will get no more than one mail per 10 mins, without missing a single message.

As written, this config has one problem: I need to flush the messages I held back once I’m allowed to send mail again. In theory, I should have added some sort of timer-based event-handling to swatch, but I considered that to be overkill. Especially if you have multiple mail statements with different rate-limits. So I added another option to the mail Action that tells it just to flush spooled messages and do nothing more. You should trigger that option frequently, e.g. with a stanza like this at the top of your config-file:

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo,rateflush=1
continue

ignore=/ /
ignore=/…/

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo

Categories
Austria Pet Peeves

Yeah, right

Today at the local (small) supermarket:

obst beim zielpunkt

Well, at some point in history, both Spain and (parts of) Italy were part of the Hapsburg Empire, but the rest? Give me a break.

Categories
Life

Life

A sequel to this post:

life in july

Categories
Tracks

Tracks

track 2009-07-02

My aim here was to build a compact set of tracks.

Categories
Tracks

Tracks

Well, sometimes there is no time to build an elaborate set of tracks. Today, I just made a simple loop for Clemens to play with before I had to leave:

track 2009-06-30

Categories
Tracks

Tracks

track 2009-06-27

Categories
IETF Internet

DNSSEC and large packets

In the wake of .org going signed, we finally have good data what that means for the authoritative nameservers. Duane gave a good talk at the recent NANOG event, showing the increase of TCP connections.

So what is the problem?

In a nutshell: Packet sizes. DNS responses containing the DNSSEC specific RRSETs are larger, and setting the DO bit that triggers their inclusion is almost default these days. So we’re now routinely exceeding the 512 bytes that the original DNS spec required. Over the years, the IETF defined EDNS0 which allowed clients to announce their support for larger responses via UDP. Not this is finally really put to the test and we can see how fallback to TCP we still observe.

Continue reading “DNSSEC and large packets”
Categories
CERT Pet Peeves

FUD, the Microsoft way

Dear Microsoft,

we all know that the “Fear, Uncertainty, and Doubt”-strategy worked quite well against Linux and other threats to your Monopoly business. By why do you apply the same tactic towards a Windows user that simply wants to open a zip-file?

microsoft-fud

(Translation: “This page contains an unspecified potential security risk. Do you want to continue?”)

What do you think a user should do with that information?

Categories
Internet Pet Peeves

Heise, Slashdot, Broken Records, and DNSSEC

Almost whenever a security event involving Windows is featured on Slashdot or Heise, some Linux fanboys will invariably post their cocky “that would not have happened with Linux” messages.

I start to see the same thing with DNS incidents and DNSSEC.

This is just as childish and stupid, especially as the voices writing such notes are often enough established engineers and not your average adolescent geek.

In reality most of the recent DNS hacks were not perpetrated by crafting forged DNS responses to poison caches but were successful attacks against the Registrar/Registrant interfaces. No, DNSSEC would not have helped in such a case.

The same is true for DNSSEC and the domain-based censorship which was just passed by the German government. DNSSEC will not help here. It is no panacea against meddling with DNS answers. It depends on who is doing the validation and whether the offending domains are actually signed or not (not likely these days):

  1. DNSSEC validation is done at the ISP resolver:

    DNSSEC doesn’t help the end-user here at all.

  2. DNSSEC validation in the client, ISP recursor is used:

    If the domain is signed, then the user will get a NXDOMAIN (or maybe a better error-reporting) instead of the IP address of the STOP-sign website.

    So the censuring still works, just the alerting of the user (and the logging of the STOP-sign access) does not.

  3. DNSSEC validation in the client, full recursion at the client

    Censorship is ineffective. Just the same as when the local recursor does no DNSSEC checking.

Remember: DNSSEC is not about the availability part of security, it’s only about the integrity. Censorship does not really need to attack the integrity, it’s all about availability.

Categories
Life

Diversions at work

Our office is at a busy intersection and sometimes this provides interesting views:

bim vs rettung