[Megoldva]Sendmail költöztetése postfix alá - ötletbörze

Linux-haladó

Szevasztok,

Van egy régi-régi örökölt sendmailes levelezés, rajta 200 működő emailcímmel, abból 150 komoly használatban van, munkára. Virtuális szerverre telepítettem egy postfixet (dovecot,clamav,spamassassin stb), erre kellene átköltöztetni a régi levelezést. A virtuális szerver és a rajta lévő levelezés kész van, küld, fogad, jól fut. A felhasználói oldalon DNS -el van beállítva a levelezés, mail.xy.hu, elméletileg pár sor átírásával a gépek átállnának az új levelezőre. De. levelezés jelszavak nem ismertek számomra.

Tippeket kérnék, ki, hogy oldaná meg a feladatot, biztos vagyok benne, hogy több tapasztalatotok van ebben ;) Mire ügyeljek, mit teszteljek, stb.

  • 8185 megtekintés

( pike.killer v | 2014. 03. 05., sze – 09:48 )

Hogyan vannak tarolva a jelszavak?(mysql,ldap,password file)

( mindenesetre | 2014. 03. 05., sze – 12:58 )

Ha minden kötél szakad, akkor a tervem az, hogy létrehozom kézzel az összes mailfiókot a virtuális szerveren, beállítok mindent, letesztelem mindenfélére ami eszembe jut, és ha üzembiztosnak tűnik, akkor meghirdetek egy pénteki napot, amikor átállítom az új levelezőre a hálózatot, és minden levládához egyesével oda kell menni beállítani a jelszavakat.
Azt gondoltam, hogy a művelet bármely részére van import, export, jelszókinyerés vagy whatever, de ezekre akárhogy keresek rá a neten, nem nagyon van ehhez bármi is.. minden ötletnek örülök, vagy ha írtok olyat, hogy milyen hibákat jó elkerülni :D

ha minimum kozepesen jol van megcsinalva a sendmail-es telepites akkor eselytelen kinyerni a plain-text jelszavakat. (bar lattam mar mysl-ben plain-text jelszavakat...)
probald ki azt hogy letrehozol egy uj mailfiokot (unix user-t, barmit. gondolom ennek metodusa ismert.) es annak probalgasd a jelszavat valtoztatni, igy kiderul, hogy mukodik.
jo esellyel az /etc/shadow-ban lesznek a jelszavak tarolva amit at tudsz vinni postfix ala is. nemi egyeztetesre szukseg lesz az uid-nubmer-ek teren, illetve mindenkit unix/pam auth-ra kell rabeszelned.
ha mar dovecot-ot hasznalsz akkor en az auth-ot ill. lda funkciot is rabiznam, postfix is tud dovecot-on keresztul authentikalni (szepen magyarul, vagy mi...) igy legalabb csak egy helyen kell hegeszteni azonositast.

( hokuszpk | 2014. 03. 05., sze – 17:05 )

a trustauthmech azt mondja meg, hogy a kliens mivel authentikalhat.

jo lenne tudni a szerveren futo disztribrol tobbet, peldanak okaert rh eseten alapbol a /etc/sysconfig/saslauthd -ben MECH=pam van, ennek megfeleloen az /etc/pam.d/smtp fileban levo beallitas a nyero ( =system-auth )

ha van rg szintu hozzaferesed a regi szerverhez, akkor van ra egy fogadasom,hogy a jelszavak egy reszet az imap/pop figyelesevel le lehet sniffelni.

ha arra jutsz, hogy a password/shadowban vannak a jelszavak, akkor elso korben nekifuthatsz johnnal, 5-6 karakterig egy négymagos gepen eleg hamar eljut, utana mar gpu gyorsitott hashcat. nekem ezzekkel a modszerekkel kb. 1200 jelszobol egy honap alatt kb. harminc maradt, amit nem tudtam.

kösz, ezt holnap megnézem! Természetesen teljes szintű a hozzáférésem, de minden ősi régi ezen a szerveren. Régi hagyományok alapján szokásjogból öröklődő népi rigmusokon átívelő dohos penészszagú ősmaradvány ez, a toldás-foldás jegyében megfűszerezve a mindenki által jólismert "ócsóból jöjjön ki" hozzáállással. Az én tudásom/gyakorlatom meg ... khm. nem minősítem. gyenge kezdő bemelegítése újjgyakorlat előtt.
volt másnak esete ilyen levelező költöztetéssel? A neméncsináltamból átköltözni a kényelmes - otthonosba? gondolom sima "enter,enter,tovább,oké" gomb és kész másnak az ilyen. de nem? :)

Asszem imap/pop figyelésével megpróbálom összekaparni a jelszavakat, de ettől függetlenül jobb lenne a jövőre nézve ha új követelményeknek megfelelő jelszavakat állítanék be az összes fióknak. Kikerülve a híreshírhedett 12345 öt, a babucika, jelszó, password és társait.
A fiam egyébként viccből egy ennedrangú helyen "nyolckarakter" jelszót használ, mert amit először beírt ott, azt nem fogadta el a rendszer, kiírva, hogy a jelszónak nyolc karakternek kell lennie. Erre megvonta a vállát, hogy akkor legyen. :)
az imap/pop figyelésre van valami bevett eljárása valakinek?

elso lepesben :
tcpdump -X -s 16384 -i eth0 -l -e port pop3 >>lassuk.txt

ezutan ha a lassuk.txt -ben a 'PASS' sringre rakeresel, akkor valahol ott lesz a jelszo, elotte valamennyivel meg az 'USER' string mogott a felhasznalonev.

ha nem akarod kezzel vegigbongeszni, akkor irsz ra scriptet, ami otomatan kiszedi a sniffelt txt filebol a jelszavakat.

( hokuszpk | 2014. 03. 05., sze – 22:29 )

kell szereznem egy r9 290x -et.
kivancsi vagyok, mi igaz a ~10x ( pc1 = 7970 pc5=r9 290x ) sebessegkulonbsegbol...

http://hashcat.net/oclhashcat/

szerk: visszavonva, az utolso oszlop 8x r9 290x -rol szol :D)

Az új szerver tesztelésére van valami ajánlásotok, vagy csak ellenőrizzem a futásképességeit, és hogy a feladatait ellátja-é.

Köszönöm az előző hozzászólásokat is, nekem hasznos volt.

A virtualizáló szervert ma raktam össze, szoftveres raid1, 3 Gb raid1 swappal, 497 Gb ext4. (két ötszázas ugyi), leend majd benne 8 Gb ram, ami most még csak 7, de szegény ember vízzel főz. Virtual box dohog rajta, meg ubuntu 12 lts szerver. minden csicsával együtt most 190 mega ramot eszik és még nagyon unatkozik. :)

Valamikor nagyon régen úgy migráltunk, hogy a shadow-ból átmásoltuk a hash-t az új helyére. Ha a kódolási módszer a cél rendszeren ugyan az ez is működhet.

Virtualizációról az én ízlésem szerinti sorrendben.
- LXC, mert sokkal kisebb terhelést ró a rendszerre.
- KVM + virt-manager, mert nagyon sok lehetőséget nyújt és távolról managelhető GUI-n keresztül.
- Vbox nem szeretem, 3 féltől szállított....

Az LXC-t nem ismerem, nem használtam (még). Jó lesz ezt áttanulmányozni, majd próbálgatok LXC-zni, meg elmélyedni benne.
A KVM inkább tetszetősebbnek tűnik, de ezt sem használtam (még) :)
A VBOX on van tapasztalatom, és csak emiatt készül így. Jó lenne, ha lenne összehasonlítás e három virtualizációs megoldás között... tehát ha a mostani postfix meg lenne csinálva mind a háromféleképpen, akkor vajh melyik enné meg előbb az erőforrásokat (egyikse), vagy melyik lenne stabilabb (no ezt nem tudom). Ha lesz időm (majd szakítok rá), akkor csinálok majd viccből egy ilyen hármaspróbát, egyrészt hogy okuljak, bénázzak teszt környezet alatt, másrészt meg jó móka.

Kösz az ötleteket!

( PtY | 2014. 03. 07., p – 10:02 )

Hát, ha DNS-sel akarsz átállni, akkor a TTL-re nagyon vigyázz, mert könnyen öngól lesz a vége...
--
PtY - www.onlinedemo.hu

igen, DNS ben megadom hogy most már attól kezdve másik IP cím szolgáltatja a mailpontakármit, tessenek szívesek lenni ott keresni.
Erre majd jó lesz figyelni. A tűzfalon az új szerver lesz a kimenő-bejövő levelezésre, a régin még futni fog a sendmail, így az ott "ragadt" leveleket le lehet kérdezni (az adott munkaállomásnál megadni kézzel a sendméles IP címet, aztán visszaállítani mail.xy) az új leveleket meg már az új fogadja be. Itt azzal lehet gond, hogy a régi szerverhez fordulgatnak még a gépek, azt hihetvén, hogy nincs új levél.
Átállás előtt a ttl-t be kéne lőni kicsi időre, aztán meg majd vissza ha minden oké.
valami iylesmi?

"Átállás előtt a ttl-t be kéne lőni kicsi időre, aztán meg majd vissza ha minden oké.
valami iylesmi?"

Hát előtte, de mennyivel?
Ha a TTL jelenleg 86400, akkor több, mint egy nappal előtte ajánlatos levenni 300-ra, az átállás előtt 10 perccel meg 60-ra, vagy még kisebbre (amekkora kiesést elviselsz). A webes kliens-t az átállás alatt le kell állítani, és a felhasználói kliensekből sem árt kilépni addig.
Ha az átállás sikeres, akkor vissza lehet tenni a TTL-t 86400-ra. Szóval amekkora a jelenlegi TTL, annál sokkal hamarabb kezdd el csökkenteni a mértékét.
--
PtY - www.onlinedemo.hu

" tűzfalon az új szerver lesz a kimenő-bejövő levelezésre, a régin még futni fog a sendmail, így az ott "ragadt" leveleket le lehet kérdezni (az adott munkaállomásnál megadni kézzel a sendméles IP címet, aztán visszaállítani mail.xy) az új leveleket meg már az új fogadja be. Itt azzal lehet gond, hogy a régi szerverhez fordulgatnak még a gépek, azt hihetvén, hogy nincs új levél."

egyreszt ha sikerul kibanyasznod a jelszvakat, akkor te is szinkronizalhatod az uj szerverre imapsynccel, de sokkal jobb, ha a regi szerveren az iptables bevetesevel szepen atnatolod az smtp/smtps/imap/imaps/pop3/pop3s forgalmat az uj szerverre.

értem, volt szó arról hogy a régi szerveren átNATolnánk a forgalmat, ez sima megoldásnak tűnne, de a későbbiek folyamán mindenképpen fel kell számolni (szervert és a kereszt-kasul jövésmenést). De ezek a felvetések mindig megfontolóra teszik, hogy épp mire is készülök, és óvatossá tesznek eléggé :)

Jelenleg amúgy most ott állok, hogy a fizikai szerver szépen megy, fut rajta a két virtuális gép (virtualbox), az egyik belőle a postfixes új levelezés. Nem rég importáltam be a kicsikéket. A levelezéses szerverre 1024 MB memóriát dedikáltam, ez érzés szerint megfelelő lehet (200 email cím, ebből sűrű napi használat 50-100 db, max levélméret 50 MB, clamav, spamassassin) ?

Nemsokára elutazom hosszúhétvégézni, és amúgy is döglődik itt egy központi program, tehát ezzel nem tudok a következő 3 napban folgalkozni, mert programozókkal vesződni kell. - ők meg nyilván velem :D

Ez most kulso vagy belso levelezest szolgal ki?
1. Ha ugy gondolod minden ok. Akkor lehet en az IP-t lonem at nem a dns-sel jatszanak, ha a masik amugy is leallitasra kerul.
2. Regi szerver nem kerul leallitasra, akkor onnan minden levelet tovabbitanek az uj szervernek es nem kell a mailbox-okat szinkronizalni.

Visszaterve a jelszo problemana en biztos felvennem magamat a regi szerveren, ha meg nem lenne ott felhasznalom es a jelszot atvinnem az ujba tesztnek. Ha mukodik, akkor orom es bologsag.

Külső levelezést szolgál ki, és fontos levelek jönnek-mennek rajta. Sajnos.
Azt hiszem az új levelezésre való átálláskor jó alkalom lesz a felesleges címek törlésére, és nem találom olyan nagy problémának végignézni egyesével a fiókokat. Fos meló, de valakinek meg kell csinálnyi már.

Namármost ttl idők. Csináltam a levelezés mellé egy Squid szervert. Ez jó előszobája a levelezés átállításnak, ugyanis ezt a funkciót is elköltöztetem a régi foshadásról. Miután leteszteltem az új szerert, és minden beállítás jónak tűnt, most ma reggel 7:15 kor átírtam a DNS-ben hogy a proxy.xy az már nem az az IP cím, hanem emez. Az új gép squid logjában azonnal elkezdett sorjázni a sok gép, és minden fennakadás nélkül ki lett szolgálva a net. Senki nem telefonált, hogy akadna bármi is, pedig ahogy néztem forgalom az megy (20 perc alatt 1 GB ot forgalmazott az új squid).