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?
(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?
I almost forgot: one of the reasons I was in Amsterdam was the DNS-OARC Workshop. I gave two presentations there:
An update on the post-Kaminsky patch statistics concerning the Austrian recursors.
Stephane asked me to be on a panel regarding what Registries should do about Conficker (and similar threats). I presented our point of view with these slides.
As a followup to Aaron’s talk at Linuxwochen Wien, Claudia Glechner from ORF visited the CERT.at offices to interview us.
The resulting article is now online at futurezone.orf.at.
Dear Evanzo,
the contact emails in the whois records for the domains you manage are there for a purpose: If there are troubles with these domains, the responsible people can be contacted in order to get the problems fixed.
And there is a good reason these whois data is not just a blob of Ascii, but structured data: Scripts can parse the records and e.g. automatically send email to the right address.
Getting back autoreplies stating basically “please use this web-form” is not going to cut it. We will not special-case our scripts to fill out web-forms just to accommodate your setup.
You, and your customers will simply not get our Mails regarding defaced Websites hosted by your service.
Your decision, your loss.
Today I gave a talk at the ISPA office concerning DNSSEC. See here for the official announcement.
Attendance was good, we had interesting questions and a lively discussion.
You can download my slides in pdf format.
This is one of the “simple” problems which always take longer to solve than expected.
The goal: Script RTIR to generate Investigations associated with an Incident.
In order to do that, I needed to solve the following who subproblems:
Basically, I needed to capture the STDOUT of the “rt” command, and let also rt invoke vi. My solution:
--- /usr/bin/rt 2007-10-31 11:52:20.000000000 +0100
+++ /usr/local/bin/rt 2008-08-20 14:14:20.000000000 +0200
@@ -1335,7 +1335,7 @@
local $/ = undef;
open(F, ">$file") || die "$file: $!\n"; print F $text; close(F);
- system($editor, $file) && die "Couldn't run $editor.\n";
+ system("$editor $file < /dev/tty > /dev/tty") && die "Couldn't run $editor.\n";
open(F, $file) || die "$file: $!\n"; $text =
unlink($file);
The “Autoreply on Create” Scrip is supposed to mail out the newly created content to the Requestor, thus I needed to not only provide plaintext while the creation, but also all the attachments that need to be sent out to the Requestor.
Adding text is simple, just use “Text: foo bar” to the Template. But attachments are simply not supported for “rt create” (and not that easy to add in the code). They are supported for “rt correspond”, so I can sidestep the “attachment on create” problem by simply splitting up the work into an empty “rt create” followed by a “rt correspond -a file”.
There is just one gotcha: The Autoreply script will happily mail on ticket creation with an empty mail.
Solution: Change the “Condition = On Create” for the Scrip to “Custom” with
my $t = $self->TransactionObj;
return 0 unless ($t->Type eq "Create");
my $c = $t->ContentObj;
return (defined($c)) ? 1 : 0;
In April I speculated about the impending doom of the DNS.
Now we know what was in the works, and yes, it’s not a pretty picture.
My idea from april doesn’t work 1:1, as the attacker doesn’t attack a single target, sondern arbitrary other hostnames in the same domain.
Anyway, I spent the last days analyzing data from .at nameserver regarding patch discipline in Austria. You can read the depressing results here.
Assume you have a number of patterns you might want to watch out for in various logfiles. These could be harmless, e.g. postfix/smtp\[[[:digit:]]+\]: .* status=sent which indicates that a mail was sent by postfix, or could be bad, e.g. indications of hardware troubles, firewall log entries or suspicious entries in proxy logs.
There are a number of tools which can help you do that, e.g. logwatch can produce nice reports for you.
In my case, I was less interested in individual log entries, but in a graphical representation of their frequency. For that, I need something similar to MRTG. Cacti is a decent graphical frontend to the core MRTG engine, rrdtool. It provides various data sources and graphing options all packed up into a neat web interface.
So, what needs to be done to get Cacti to graph match-rates of regexs in logfiles?