2012-02-02 17:20 keltezéssel, Mihaly Zachar írta:
Ezt a thread-et miert nem zartad le megfeleloen ?
Ha a lezárás alatt azt érted, hogy végül is hogy' oldódott meg a az
egész, akkor igazából csak tüneti kezelést tudtam végezni. Leírhatom a
lépéseket, de az nem ad választ a lentebbi
2011.12.21. 19:43 keltezéssel, Laborczi Pál írta:
Az érdekes az, hogy ez a jelenség csak egy adott pillanattól kezdődött,
tehát valamelyik frissítéssel kerülhetett bele.
Valakinek nagyon meg kéne ütnie a bokáját.
Rákerestem erre, azt vártam, hogy lesz valami nyilvánvaló találat, de
nem
2011-12-21 20:00 keltezéssel, Magosányi Árpád írta:
On 12/21/2011 07:43 PM, Laborczi Pál wrote:
A levél címzettje: ridethe...@gmail.com. És tartalmazza a felhasználó
plain/text jelszavát.
[]
Az érdekes az, hogy ez a jelenség csak egy adott pillanattól kezdődött,
tehát valamelyik frissítéssel
Laborczi Pál írta:
2011-12-21 20:00 keltezéssel, Magosányi Árpád írta:
On 12/21/2011 07:43 PM, Laborczi Pál wrote:
A levél címzettje: ridethe...@gmail.com. És tartalmazza a felhasználó
plain/text jelszavát.
[]
Az érdekes az, hogy ez a jelenség csak egy adott pillanattól kezdődött,
tehát
On Thu, Dec 22, 2011 at 12:15:04PM +0100, Laborczi Pál wrote:
Én inkább exploitra tippelnék, mint frissítésre.
Szerintem a kettő nem zárja ki egymást.
Mentsd le ami fontos és nem bináris, utána vegyél elő egy XXL-es gyalut.
Mielőtt újratelepítenéd a rendszert, gyúrd ki magad egy kicsit
On 12/22/2011 12:15 PM, Laborczi Pál wrote:
Nem értem ezt a választ. Egy újra telepítéssel mi változna? RPM
csomagból ugyanúgy fölmenne ez a meghekkelt sshd. Nekem szerencsém volt,
mert valójában nem sikerült a jelszóküldés. De aki az internetre
közvetlenebb módon kapcsolódik, és így épít egy
2011-12-22 12:15 keltezéssel, Laborczi Pál írta:
2011-12-21 20:00 keltezéssel, Magosányi Árpád írta:
On 12/21/2011 07:43 PM, Laborczi Pál wrote:
A levél címzettje: ridethe...@gmail.com. És tartalmazza a felhasználó
plain/text jelszavát.
[]
Az érdekes az, hogy ez a jelenség csak egy adott
On Thu, Dec 22, 2011 at 12:15 PM, Laborczi Pál lp...@pse.siemens.hu wrote:
1.) a Centos (RPM?) közösséget, mert lehetséges, hogy nem is sejtik a
veszélyt; mert azonnali beavatkozás szükséges.
Biztos vagy abban, hogy a csomag a hivatalos repobol lett felteve?
Milyen CentOS, milyen
2011-12-22 15:55 keltezéssel, Laszlo Beres írta:
On Thu, Dec 22, 2011 at 12:15 PM, Laborczi Pállp...@pse.siemens.hu wrote:
1.) a Centos (RPM?) közösséget, mert lehetséges, hogy nem is sejtik a
veszélyt; mert azonnali beavatkozás szükséges.
Biztos vagy abban, hogy a csomag a hivatalos
On 12/20/2011 05:03 PM, Laborczi Pál wrote:
Nem inkább helyben kéne ilyet lekérdezni, ahonnan a levelet küldik?
Mondom hogy auditd.
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
2011-12-20 17:46 keltezéssel, Ferenc Wagner írta:
Laborczi Pállp...@pse.siemens.hu writes:
2011-12-20 12:13 keltezéssel, Ferenc Wagner írta:
Első körben azt nézd meg, hogy az SMTP szerveredet (a szomszéd
gépet) rá tudod-e beszélni, hogy futtasson ident lekérdezést
(esetleg csak a szóban
2011-12-21 11:18 keltezéssel, Magosányi Árpád írta:
On 12/20/2011 05:03 PM, Laborczi Pál wrote:
Nem inkább helyben kéne ilyet lekérdezni, ahonnan a levelet küldik?
Mondom hogy auditd.
Végig néztem az auditd.conf-ot, de nem tudtam rájönni, mire gondolsz.
A tcp_listen_port. ill. a
2011-12-21 01:36 keltezéssel, Gabor HALASZ írta:
Rendben, meggyőztél. De ha lehet, egy kicsit bővebben, mert freebsd-ről
van szó. Telepítve nincs ilyen csomag, a leírások meg ilyeneket
tartalmaznak, hogy: An RFC1413 identification server which also supports
random replies. Magyarán nem igazán
On 12/21/2011 2:49 PM, Laborczi Pál wrote:
2011-12-21 01:36 keltezéssel, Gabor HALASZ írta:
Rendben, meggyőztél. De ha lehet, egy kicsit bővebben, mert freebsd-ről
van szó. Telepítve nincs ilyen csomag, a leírások meg ilyeneket
tartalmaznak, hogy: An RFC1413 identification server which also
On 12/21/2011 01:50 PM, Laborczi Pál wrote:
2011-12-21 11:18 keltezéssel, Magosányi Árpád írta:
On 12/20/2011 05:03 PM, Laborczi Pál wrote:
Nem inkább helyben kéne ilyet lekérdezni, ahonnan a levelet küldik?
Mondom hogy auditd.
Végig néztem az auditd.conf-ot, de nem tudtam rájönni, mire
Laborczi Pál lp...@pse.siemens.hu writes:
2011-12-20 17:46 keltezéssel, Ferenc Wagner írta:
Laborczi Pállp...@pse.siemens.hu writes:
2011-12-20 12:13 keltezéssel, Ferenc Wagner írta:
Első körben azt nézd meg, hogy az SMTP szerveredet (a szomszéd
gépet) rá tudod-e beszélni, hogy futtasson
2011-12-21 15:05 keltezéssel, Magosányi Árpád írta:
Azzal kezdeném, hogy az exec,fork és connect syscallok auditálását
állítom be.
/etc/audit/audit.rules
-a exit,always -S fork
-a exit,always -S exec
-a exit,always -S connect
Nézd végig a syscall listát, mert lehet hogy fejből
On 12/21/2011 04:49 PM, Laborczi Pál wrote:
Köszi, vannak már életjelek. Ha csak az -S connect sor él, már akkor
is naplózza a levélküldést. Igaz, egy sima ls parancsra is már egy
hosszú, számomra nem igazán értelmezhető sort ír a naplóba.
Read The Fine Manual
Megtaláltam a bűnöst: az openssh-server az. Ha valaki normál ssh-val lép
be, akkor nem történik semmi különös. De ha sftp klienssel, akár
winscp-vel, akkor minden belépéskor keletkezik egy ilyen, a root nevében
föladott levél, ami csak azért landol nálam, mert a rendszer nem tudja
kézbesíteni.
On 12/21/2011 07:43 PM, Laborczi Pál wrote:
A levél címzettje: ridethe...@gmail.com. És tartalmazza a felhasználó
plain/text jelszavát.
[]
Az érdekes az, hogy ez a jelenség csak egy adott pillanattól kezdődött,
tehát valamelyik frissítéssel kerülhetett bele.
Én inkább exploitra tippelnék,
Laborczi Pál lp...@pse.siemens.hu writes:
De nagyobb hiba, hogy a lesbeálló program elégtelen sebességgel működik.
Ha a for ciklust sleep 1 nélkül futtatom, közel 100%-ra megterheli a
CPU-t. Létezik 1 sec alatti késleltetés?
Debian stable alatt lehet a sleepnek tört értékű argumentumot adni
2011-12-20 09:39 keltezéssel, Ferenc Wagner írta:
De továbbra is azt gondolom, hogy rosszul fogod meg a problémát: nem
pörögni kellene, hanem a TCP kapcsolat megnyitásakor visszakérdezni
identtel.
Rendben, meggyőztél. De ha lehet, egy kicsit bővebben, mert freebsd-ről
van szó. Telepítve
Laborczi Pál lp...@pse.siemens.hu writes:
2011-12-20 09:39 keltezéssel, Ferenc Wagner írta:
De továbbra is azt gondolom, hogy rosszul fogod meg a problémát: nem
pörögni kellene, hanem a TCP kapcsolat megnyitásakor visszakérdezni
identtel.
Rendben, meggyőztél. De ha lehet, egy kicsit
2011-12-20 12:13 keltezéssel, Ferenc Wagner írta:
Első
körben azt nézd meg, hogy az SMTP szerveredet (a szomszéd gépet) rá
tudod-e beszélni, hogy futtasson ident lekérdezést (esetleg csak a
szóban forgó email címre).
Épp erről van, ehhez keresem az Általad javasolt progit, de csak ilyenek
Erről beszélsz?
http://en.wikipedia.org/wiki/Ident
Köszi:
P.
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Laborczi Pál lp...@pse.siemens.hu writes:
2011-12-20 12:13 keltezéssel, Ferenc Wagner írta:
Első körben azt nézd meg, hogy az SMTP szerveredet (a szomszéd
gépet) rá tudod-e beszélni, hogy futtasson ident lekérdezést
(esetleg csak a szóban forgó email címre).
Épp erről van, ehhez keresem az
Laborczi Pál lp...@pse.siemens.hu writes:
http://en.wikipedia.org/wiki/Ident
Igen, RFC 1413, ahogy egy korábbi leveledben magad is írtad.
--
Feri.
_
linux lista -
On 12/20/2011 11:27 AM, Laborczi Pál wrote:
2011-12-20 09:39 keltezéssel, Ferenc Wagner írta:
De továbbra is azt gondolom, hogy rosszul fogod meg a problémát: nem
pörögni kellene, hanem a TCP kapcsolat megnyitásakor visszakérdezni
identtel.
Rendben, meggyőztél. De ha lehet, egy kicsit
2011-12-17 10:03 keltezéssel, Zs írta:
Hali!
Az ötleteket fölhasználva a követkző született:
Az iptables-be beraktam egy sort
--dport 25 -j LOG
opcióval, tehát bárki bárhova megnyit egy smtp portot, a naplóban
keletkezik nem is egy sor.
Ajánlanám a következő bővítést a
2011-12-16 18:05 keltezéssel, Attila Rajmund Nohl írta:
Jut eszembe, az nem járható út, hogy tcpdump-pal figyeled, milyen
levelek mennek ki a 25-ös porton és akkor a levél tartamából kiderül,
hogy mi küldözgeti?
Maga a levél megvan, tehát ez fölösleges lépés. a címzett
ridethe...@gmail.com,
2011/12/19 Laborczi Pál lp...@pse.siemens.hu:
2011-12-16 18:05 keltezéssel, Attila Rajmund Nohl írta:
Jut eszembe, az nem járható út, hogy tcpdump-pal figyeled, milyen
levelek mennek ki a 25-ös porton és akkor a levél tartamából kiderül,
hogy mi küldözgeti?
Maga a levél megvan, tehát ez
2011-12-19 16:32 keltezéssel, Attila Rajmund Nohl írta:
for i in/usr/sbin/*; do strings $i | grep ridethefog echo $i; done
Nincs találat.
De nagyobb hiba, hogy a lesbeálló program elégtelen sebességgel működik.
Ha a for ciklust sleep 1 nélkül futtatom, közel 100%-ra megterheli a
CPU-t. Létezik
Laborczi Pál írta:
2011-12-19 16:32 keltezéssel, Attila Rajmund Nohl írta:
for i in/usr/sbin/*; do strings $i | grep ridethefog echo $i; done
Nincs találat.
De nagyobb hiba, hogy a lesbeálló program elégtelen sebességgel működik.
Ha a for ciklust sleep 1 nélkül futtatom, közel 100%-ra
Hali!
Az ötleteket fölhasználva a követkző született:
Az iptables-be beraktam egy sort
--dport 25 -j LOG
opcióval, tehát bárki bárhova megnyit egy smtp portot, a naplóban
keletkezik nem is egy sor.
Ajánlanám a következő bővítést a szabályban:
-m state --state NEW
Ez csak az első,
Ferenc Wagner wf...@niif.hu writes:
Laborczi Pál lp...@pse.siemens.hu writes:
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik a szomszédos
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
On Thu, Dec 15, 2011 at 04:02:08PM +0100, Laborczi Pál wrote:
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik a szomszédos
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
kapcsolatot a
Az ötleteket fölhasználva a követkző született:
Az iptables-be beraktam egy sort
--dport 25 -j LOG
opcióval, tehát bárki bárhova megnyit egy smtp portot, a naplóban
keletkezik nem is egy sor.
Majd írtam egy perl scriptet, amely a tail -f-hez hasonlóan lesi az új
sorokat, és ha a
Laborczi Pál lp...@pse.siemens.hu írta (2011. december 16. 18:01):
Az ötleteket fölhasználva a követkző született:
Az iptables-be beraktam egy sort
--dport 25 -j LOG
opcióval, tehát bárki bárhova megnyit egy smtp portot, a naplóban
keletkezik nem is egy sor.
Majd írtam egy perl
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik a szomszédos
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
kapcsolatot a netstat-tal TIME_WAIT állapotban. De a PID/Program name
mezőben
2011.12.15. 16:02 keltezéssel, Laborczi Pál írta:
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik a szomszédos
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
kapcsolatot a netstat-tal
On 12/15/2011 04:02 PM, Laborczi Pál wrote:
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik
[]
Hogy' lehet elkapni egy ilyen nem kívánatos programot.
Auditd?
_
Laborczi Pál lp...@pse.siemens.hu writes:
Adott egy szerver, amely rejtélyes leveleket küldözget, de nem a helyi
postfix segítségével, hanem a 25-ös porton bejelentkezik a szomszédos
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
kapcsolatot a netstat-tal TIME_WAIT
Laborczi Pál wrote:
gépre. Mivel csomóban jönnek a levelek, sikerült megfognom egy fölépült
kapcsolatot a netstat-tal TIME_WAIT állapotban. De a PID/Program name
mezőben csak egy kötőjel (-) van.
Iptbles?
-m owner: a csomagot küldő folyamat UID, GID, PID, SID (session ID)
értékei, ill. a
43 matches
Mail list logo
