So schnell kann es gehen.
29.08.11 02:59 Mozilla meldet gefundenes Wildcard von google.com
Fraudulent *.google.com Certificate
30.08.2011 18:55 Heise News meldet:
Falsches Google-Zertifikat ist Folge eines Hacks
01.09.2011 18:05 Neues ca-certificates Pakete kommen auf unserem Mirror an.
* New upstream release v3.6.21 (FIREFOX_3_6_21_BUILD1)
- Distrust and disable DigiNotar Root CA due to fraudulent certificate
issuance (LP: #837557)
Imfolge dessen gab der Kurs der VASCO Data Security International um gut 33% nach.

08.09.2011
* New upstream release v3.6.22 (FIREFOX_3_6_22_BUILD2)
- Distrust and disable all DigiNotar certs including the Staat der
Nederlanden Certificates (LP: #838322)
Veröffentlicht am: 03.09.2011 von: CHR | publiziert in: Aktuell
Heute bedien wir uns an einem SSH AGENT eines andren Users.
So sieht die ausgabe bei einem User aus.
user@pc:~$ env | grep SSH
SSH_AGENT_PID=1719
SSH_AUTH_SOCK=/tmp/keyring-AyZCBd/ssh
Stellen wir uns vor, wir haben uns per SSH zugang zum dem Rechner des Users gemacht, und wissen das er gerade ein gnome-panel
hat. Es kann natürlich auch eine andere pid des Users benützt werden.
root@pc:~# cat /proc/$(pidof gnome-panel)/environ | xargs -0n1 echo | grep SSH
SSH_AGENT_PID=1719
SSH_AUTH_SOCK=/tmp/keyring-AyZCBd/ssh
root@pc:~# SSH_AUTH_SOCK=/tmp/keyring-AyZCBd/ssh ssh user@chr.istoph.de
Nun kann eine Verbindung mit dem agent des Users aufgebaut werden.
Veröffentlicht am: 01.09.2011 von: CHR | publiziert in: Linux, Security
Auf einem ext2/ext3/ext4 basierende Dateisystem kann man root die Schreibrechte für einzelne Dateien entziehen.
Nötig war das für meinen Router der am externen Netz eine per DHCP zugewiesene IP bekommt und damit immer die /etc/resolv.conf
überschreiben hat. Da ich aber auf dem Router einen bind9 laufen lasse, sollten die Lokalen DNS anfragen an die 127.0.0.1 weitergeleitet werden.
chattr +i /etc/resolv.conf
Um das ganze wieder rückgängig zu machen verwendet man die Option -i
.
Quelle: wiki.ubuntuusers.de
Veröffentlicht am: 22.08.2011 von: CHR | Tags: dns | publiziert in: Linux
Beim starten des md Raid waren 2 Platten beim Starten nicht hochgekommen.
# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: cannot open device /dev/sdb2: Device or resource busy
mdadm: /dev/sdb2 has no superblock - assembly aborted
Sie wurden bereits benutzt. Allerdings nicht von eine Userspace Programm / Mount wie fuser „nicht anzeigt“.
# fuser -v /dev/sdb2
An dieser Stelle haben wir vermutet das es sich um ein Fake Raid handelt. Also mal einen Blick in die device mapper blockdevices werfen…
# dmsetup table
isw_ddjcbgeaib_Volume12: 0 1875395970 linear 252:0 78124095
isw_ddjcbgeaib_Volume11: 0 78124032 linear 252:0 63
isw_ddjcbgeaib_Volume1: 0 3907039744 striped 2 256 8:16 0 8:48 0
# ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 2011-08-03 23:32 /dev/sdb
In der Tat /dev/sdb wird von device mapper verwendet.
Um das Fake Raid aufzulösen haben wir die brachial Methode genommen. Hier wird mit dem Devicemapper alle Einstellungen Deaktiviert. Somit sind die platten wieder freigegeben.
# dmsetup remove_all
# dmsetup table
No devices found
Anschießend konnte das md Software Raid wieder ordentlich gestartet werden
# mdadm --assemble /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd2
mdadm: /dev/md0 has been started with 4 drives.
Im Endeffekt hat auf die Platten ein „Facke Raid“ mittels dmraid zugegriffen. Was auch erklärt warum die „Partitionen für den Kernel verschwunden“ waren.
apt-get autoremove dmraid
Veröffentlicht am: 03.08.2011 von: CHR | Tags: mdadm | publiziert in: Linux
Partitionen für den Kernel Verschwunden
Sowohl mit partx als auch mit fdisk -l und anderen Tools konnte man die Partitionen der Platte sehen.
# partx -l /dev/sdb
# 1: 63- 78124094 ( 78124032 sectors, 39999 MB)
# 2: 78124095-1953520064 (1875395970 sectors, 960202 MB)
# 3: 0- -1 ( 0 sectors, 0 MB)
# 4: 0- -1 ( 0 sectors, 0 MB)
Leider Tauchten sie aber nicht im /sys auf.
# tree /sys/ | grep sdb
│ ├── sdb -> ../devices/pci0000:00/0000:00:1f.2/host2/target2:0:1/2:0:1:0/block/sdb
│ │ ├── sdb -> ../../devices/pci0000:00/0000:00:1f.2/host2/target2:0:1/2:0:1:0/block/sdb
│ │ ├── 8:16 -> ../../devices/pci0000:00/0000:00:1f.2/host2/target2:0:1/2:0:1:0/block/sdb
│ │ │ │ │ │ │ └── sdb
│ │ │ │ ├── sdb -> ../../../../pci0000:00/0000:00:1f.2/host2/target2:0:1/2:0:1:0/block/sdb
Nach dem wir partprobe ausgeführt haben waren die Platten wieder da.
#partprobe
Veröffentlicht am: 03.08.2011 von: CHR | publiziert in: AStA, Ubuntu