The Commandline Tool Blog

Anscheinend hat der BlueZ-Bluetooth-Stack die Verantwortlichkeit, eine Möglichkeit zur Passcode-Eingabe bereitzustellen, an die jeweiligen Desktop Environments abgegeben, indem sie einfach nur einen entsprechenden dbus-event schicken, wenn ein Passcode gebraucht wird.

Das ist natürlich dann ungünstig, wenn man kein Desktop Environment benutzt oder das DE keinen solchen Passcode-Dialog mitbringt. Leider wird die vorhandene Commandline-Version in BlueZ vom Makefile nicht mitinstalliert, wodurch die Pakete sie natürlich nicht enthalten.

Abhilfe schafft, die Quellen des Pakets zu laden, selbst zu kompilieren (dauert nicht lange) und dann direkt den passkey-agent auszuführen:

sudo apt-get source bluez-utils
cd bluez-utils-3.1/
./configure && make
./passkey-agent

Anschließend sollte man sein Gerät mit dem Computer pairen können.

Wer die Google-Dienste gerne per IPv6 nutzen möchte (nicht nur ipv6.google.com, sondern auch maps.google.com, gmail, etc…), der hat seit geraumer Zeit die Möglichkeit, den eigenen DNS bei Google whitelisten zu lassen und dann direkt AAAA-records zu bekommen für die jeweiligen Hosts.

Wer sich allerdings den Aufwand sparen möchte, selbst einen passenden Whitelist-Eintrag anzufordern, oder wem dieser verweigert wurde (Netz zu klein o.ä.), der kann den DNS-Server von Hurrican Electrics nutzen. Dieser ist auf der Whitelist von Google und öffentlich nutzbar.

Da man nun aber selten seinen kompletten DNS umstellen möchte, nur damit eine Zone ordentlich resolved, kann man bind so konfigurieren, dass er nur für Queries auf die google-Zone die Anfragen an den HE-Server weiterleitet:

# HE DNS server for google IPv6 service
zone "google.com" IN {
   type forward;
   forward first;
   forwarders {
       2001:470:20::2;
       74.82.42.42;
   };
};

$ host www.google.de
www.google.de is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.129.99
www.l.google.com has address 209.85.129.147
www.l.google.com has address 209.85.129.103
www.l.google.com has address 209.85.129.104
www.l.google.com has IPv6 address 2001:4860:a003::68

Wenn man sich wundert, wieso die Anforderung eines krbtgt/NET.ZEKJUR.NET@ZEKJUR.NET überhaupt stattfindet, anstatt dass man sich auf seinem Rechner einloggen kann, sollte mal kontrollieren, ob sein DNS ordentlich funktioniert.

In diesem Fall war ein T-Online DNS eingestellt, der standardmäßig auf nicht existierende Records einfach die T-Online-Suchseite zurückgibt. Das kracht genau dann, wenn der Zielhost nur einen AAAA-record hat, sodass kein A-record existiert. Dann kriegt der anfragende Client für die Anfrage host.zekjur.net.zekjur.net (warum das überhaupt angefragt wird, weiß ich auch nicht, aber das kann man ein andermal debuggen) eine Antwort und denkt, er müsse sich für NET.ZEKJUR.NET cross-realm-authentifizieren.

Lösung: Ordentlichen DNS verwenden (oder DNSSEC?) und gut ist.

Da dieser Artikel so langsam aus dem Google Cache fliegt, nicht auf web.archive.org ist und das original-blog gelöscht wurde, poste ich ihn hier nochmal. Danke an Hal Pomeranz für den hilfreichen Artikel.

Mounting Unix file system images is a common investigative technique, because it allows examiners to use standard file system tools (e.g., find, grep) to look for evidence. However, sometimes you run into difficulties:

# mount -o loop,ro dev_sda2.dd /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So what’s going on here? Well, let’s try the dmesg command suggested in the above error message:

# dmesg | tail
[...]
[565633.964688] EXT3-fs: INFO: recovery required on readonly filesystem.
[565633.964698] EXT3-fs: write access unavailable, cannot proceed.

Actually, in this case the “file” command can provide us with more succinct information:

# file dev_sda2.dd
dev_sda2.dd: Linux rev 1.0 ext3 filesystem data (needs journal recovery)

See the “needs journal recovery” bit at the end? Looks like the image comes from a machine that was shut down ungracefully, and the ext3 file system driver wants to sync the operations in the file system journal before allowing the file system to be mounted.

Now we could mount the image read-write and allow the journal to be flushed, but the concern is that we’d be damaging the forensic integrity of the image– to say nothing of losing actual evidence. In fact, the file system in the image is probably in a decent enough state that we could actually mount it, if only there were some way to coerce the file system drivers into not requiring a journal recovery. Needless to say, I wouldn’t be writing this article unless there was a way to do this…

The Alternate Superblock Trick

As most of you are aware, Unix file system metadata is kept in the superblock at the beginning of the file system image. The superblock stores information like file system state (clean or dirty), last mounted time and location, and pointers to the root of the file system, free block and inode lists, and the file system journal (if any). For redundancy, the primary superblock is replicated throughout the file system. That way if you lose the primary superblock for some reason, you can often recover the file system using one of the alternates, depending on the nature of the corruption.

However, the data in the primary superblock is not perfectly replicated to the alternates. Most important for our purposes, the file system clean/dirty information that’s causing the ext3 file system drivers to require a journal recovery is not flagged in the alternate superblocks. The upshot is that if we tell the mount command to use an alternate superblock, the OS will allow us to mount the file system image without requiring a journal recovery. The hard part is figuring out where the alternate superblocks live and then setting options for the mount command appropriately.

Mounting With Alternate Superblocks

The first step is to discover the location of the alternate superblocks. The trick is to use mkfs with the “-n” option. As with many other Unix commands, “-n” means “show me what you would do, but don’t actually do it”:

# mkfs -n dev_sda2.dd
mke2fs 1.41.3 (12-Oct-2008)
dev_sda2.dd is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
58880 inodes, 235516 blocks
11775 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=243269632
8 block groups
32768 blocks per group, 32768 fragments per group
7360 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

There are two important pieces of information in the above output. The first is obviously the list of alternate superblock locations at the end of the output. But we also need the block size information from earlier in the output.

Why is the block size relevant? It turns out that the mount command wants you to specify the alternate superblock location in terms of 1K offsets. But mkfs is reporting the alternate superblock addresses in terms of 4K blocks, so we’ll need to multiply the values reported by mkfs by four in order to produce addresses we can feed into the mount command.

You can use any of the alternate superblock addresses you want– let’s just use the first one. The offset we need to feed into the mount command then is 32768*4 = 131072. The mount option for specifying an alternate superblock is “sb=”:

# mount -o loop,ro,sb=131072 dev_sda2.dd /mnt
# ls /mnt
bin   dev  home    lib         mnt  proc  sbin  usr
boot  etc  initrd  lost+found  opt  root  tmp   var

Excellent! We can now view the contents of our file system image as a mounted file system.

Da es nur halbgare Scripts und unzureichend funktionierende Javascript-Servlets gab, habe ich dieses kurze Perl-script geschrieben, welches einem die aktuelle Session anzeigt (sprich: die URLs der Tabs für jedes Profil und für jedes Fenster):

#!/usr/bin/env perl
# vim:ts=4:sw=4:expandtab

use strict;
use warnings;
use JSON;
use IO::All;
use File::Basename qw(basename);

for my $session (io($ENV{HOME} . '/.mozilla/firefox')->all) {
    # Skip all non-directories
    next unless io($session)->is_dir;

    # Skip the session if it has no sessionstore.js
    next unless (-e $session . '/sessionstore.js');

    print "Dumping session " . basename($session) . ":\n";

    my $sessionfile = io($session . '/sessionstore.js')->slurp;

    # Strip the leading and trailing parenthesis
    $sessionfile =~ s/^\(//;
    $sessionfile =~ s/\)$//;

    # Parse the JSON file
    my $session = from_json($sessionfile);

    for my $window (@{$session->{windows}}) {
        print "Open tabs in this window:\n";
        for my $tab (@{$window->{tabs}}) {
            # The number of the selected tab (inside the entries for this tab)
            # is stored in 'index'. If it is not present, the tab was not yet
            # saved, probably because it's loading.
            if (!defined($tab->{index})) {
                print "  \n";
                next;
            }
            my $idx = $tab->{index}-1;
            # Get the tab's URL
            my $url = $tab->{entries}[$idx]->{url};
            print "  $url\n";
        }
        print "\n";
    }
}

Das ist insbesondere dann praktisch, wenn man unterwegs ist und sich dachte: „Hmm, ich hab da doch so ein Tab zuhause offen…“

Normalerweise kann man in bacula einfach das mitgelieferte bsmtp benutzen, oder einfach sendmail, wenn man die Reports verschicken möchte (ja, möchte man). bsmtp existiert übrigens, weil lustigerweise sendmail bzw. mail jeweils eine Option fehlt: sendmail(1) hat zwar sender (-f) aber nicht subject. mail(1) hat zwar subject (-s) aber nicht sender.

Wenn allerdings der Mailserver, wo die Mail landen würde, auf dem selben Rechner läuft, kann man sich diesen unnötigen Hop auch sparen. Allerdings kann auch dovecots deliver(8) nicht beide Optionen, sodass man sich einen simplen Wrapper schreiben muss: (bei mir in /etc/bacula/mail.pl abgelegt)

#!/usr/bin/env perl

use strict;
use warnings;
use Getopt::Long;

my $subject = 'Message from bacula';
my $from = 'Bacula';
my $mailbox = 'daemons';

GetOptions(
        'subject=s' => \$subject,
        'from=s' => \$from,
        'mailbox=s' => \$mailbox
);

my $recipient = shift;
die 'No recipient specified!' unless $recipient;

my $output;
open($output, "|/usr/lib/dovecot/deliver -d $recipient -m $mailbox");
print $output "From: $from\n";
print $output "Subject: $subject\n";
print $output "To: $recipient\n";
print $output "\n";
# Ganz STDIN auslesen und an deliver(8) übergeben
print $output "$_" while ();
close $output;

Aufgerufen werden kann das ganze dann z.B. so:

Messages {
        Name = Standard
        mailcommand = "/etc/bacula/mail.pl -f \"Bacula\" -s \"%t %e of %c %n (%l) \" %r"
        operatorcommand = "/etc/bacula/mail.pl -f \"Bacula\" -s \"%t %e of %c %n (%l) \" %r"
        mail = michael = all, !skipped
        operator = michael = mount
        console = all, !skipped, !saved
        append = "/var/log/bacula/main.log" = all, !skipped
}

apt-get install mediawiki libapache2-mod-auth-kerb
vi /etc/apache2/sites-enabled/000-default

        Alias /wiki /var/lib/mediawiki

        <Directory /var/lib/mediawiki/>
                Options +FollowSymLinks
                AllowOverride All
                AuthType Kerberos
                AuthName "Wiki"
                Krb5Keytab /etc/apache2/krb5.keytab
                require user foo@REALM.NET
        </Directory>

        <Directory /var/lib/mediawiki/config>
                Options -FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/lib/mediawiki/upload>
                Options -FollowSymLinks
                AllowOverride None
        </Directory>

Eine Keytab bauen auf dem KDC (Befehle für heimdal):

kadmin -l
add --random-key HTTP/fqdn.of.webserver
ext_keytab -k /etc/apache2/krb5.keytab HTTP/fqdn.of.webserver

Bequem das Wiki via Browser installieren, dann die Config an den richtigen Platz schieben:

mv /var/lib/mediawiki/config/LocalSettings.php /etc/mediawiki/

Anschließend von http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER die extensions/Auth_remoteuser.php laden und in /etc/mediawiki/LocalSettings.php einbinden:

require_once('extensions/Auth_remoteuser.php');
$wgAuth = new Auth_remoteuser();

Im debian-wiki liest man, wie man die offiziellen Kernelpakete neu baut. Die Methode hat allerdings den Nachteil, dass es richtig lange dauert, bis man letztendlich ein Header- und ein Kernelpaket enthält. Außerdem kann man keine LOCALVERSION angeben im Kernel, sieht also nicht, ob man gerade einen eigenen Kernel verwendet oder nicht.

Daher ist (zumindest derzeit) kernel-package (make-kpkg) die besser Wahl. Dort gibt es allerdings die Änderung, dass man mittlerweile nicht mehr vollautomatisch eine initrd erstellt bekommt, was daran liegt, dass der Maintainer meinte, man müsse die Funktionalität auf den kleinsten gemeinsamen Nenner reduzieren (Details in einem Post auf debian-devel zu finden).

Jedenfalls kann man das alte Verhalten folgendermaßen wieder erlangen:

# cp /usr/share/kernel-package/examples/etc/kernel/postinst.d/initramfs  /etc/kernel/postinst.d/initramfs-tools
# cp /usr/share/kernel-package/examples/etc/kernel/postrm.d/initramfs  /etc/kernel/postrm.d/initramfs-tools   
# cd linux-2.6.30
# cp /boot/config-$(uname -r) .config
# make oldconfig
# Eigene Änderungen an Konfiguration hier vornehmen / Patches einspielen
# CONCURRENCY_LEVEL=4 make-kpkg --initrd kernel_image kernel_headers
# dpkg -i ../linux-image-2.6.30*deb
# dpkg -i ../linux-headers-2.6.30*deb

Betrifft auch alle anderen Fontconfig-verwendenden Anwendungen:

# rm /etc/fonts/conf.d/70-no-bitmaps.conf
# ln -s /etc/fonts/conf.d.avail/70-yes-bitmaps.conf /etc/fonts/conf.d/70-yes-bitmaps.conf
# fc-cache -f

Und dann in Firefox bei Monospace „Fixed” auswählen. Ein Hurra an mxf.

Bevor man garkein IPv6 hat und pro Client einen Tunnel aufbaut, kann man auch erstmal partiell IPv6 über einen Tunnel bauen. Da sich am Netz allerdings einige Clients befanden und wir uns nicht sicher waren, ob die alle mit IPv6 klarkommen, wollten wir erstmal nur spezifische Clients ins Netz lassen. Das allerdings nicht über DHCPv6 oder manuelle Konfiguration, sondern richtig, also mit autoconf.

Als Tunnelbroker wählten wir Hurrican Electrics, also tunnelbroker.net. Dort will man sich dann gleich einen /48er-Tunnel klicken, damit das mit dem Routing einfacher läuft (separate IPs für eth0 und tun0).

Nachdem man also den Tunnel so einrichtet, wie einem die tunnelbroker-Website das empfiehlt, installiert man radvd und konfiguriert ihn folgendermaßen:

interface eth0
{
AdvSendAdvert on;
AdvHomeAgentFlag off;
UnicastOnly on;
   prefix 2001:470:foobar::/64
   {
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;

   };
   route ::/0
   {
        AdvRouteLifetime infinity;
   };
};   

Dabei ist die UnicastOnly-Direktive wichtig, die bewirkt, dass radvd von sich aus keine Broadcasts schickt, sondern nur (gezielt) antwortet, wenn ein Client anfragt. Weiterhin wird, da wir nicht periodisch Broadcasts senden, die Route so gesendet, dass sie nicht expired.

Das Firewall-Setup sieht nun folgendermaßen aus:

ip6tables -N ipv6enabled
ip6tables -A INPUT -j ipv6enabled 
ip6tables -A INPUT -s 2001:470:foobar:1b7::1/128 -p ipv6-icmp -m comment --comment "IPv6-tunnel endpoint" 
ip6tables -A INPUT -s fe80::/32 -p ipv6-icmp -j REJECT --reject-with icmp6-port-unreachable 
ip6tables -A FORWARD -s 2001:470:foobar::/64 -m comment --comment "forwarded /48" -j ACCEPT 
ip6tables -A FORWARD -d 2001:470:foobar::/64 -m comment --comment "forwarded /48" -j ACCEPT 
ip6tables -A FORWARD -p ipv6-icmp -j REJECT --reject-with icmp6-port-unreachable 
ip6tables -A ipv6enabled -s fe80::21d:60ff:fe34:dd20/128 -j ACCEPT 
ip6tables -A ipv6enabled -s fe80::204:e2ff:fe08:cc7d/128 -j ACCEPT 
ip6tables -A ipv6enabled -s fe80::204:23ff:fec7:eeac/128 -j ACCEPT 

Wir erlauben also ICMPv6-Traffic nur von den extra freigeschalteten Hosts (die in der Chain ipv6enabled, mit ihrer link local address) und von der Tunnelgegenseite. Weiterhin wird nur das Subnetz, welches wir weiterrouten (das erste /48er in diesem Fall) freigeschaltet.

Zum Pflegen der IPv6-aktivierten Hosts kann man nun folgendes Script verwenden (die MAC-Adressen, welche IPv6 verwenden sollen, stehen in je einer Zeile in /etc/network/ipv6enabled):

		ip6tables -F ipv6enabled
		for mac in $(cat /etc/network/ipv6enabled)
		do
			ip6tables -A ipv6enabled -s fe80$(ipv6calc --in mac --action geneui64 --out ipv6addr $mac)/128 -j ACCEPT
		done
		ip6tables-save > /etc/network/ip6tables

Wer sich über die Meldung „Reply packet too large” (Heimdal) oder „Reply packet too big” wundert: Die Kerberos-Kommunikation passt manchmal nicht mehr in ein UDP-Paket. In dem Fall sollte man also TCP verwenden, was man über einen passenden Eintrag in der /etc/krb5.conf macht:

[realms]
REALM.NET = {
kdc = tcp/kdc.realm.net
}

Mxf hat ein hübsches Script geschrieben, welches man in URxvt einbinden kann und via Keybindings eine vorher definierte Liste an fonts durchgehen kann. Zu finden auf https://s.qu.cx/urxvt-fonts (mirror auf http://code.stapelberg.de/git/configfiles/tree/urxvt-fonts)

Zumindest auf NetBSD 4 ist das mitgelieferte Kerberos wohl zu alt, um AES zu können. Im ssh-Debuglog (/usr/sbin/sshd -dddD) findet man nur folgende Nachricht:

debug1:  Miscellaneous failure (see text)
encryption type 18 not supported

Folgendes hilft auf dem kdc (der ja die Tickets verteilt und daher auch die Encryption Types verwaltet):

# kadmin -l
kadmin> del_enctype host/foo.bar@REALM.NET aes256-cts-hmac-sha1-96

Weiterhin aufpassen: security/openssh aus pkgsrc wird standardmäßig nicht mit kerberos-support gebaut, sodass man PKG_OPTIONS.openssh+=kerberos in /etc/mk.conf hinzufügen muss bevor man das Paket baut.

Wenn man sich IPv6-connectivity beschafft ist grundlegend erstmal alles offen und global im Internet zu erreichen. Je nachdem, wie man seine Dienste konfiguriert hat (SSH, NTP, Apache lauschen gerne mal auf allen verfügbaren Interfaces) könnte das ein Problem werden.

Daher ist es sicher keine schlechte Idee, ip6tables zu benutzen. Ich zeige im folgenden, wie man erstmal alles dicht macht und dann selektiv freigibt.

# ip6tables -A INPUT -p icmpv6 -j ACCEPT -m comment --comment "IPv6 needs ICMPv6 to work"
# ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT -m comment --comment "Allow SSH"
# ip6tables -A INPUT -s 2001:4d88:beef::/48 -j ACCEPT -m comment --comment "Allow connections from a specific network"
# ip6tables -A INPUT -s ::1/128 -d ::1/128 -j ACCEPT -m comment --comment "Allow connections from localhost"
# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "Allow packets for outgoing connections"
# ip6tables -A INPUT -s fe80::/10 -d fe80::/10 -j ACCEPT -m comment --comment "Allow link-local traffic"
# ip6tables -A INPUT -j REJECT -m comment --comment "Reject all other traffic"

Wenn’s fertig ist sieht das ganze nun so aus:

$ ip6tables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  448 47024 ACCEPT     icmpv6    *      *       ::/0                 ::/0                /* IPv6 needs ICMPv6 to work */ 
   70 11155 ACCEPT     all      *      *       2001:4d88:beef::/48  ::/0                /* Allow complete acces from my network */ 
    0     0 ACCEPT     tcp      *      *       ::/0                 ::/0                tcp dpt:22 /* Allow SSH */ 
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                state RELATED,ESTABLISHED /* Allow established connections */ 
   26  2704 REJECT     all      *      *       ::/0                 ::/0                /* Disallow everything else */ reject-with icmp6-port-unreachable 

Damit diese Regeln nun auch bei jedem Start neu geladen werden, kann man sie folgendermaßen speichern:

# ip6tables-save > /etc/network/ip6tables
# echo "ip6tables-restore < /etc/network/ip6tables" >> /etc/rc.local

Gegebenenfalls musst du deine /etc/rc.local nochmal selbst anpassen, da sie mit „exit 0” aufhört (zumindest bei mir).