[fox-users] <- via users: server probleme

Fri Apr 23 17:14:41 CEST 2004

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi

[english version next week, i'm exhausted... sorry]

ich weiss, in letzter zeit haeufen sich die unangenehmen vorfaelle. das 
tut uns sehr leid, und wir tun unser moeglichstes. dazu kommt noch, dass 
TD (technischer direktor) jogi in der toskana an einem grossen nylonsack 
von huegeln schwebt (er nennt es urlaub), und die azubine (auszubildende) 
renate sich in der berufsschule im finsteren eibiswald weiterbildet. der 
arme DVD (dodl vom dienst) lu ist also ganz alleine, und wie immer in so 
einer situation (erfahrung, kein fatalismus!) passieren gerade dann die 
schlimmsten sachen.

da war die leidige, und bis heute leider nicht aufgeklaerte pop misere. in 
meinem stress hab ich ganz vergessen, zu verkuenden, dass das service 
wieder funktioniert. alle, die pop lieber haben als imap, koennen also 
wieder zurueck wechseln.

da ich pop nicht verwende war mir nicht bewusst, dass der umstieg auf imap 
einige probleme mit sich bringt. ein paar punkte dazu:

# imap speichert die mails in einer verzeichnisstruktur, ganz wie normale 
files im filesystem. es koennen ordner und unterordner etc. angelegt 
werden, um die mails zu sortieren. wichtig: ordner koennen nur unterhalb 
der inbox angelegt werden.

# fuer dialin (modem) ist imap anscheinend nicht das ideale, weil nicht 
alle mails auf einen schwung geholt werden, und auch beim wechseln 
zwischen ordnern immer eine serververbindung hergestellt wird, was ueber 
eine langsame leitung eher zaeh ist. (oder weiss vielleicht jemand, ob/wie 
das zu umgehen ist?)

# bei leuten, die in den wirren der letzten tage mehrmals zwischen pop und 
imap gewechselt haben, sind unter umstaenden mails scheinbar verschwunden. 
scheinbar, weil sie zwar vom server geloescht wurden (weil die meisten 
[alle?] clients, wenn nicht bewusst anders konfiguriert, ge-pop-te mails 
vom server loeschen), aber irgendwo auf eurer festplatte liegen. das ist 
mir selbst passiert beim versuch, von mehreren userInnen geschilderte 
probleme zu reproduzieren. wem es so ergangen ist und imap weiter 
verwenden will, bitte melden. es gibt eine moeglichkeit, die mails 
wieder auf den server zu transferieren, natuerlich nur sofern ihr sie 
nicht von eurer festplatte geloescht habt.

und nun noch zum wirklich ernsten teil:

unser zentraler server wurde gestern frueh gecrackt. und zwar relativ 
professionell, sodass es nur wenige konkrete spuren gibt. wir wissen aber, 
welcher crack verwendet wurde: eine lokale kernel vulnerability, die fast 
saemtliche aktuellen linux kernels betrifft. wie der name impliziert, kann 
so ein angriff nur von einam lokalen account aus gefuehrt werden. da uns 
keine exploits bekannt sind, die ueber die auf mur.at angebotenen services 
das erlangen von lokalen rechten ermoeglichen, gehen wir davon aus, dass 
ueber ein ausgespaehtes oder weitergegebenes user passwort eingeloggt 
wurde. ab da ist es fuer jemanden, der weiss, was er tut, mehr oder 
weniger ein spaziergang. (die politisch korrekte bisexualitaet vermeide 
ich hier bewusst...)

das erklaert auch die ueber die letzten zwei tage verteilten teil- und 
komplett-ausfaelle des servers. war noetig zur reparatur, bzw reparatur 
der reparatur ("meine komplikation hat eine komplikation bekommen...") 
etc. tut leid, nervt, ich weiss.

die konsequenzen:
alle trojaner, die ich finden konnte, sind getilgt, und auf dem server 
laeuft jetzt ein brandneuer kernel, der immun gegen diese attacke ist.
anhand der logins der letzten wochen (wann und von wo) ergeben sich ein 
paar kandidaten, deren account zum crack verwendet worden sein konnte. (es 
duerfte recht schwierig sein, sich zb. gleichzeitig von moskau und von 
graz einzuloggen...) die betreffenden passwoerter sind geaendert, und die 
inhaberInnen verstaendigt.

wir werden weiter nach spuren und moeglichen verbliebenen backdoors 
suchen, das system gezielt beobachten und sukzessive weitere 
sicherheitsmechanismen einbaun.

und jetzt kommt ihr an die reihe ;]
um das system moeglichst sicher zu machen und zu halten, braucht es eure 
mithilfe:

# keine weitergabe von zugangsdaten an dritte!
wir werden in zukunft rigoros gegen account sharing vorgehen. ein account 
ist an eine person gebunden, diese person ist verantwortlich fuer den 
account, auch fuer alles, was dritte, an die zugangsdaten weitergegeben 
wurden, damit anstellen. im klartext: verlust der mitgliedschaft.
das betrifft auch das unwesen der "inoffiziellen webmaster". leute mit 
mur.at account, die ihre homepage nicht alleine machen wollen/koennen, 
oder hilfe mit der datenbank brauchen, koennen ohne aufwand einen 
offiziellen webmaster account mit dementsprechenden rechten bekommen. auch 
ein webmaster ist ein dritter, egal wie gross das vertrauen in ihn/sie 
ist.

# sichere protokolle verwenden!
seit langem schon ist es nicht mehr noetig, passwoerter im klartext zu 
uebermitteln.
ftps statt ftp verwenden: jeder ftp client, der was auf sich haelt, kann 
ssl/tls. schaut mal in den settings nach. und hiermit sei gleich der 
unwiderrufliche tod von ftp auf mur.at angekuendigt. in absehbarer zukunft 
wird es nur noch ftps geben.
scp verwenden: unter linux ohnehin laengst standard, unter macosx sogar 
mit einem klickbaren bunti interface ausgestattet (obwohl noch etwas 
buggy), und dos clients gibt es auch. wir werden un daran machen, fuer die 
verschiedenen plattformen clients zu testen und TODOs online zur 
verfuegung zu stellen.
sowohl ueber pop als auch ueber imap kann mail verschluesselt abgeholt 
werden. wie beim ftp, im client nach der entsprechenden einstellung 
suchen, aktivieren, das mur.at zertifikat akzeptieren und schon kann nur 
noch die NSA mitlesen. das ist aber eine andere geschichte... auch 
pop/imap unverschluesselt wird ueber kurz oder lang eingestellt werden.

# passwoerter nicht speichern!
weder in selbst erzeugten klartext files, weder auf dem server noch auf 
der eigenen maschine, noch in programmen (save password? -> NO). die 
sicherheit und der schutz der eigenen daten sollte es wert sein, sich ein 
paar passwoerter zu merken und die, wenn verlangt, einzutippseln. es gibt 
offenbar windoze exploits, die gespeicherte passwoerter ausspionieren.
auch im internet cafe sollte userIn sich vergewissern, dass der browser 
keine formulardaten und/oder passwoerter speichert, was unseligerweise die 
voreinstellung bei allen gaengigen browsern zu sein scheint.

# passwoerter nicht unverschluesselt mailen!
immer wieder kommt es vor, dass userlein uns mailt: ich log mich ein als 
hinz mit passwort kunz, aber es geht nicht. und schon haben dutzende, u.U. 
hunderte, theoretisch die moeglichkeit, es selber zu probieren. chello 
userInnen zb. teilen sich mit etlichen anderen ein subnetz, de facto ein 
(zumindest vor einiger zeit noch sogar ungeswitchtes) LAN, und es ist 
nicht schwer, von einer maschine aus alles, was alle anderen schicken und 
empfangen mitzulesen. ich hatte selber gelegenheit, das (rein aus jux und 
interesse, versteht sich ;) zu betreiben, als ich kunde dieser windigen 
firma war.

das war's vorerst einmal.
ich hab alle services stichprobenmaessig getestet und fuer funktional 
befunden. sollte doch was nicht klappen, bitte melden.
kontakte: http://support.mur.at/
gute nacht.

lg
lu

- -- 

wuensche, wohl administriert worden zu sein!

  NOC at mur.at
  NetworkOperationCenter

>> http://lu.mur.at/lu.pub.key.html <<
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAiTLkea0RHHXBzw0RAjyhAJ4rNEjgfBmHyTyo3gijKJ3TwNMqDwCgnUsn
h2O7f9tb7VEYukPWf+tiQ3M=
=p5Er
-----END PGP SIGNATURE-----
_______________________________________________
users mailing list
users at mur.at
http://mur.at/mailman/listinfo/users