ich hatte gestern einen server von einem rootkit zu befreien… zumindest nach bestem wissen und gewissen, damit die kiste wieder laeuft und keinen unfug mehr macht. an einer neuinstallation geht da sowieso nichts dran vorbei… sicher ist sicher.
auf jeden fall kann man da auch mal schmunzeln, wenn einem sowas unterkommt:
# lsattr /bin/ls
suS-iadAc--------- /bin/ls
# chattr -suSiadAc /bin/ls
was nur die susi mit dem adac hat…
wens interessiert… das sind flags im ext2 dateisystem. wikipedia schreibt dazu:
Das Flags-Feld enthält einige ext2-spezifische Flags, die nicht beispielsweise durch chmod beeinflusst werden können. Diese Flags können mit dem Programm lsattr gelistet werden und mit chattr geändert werden. Diese Flags erlauben einer Datei besonderes Verhalten, welches über die POSIX-Dateiflags nicht darstellbar ist: Es gibt Flags für sicheres Löschen, Unlöschbarkeit, Kompression, synchrone Updates, Schreibschutz, indizierte Verzeichnisse, Journaling und einiges mehr. Nicht alle Flags werden jedoch vom ext2-Treiber im Kernel umgesetzt.
bei selflinux.org gibts leicht verstaendliche erklaerungen auf deutsch dazu, die ich einfach mal hier reinkopiert hab:
s (Secure Delete)
Wenn das System diese Datei löscht, werden alle Datenblöcke auf dem Datenträger zufällig überschrieben.
u (Undelete)
Wenn eine Anwendung das Löschen der Datei fordert, soll das System die Datenblöcke so “konservieren”, dass das Löschen der Datei auch wieder rückgängig gemacht werden kann. Diese Funktion ist derzeit noch nicht impementiert.
S (Sync)
Wenn eine Anwendung gerade den Schreibprozess durchführt, soll das System alle Änderungen sofort und ungepuffert auf dem physischen Datenträger abspeichern.
i (Immutable)
Das System verbietet jegliche Änderungen an der Datei. Im Falle eines Verzeichnisses können Dateien, die in diesem Verzeichnis bereits existieren, verändert werden. Weder das Löschen noch das Anlegen von Dateien ist möglich.
a (Append Only)
Das System erlaubt das Öffnen dieser Datei nur zum Zwecke der Erweiterung und verbietet explizit allen Prozessen das Überschreiben bzw. Löschen bereits gespeicherter Daten (sinnvoll bei log-Dateien). Ebenfalls untersagt ist das Löschen, Umbenennen, Verschieben und “hartes” Linken der Datei. Wird das Flag auf einem Verzeichnis angewendet, dürfen darin keine Dateien angelegt oder gelöscht werden.
d (No Dump)
Das dump Programm soll diese Datei beim Backup ignorieren.
A (Atime)
Das System soll die “atime” (access time) dieser Datei nicht aktualisieren.
c (Compress)
Das System soll diese Datei “transparent” komprimieren. Beim Schreiben in die Datei wird deren Inhalt komprimiert und erst danach auf dem physischen Datenträger abgelegt, beim Lesen der Datei werden jedoch stets dekomprimierte Daten zurückgegeben. Diese Funktion ist derzeit noch nicht implementiert.
das stand schon lange auf meiner liste der “sachen, die ich unbedingt nachschlagen muss”: die grub konfiguration bei einem software raid1 unter linux. und jetzt bin ich rein zufaellig beim hostbogger drueber gestolpert: “Insbesondere ist es wichtig, sicherzustellen, dass beim Totalausfall eines physikalischen Laufwerks von der nächsten (meist einzigen) anderen, die in diesem Falle dann zur ersten wird, gebootet werden kann.”
/boot/grub/device.map editieren:
(hd0) /dev/sda
(hd0) /dev/sdb
(hd0) /dev/sd
in der Grub-Shell
root (hd0,1) # Natürlich die /boot-Partition angeben
setup (hd0)
setup (hd1)
setup (hd)
Das Ganze hat den Hintergrund, dass sich beim Booten mit fehlendem Laufwerk die Nummerierung ändert, aber immer ein hd0 vorhanden ist.
es ist schon lange her, dass ich mich ueberhaupt mal mit twitter beschaeftigt habe. zum spass heute mal auf dem blackberry eingerichtet… und (mal mit einem anderen client) einen gewohnten anblick genossen:
es war mal wieder so weit und ich musste einen vmware server installieren. dank meines eigenen howto’s sollte das eigentlich kein problem sein… dachte ich. die installation hat soweit auch geklappt (mit den beschriebenen tricks). bloss der erste connect mit dem browser nach der oblogatorischen fehlermeldung wegen des zertifikats ins leere. in der datei /var/log/vmware/hostd.log konnte ich massig dann eintraege wie diese finden:
[2010-08-18 21:43:51.807 'Proxysvc' 1076664656 warning] SSL Handshake on client connection failed: SSL Exception:
das war sowohl im firefox, als auch im IE so. langes googlen brachte viele voodoo tricks ans tageslicht, aber darunter auch eine ernsthafter, der dann geholfen hat:
Turns out it is Firefox 3.6, in the update the default setting for SSL 2 is off, easy fix, go to about:config and switch security.enable_ssl2 to true.
nach einem reload hat dann der firefox endlich die loginmaske angezeigt. lustigerweise hats dann auch mit dem internet explorer funktioniert. verstehen muss ich das jetzt nicht…
gefreut hat mich, dass der firefox nun ein “bischen kompatibler” zu sein scheint. den mist, den er beim letzten mal angezeigt hat, macht er jetzt nicht mehr. dafuer tauchen andere kuriositaeten auf:
meine physikalische maschine hat 4GB ram:
und der vmware server sagt mir, dass ich maximal 8GB vergeben kann, weil die kiste sonst zu swappen anfaengt:
hmm… ich wills mal lieber nicht ausprobieren. auf jeden fall scheint erstmal alles zu laufen. die webgui ist gewohnt scheisse und haengt ab uns zu, die remote console funktioniert auch nicht immer beim ersten mal, und manchmal muss man sich einfach ausloggen und wieder einloggen, damit die kleinen merkwuerdigkeiten wenigstens termporaer verschwinden.
und wenn die gui schon merkwuerdig ist, muss sich mein server anscheinend auch noch merkwuerdig verhalten… aus heiterem himmel zeigt mir die ssh session das an:
ich wars nicht. die kiste steht im keller und ich bin drei stockwerke weiter oben. ich gehe mal davon aus, dass niemand in meinem keller war und die kiste ausgeschaltet hat… suspicious…
alles gruen… auch die utf8 unterstuetzung. aber sehr vertrauenserweckend sieht das nicht aus:
seit ein paar tagen laeuft bei mir der blackberry enterprise server express in der version 5 (besx5). mal abgesehen davon, dass die kiste extrem ressourcenhungrig ist, nur noch ein komisches webinterface statt einer vernuenftigen clientsoftware bietet und noch ein paar kleinigkeiten, scheint es problemlos zu laufen. neben ein paar neuerungen (uhh.. endlich html emails auf dem blackberry) gibts auch gute nachrichten fuer geplagte hobby-blackberry-bastler-admins: es reicht jetzt auch der (kostenguenstigere) BIS tarif vom mobilfunkanbieter, um einen blackberry an den besx dranzuhaengen. bei einigen providern bekommt man als privatperson ja nicht mal die bes option auf die simkarte gebucht. verschmerzbares manko: die aktivierung funktioniert aufgrund der fehlenden servicebuecher nicht drahtlos, sondern nur ueber den webdesktop manager. und fuer diesen muss man natuerlich den internet explorer benutzen und ein activeX plugin installieren, welches die kommunikation mit dem per usb angeschlossenem blackberry ermoeglicht.
hab ich alles gemacht, getestet… und es funktioniert!
die letzten tage und vor allem gestern war dieses blog schlecht bis garnicht mehr erreichbar. das lag daran, dass ich aenderungen an der dns zone gemacht hatte und mich bei der seriennummer im zonefile vertippt habe. diese vertraegt naemlich dezimal nur 10 stellen und ich hatte versehentlich 11 gehabt. der bind startet wie gewohnt, aber laedt das zonefile nicht. um logfile stand dann:
Aug 9 18:21:10 host named[7856]: dns_rdata_fromtext: /etc/bind/db.sd.vc:5: near '20100080401': out of range
…eigentlich eindeutig, aber dazu haette ich mal logfile lesen muessen. ich wurde erst stutzig, als nix mehr ging 
nachdem ich mir heute ein serielles kabel ausleihen konnte, hab ich mich mal an die installation der firebox gewagt. aber erst musste ein wenig an der hardware geschraubt werden. die compactflash karte muss raus und der dummy wechselrahmen samt seiner merkwuerdigen backplane, damit spaeter die 2,5 zoll platte installiert werden kann. ausgebaut sieht das so aus:
die 2,5er platte habe ich erstmal an einen beliebigen anderen rechner angeschlossen und mit der pfsense live cd gebootet… irgendwo (ich habs mir leider nicht gemerkt) konnte man dann die installation auf festplatte auswaehlen. husch ausgewaehlt und beim zu installierenden kernel den “embedded without vga and keyboard” (oder so aehnlich) ausgewaehlt. die standardinstallation laeuft ohne grossartige weitere fragen durch.
nun muss die platte in die firebox verbaut werden. provisorisch hab ich erstmal ein kleines brettchen in den schacht gelegt, damit die nicht einfach so auf der elektronik rumliegt. sieht etwas komisch aus… ist es auch… aber das mach ich noch anders
nun einen rechner mit mit dem seriellen kabel dranstoepseln, hyperterminal starten und eine neue verbindung (mit den einstellungen: BPS: 9600 / Data bits: 8 /
Parity: None / Stop : 1 / Flow control: Hardware) anlegen.
nach dem anschalten sollten das im hyperterminal irgendwann so aussehen:
da die festplatte nun in einem anderen computer laeuft, hat sie eine andere bezeichnung, weshalb das freebsd die partition nicht mounten kann. an diesem prompt gibt man dann folgendes ein:
ufs:ad2s1a
…und drueckt enter. nun startet das pfsense ganz normal. damit man per webinterface darauf zugreifen kann, muss man nun die minimalste konfiguration per konsole machen. also die netzwerkkarten den pfsense interfaces zuordnen und die gewuenschte lan ipadresse einstellen.
damit der naechste reboot auch noch funktioniert, muss die datei “/etc/fstab” angepasst werden. mit der console und vi ist das quasi nicht so einfach, weshalb man das besser bzw. komfortabler im webinterface macht. die schritte dazu im menue: diagnostics -> edit file -> load /etc/fstab. darin die partitionen ad2s1a und ad2s1b eintragen, speichern und gut.
ich war selbst ueberrascht, wie vergleichsweise einfach das ging. naja… darf ja auch mal was klappen
wen es interessiert, hier noch die ausgabe von dmseg dieser kiste: dmesg.txt
demnaechst will ich noch das lcd display dazu bewegen, wieder irgendwas anzuzeigen… momentan dient es nur der beleuchtung des kellers. fuer heute wars das aber erstmal…
heut wars dann endlich so weit. fuso hat mir die tage netterweise meinen neuen blackberry server express 5.0 installiert. (manche sachen will ich einfach nicht machen und er hats da halt drauf). ich war schon etwas ueberrascht von dem ressourcenhunger der neuen version. ich weiss nicht, warum so eine software ohne auch nur einen benutzer ueber ein gigabyte an speicher verbraten muss. aber so ist das halt, wenn dank immer leistungsfaehigerer hardware kein entwickler mehr darauf achtet. bei mir ists halt nur eine vmware, die sich trotz zwei GB ram auf dem dem hoffnungslos ueberlasteten traegersystem ziemlich quaelt. aber egal… es reicht fuer den betrieb aus.
tja… und der alte blackberry professional server… hat nun ausgedient. ueber zwei jahre hat er klaglos seinen dienst verrichtet. und das trotz gelegentlicher bluescreens wegen grottenschlechter IO performance des unzureichend dimensionierten bzw. vollgestopften traegersystems. beim runterfahren hab ich wenigstens noch ein paar warme worte fuer ihn gefunden:
und so sieht das im leerlauf aus, wenn der neue besx5 NICHTS macht… leerlauf also:
