Zugschlusbeobachtungen

Ich sitze hier gerade in einem Vortrag über Open Source im Auswärtigen Amt. Der erste Satz, den ich - knapp zehn Minuten zu spät kommend - auf der Folie sehe, ist "Debian als führendes Betriebssysem".

Auf der nächsten Folie steht dann "Nagios, Munin als Ablösung für HP OpenView". Ich glaube, mein Tag ist gerettet.

Die DSL-Router aus Thomsons SpeedTouch-Serie genießen den Ruf, eine ausgezeichnete Modembaugruppe zu haben und außerdem auch als reines Modem betreibbar zu sein. Das war für mich genug Grund, mir mal so ein Gerät aus der Nähe anzugucken.

For nearly two years, I have been pondering about a good and failure-resilient DNS setup to implement for my own domains. In the last days, I have set the first prototype into use.

No, I haven't dared to touch zugschlus.de, my most important domain, yet. This is planned for the weekend. So, if you experience difficulties in accessing any of my Internet services, please inform me and allow me to fix the issue.

Dec 29 11:23:51 scyw00225 kernel: Critical temperature reached (4822 C), shutting down.

Right after your system has shut down while booting up in the early morning.

Yesterday, Philip Hazel released exim 4.64. I have just uploaded the packages to Debian experimental. If you want to try the lastest and finest exim, please check out the packages.

Unfortunately, the release is too late for etch. Debian etch will release with exim 4.63. I mean, unless the release team decides to bend their rules very badly, which I really do not assume.

Hallo Dirk, zu Deinem Artikel möchte ich noch hinzufügen, dass Serendipity 1.0.2 ein Security-Update ist, das XSS Vulnerabilities behebt.

Man möchte dieses Update also nicht verzögern, sondern unverzüglich installieren!

Das Bundesministerium der Justiz bereitet einen Gesetzentwurf vor, der den Schutz vor Computerkriminalität mit strafrechtlichen Maßnahmen verbessern soll. Und handelt Deutschland erneut den Verlust von zahlreichen hochqualifizierten Arbeitsplätzen im Hochtechnologiesektor ein.

While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI.

If you are putting an URL containing brackets in the section title of an .ini-like formatted file, you'd better use percent notation for the brackets in the URL.

Sorry for yesterday's Planet flood. I hope it will be less painful this time.

PlayingExperimenting with arping, I found the following behavior:

$ sudo arping -c 1 10.202.202.254
ARPING 10.202.202.254
60 bytes from 00:0f:20:d4:07:e0 (10.202.202.254): index=0 time=196.934 usec

--- 10.202.202.254 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$ sudo arping -c 1 10.101.2.1
ARPING 10.101.2.1
60 bytes from 00:0f:20:d4:07:e0 (10.101.2.1): index=0 time=168.085 usec

--- 10.101.2.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$

wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don't think it is ok to answer ARP requests for that IP address on "my" interface, as it confuses some "what network segment am I on today" mechanisms.

Is there some /proc setting where I can disable this rather generous ARP behavior?

Die meisten restriktiven Security Policies haben inzwischen ein Alter von drei bis fünf Jahren erreicht. Damals hat man das als Policy niedergelegt, was im gerade führenden Fachbuch stand, und somit auch schon einige Jahre auf dem Buckel hatte. Auf solch einer alten Policy aufgesetzte Sicherheitsmaßnahmen, die typischerweise das böse Internet mit einer (!) Firewall von dem einen (!) internen Netz abtrennen und bestenfalls eine kleine Handvoll Servicenetze (vulgo "DMZ", wobei "mehr als ein Servicenetz" immer noch mit "Respekt! Das ist aber gut durchdacht!" kommentiert wird) beinhalten, sind in der heutigen Welt kaum mehr zeitgemäß; es ist Zeit, hier anzusetzen.

I am wondering whether it is currently possible to run a personal laptop with Debian unstable and some init scheme that allows parallel startup of the services. Naturally, it would be very good to start the X server early to be able to log in faster.

Is this concept ready for testing and use? Which packages should I investigate? Any URLs that might be enlightning?

Im Microsoft Technet stehen von Zeit zu Zeit echte Perlen. Aber die hier ist so gut (und so wahr), dass ich sie sogar hier zitieren muss.

Jesper M. Johansson, Ph.D., CISSP, MCSE, MCP+I, seines Zeichens Security Program Manager bei der Microsoft Corporation, schreibt in einem Artikel mit dem Titel "Help: I Got Hacked. Now What Do I Do?" aus dem Mai 2004:

• You can’t clean a compromised system by patching it. Patching only removes the vulnerability. Upon getting into your system, the attacker probably ensured that there were several other ways to get back in.
• You can’t clean a compromised system by removing the back doors. You can never guarantee that you found all the back doors the attacker put in. The fact that you can’t find any more may only mean you don’t know where to look, or that the system is so compromised that what you are seeing is not actually what is there.
• You can’t clean a compromised system by using some “vulnerability remover.” Let’s say you had a system hit by Blaster. A number of vendors (including Microsoft) published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? I wouldn’t. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it? I didn’t think so.
• You can’t clean a compromised system by using a virus scanner. To tell you the truth, a fully compromised system can’t be trusted. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm and you know that this virus has no back doors associated with it, and the vulnerability used by the virus was not available remotely, then a virus scanner can be used to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action, then you can’t guarantee that the worm was the only thing that used that vulnerability. It is entirely possible that something else used the same vulnerability. In this case, you can’t just patch the system.
• You can’t clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that tell the installer lies. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have put back doors in non-operating system components.
• You can’t trust any data copied from a compromised system. Once an attacker gets into a system, all the data on it may be modified. In the best-case scenario, copying data off a compromised system and putting it on a clean system will give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a back door hidden in the data.
• You can’t trust the event logs on a compromised system. Upon gaining full access to a system, it is simple for an attacker to modify the event logs on that system to cover any tracks. If you rely on the event logs to tell you what has been done to your system, you may just be reading what the attacker wants you to read.
• You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs cannot be trusted to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
• The only way to clean a compromised system is to flatten and rebuild. That’s right. If you have a system that has been completely compromised, the only thing you can do is to flatten the system (reformat the system disk) and rebuild it from scratch (reinstall Windows and your applications). Alternatively, you could of course work on your resume instead, but I don’t want to see you doing that.

Ein weiser Mann. Ich wünsche mir, dass einige Manager in Zukunft auf diesen weisen Mann hören.

Gefunden hab ich das übrigens bei Dirk, und der hat's von El Loco.

The new wpa_supplicant packages have removed the /etc/wpa_supplicant.conf file. Wireless LAN is now configured via special commands from /etc/network/interfaces, which looks like an elegant Debian way to do things.

While setting this up, I have learned the following:

• an ESSID starting with "+" is not accepted
• You don't enter the passphrase verbatim into /e/n/i, you use wpa_passphrase to hash it
• wpa_supplicant debugs surprisingly well

Well done, maintainers! Thanks!

Next time I'll figure out how to configure wpa_supplicant to automatically associate to the correct wireless LAN regardless of location

To support my experiments with OpenVPN, I have been trying to evaluate different CA software packages in Debian. With devastating results.

I tried

• pyca
• tinyca
• easy-rsa (from the openvpn package)