skype és a tűzfal

Fórumok

skype és a tűzfal

Hozzászólások

Sziasztok!

Volna egy kérdésem.
Tudomásom szerint a Skype azé tud átjutni egyes tűzfalakon mert a 80 http és a 443 https -en keresztül közlekedik. Egyes éber kis emberkék a cégnél ezt ki is használják, kis cseverészésre.
Ezt hol tudom az ip tablesben megadni drop-ra? Vagy esetleg a Zorp-ba?

Jól gondolom, hogy vmiféle protokollszűrés kell?

Előre is köszi a segítséget!

Hmm, a Skype tiltasa nem egyszeru. Eleg, ha tudod, hogy pl. en http proxy-n keresztul hasznalom, tehat TCP szinten normalis WEB bongeszesnek tunik a dolog. Tudtommal fel kell ismerni a Skype uzeneteket ahhoz, hogy kiszurhetoek legyenek.

Talan az egy kiskapu, hogy keves Skype logon server van, ha ezek fele blokkolod a forgalmat akkor nem tudnak belepni. Bar lehet, hogy azota fejlodtek, es minden supernode (potencialisan az osszes futo Skype program a vilagban, ez a P2P) lehet egyben valami logon proxy is, ekkor meg vagy love.

BTW, sose feledd, hogy minden TCP ketiranyu, tehat ha kiengedsz egy SSH-t, akkor azon vissza is lehet jonni, szoktam Skype-olni SSH tunnel felett is.

Na csinaltam egy dump-ot Skype login-rol. Nem tul biztato. Kb. 50 geppel probalta felvenni a kapcsolatot, reverse DNS-bol itelve kivetel nelkul broadband felhasznaloval. Azaz supernode-ot keresett es azon keresztul lepett be. Egy fix pont az ui.skype.com volt, de azzal csak annyit beszelt meg, hogy mi a legfrisebb Skype verzio. A tobbi kommunikacio nem tunt valami szoveges protokollnak. Vagy binaris, vagy titkositott minden.

Osszefoglalva: a login is P2P alapon zajlik, tehat bizonyos host-ok tiltasaval nem sokra mesz. Nemi esellyel a kezdeti kommunikacio is titkositott, igy ngrep-el is lehetnek gondok. Ettol meg a login elso x byte-ja lehet mindig azonos, ezt nem bogarasztam ki.

nalunk eleg durvan le van tiltva minden de a skype megis megy.
esetleg loggold le a forgalmat, amit bonyolit a belepeskor
es tiltsd le direktbe a hostot.

jah es az ssh tunelt is kapcsold ki met kulonben a tanultabb kollegak
azon fognak kimenni. :D
[code:1:d08e5fa957]
sshd_config:
AllowTcpForwarding no
[/code:1:d08e5fa957]

[quote:52f83399f6="hawk"]
jah es az ssh tunelt is kapcsold ki met kulonben a tanultabb kollegak
azon fognak kimenni. :D
[code:1:52f83399f6]
sshd_config:
AllowTcpForwarding no
[/code:1:52f83399f6]

A vilag osszes gepen te vagy a root? Ugyanis tipikusan az sshd egy szabad vilagbeli cuccon fut ezekben az esetekben. Lehet trukkozni a helyi SSH klienssel, csak hat abbol is fel lehet tenni sajatot.

[quote:10164a0a3f="keri"]
Egyes éber kis emberkék a cégnél ezt ki is használják, kis cseverészésre.

egy szónak is egy a vége...egy kis cseverészés kell a nehéz munka mellett.(persze amig nem megy annak rovására) :wink:

üdv,sutyee

[quote:e6ba081c71="dandor"]Ha a teljes kommunikáció titkosított, esetleg érdemes lehet fix méretű üzenetváltásokat keresni és ezeket az üzenetméreteket tekinteni jellemzőnek.

Több jellemző is van, a fentiek. Csak úgy septiben.

[quote:c6809f3f43="kecsa"]
A vilag osszes gepen te vagy a root? Ugyanis tipikusan az sshd egy szabad vilagbeli cuccon fut ezekben az esetekben. Lehet trukkozni a helyi SSH klienssel, csak hat abbol is fel lehet tenni sajatot.

nem, csak pár gépen, mert?. :D

Amúgy mi azt a nézetet követjük, hogy mindent szabad, amit nem tilos.
Na jó ez se teljesen igaz. :)

Szépen meg kell bujni a háttérben és csak a kirívó esetben előjönni.
pl szépen mérni a hálózati forgalmat és ha valami furcsaságot látsz, akkor kell
odamenni és elfenekelni a csúnya usert. :D

[quote:ce4855b4be="kecsa"]Osszefoglalva: a login is P2P alapon zajlik, tehat bizonyos host-ok tiltasaval nem sokra mesz. Nemi esellyel a kezdeti kommunikacio is titkositott, igy ngrep-el is lehetnek gondok. Ettol meg a login elso x byte-ja lehet mindig azonos, ezt nem bogarasztam ki.

Biztosan nem lesz könnyű feladat, de biztosan megoldható. Tudsz mutatni ngreppel vett mintát?

Minden program kommunikációja kezdetekor küld valamilyen fejlécet. Nem tudom, a Skype-nak milyen, de biztos, hogy van valamilyen jellemző mintája. Szépen elemezhető egy ilyen kapcsolat mondjuk az ngreppel, ami elérhető a (http://ngrep.sourceforge.net) címről -- én imádom ezt a programot --, és aztán irány a mintán alapuló szűrés (különböző módjai)!

Egy dolog biztosnak látszik: lesz legalább egy értelmezhetetlen, de pontosan 18 karakter hosszúságú kommunikáció a kliens gép 3205-ös portján.

Ha valaki tudja, milyen titkosítást használ a Skype, és megosztaná velem is, annak nagyon örülnék.

[quote:0a193ec7c4="kecsa"] Egy fix pont az ui.skype.com volt

Sajnos nem minden esetben igaz, nálam a 212.72.49.142-es cím volt többynire a fix. Azonban a tartomány igaznak tűnik, és ez kombinálva az előbbi észrevételeimmel, már jó kiindulópont. Neked is a 12350-es porton kommunikált az a 212.72.49.131-es ui.skype.com?

Nyilván az adott külső host tiltása nem sokat ér, és a belső gép 3205-ös portjának tiltása sem ad megoldást, ahogyan a belső gép teljes tiltása sem célszerű, de ha a szabályzat engedi (amennyiben van), az internetről egy-két percre ki lehet tiltani.

Biztosan van valami, ami a kapcsolatfelvétel sikerességére jellemző, és nagy valószínűséggel egyedi.

szasztok
itt most mindenki arról beszél hogyan nyomjuk ki a skype-ot
(ehhez nem sokat tudok hozzáfűzni)
nekem viszont az kellene, h debian/nat-iptables kódba mit rakjak be, h menjen skype a kliensről?
kösze

Csak egy tipp, nem tudom mennyit segítek vele:

~/.Skype/shared.xml
fájlban van egy <HostCache> rész, amiben egy csomó ip+port fel van sorolva. Valahogy ezek alapján talál bele a supernode-ok hálózatába, vagyis azzal a feltételezéssel él, hogy ami ip-n egyszer volt skype azon valszeg később is lesz. Ha ez nincs (pl, mert új telepítés, még csak most kapcsolódik először), akkor nyilván valami fix "kályhától" kell elindulnia. Na EZT a folyamatot kéne jól megfigyelni és ezt megakadályozni, illetve a klienseken kézzel kipucolni a hostcache-t a shared.xml-ből.

Ha a teljes kommunikáció titkosított, esetleg érdemes lehet fix méretű üzenetváltásokat keresni és ezeket az üzenetméreteket tekinteni jellemzőnek.

[quote:63ffb57cf4="szucs_t"]Minden program kommunikációja kezdetekor küld valamilyen fejlécet. Nem tudom, a Skype-nak milyen, de biztos, hogy van valamilyen jellemző mintája. Szépen elemezhető egy ilyen kapcsolat mondjuk az ngreppel, ami elérhető a (http://ngrep.sourceforge.net) címről -- én imádom ezt a programot --, és aztán irány a mintán alapuló szűrés (különböző módjai)!

Na jó, de akkor pontosan mi a megoldás?

[quote:2d499ad765="keri"][quote:2d499ad765="szucs_t"]Minden program kommunikációja kezdetekor küld valamilyen fejlécet. Nem tudom, a Skype-nak milyen, de biztos, hogy van valamilyen jellemző mintája. Szépen elemezhető egy ilyen kapcsolat mondjuk az ngreppel, ami elérhető a (http://ngrep.sourceforge.net) címről -- én imádom ezt a programot --, és aztán irány a mintán alapuló szűrés (különböző módjai)!

Na jó, de akkor pontosan mi a megoldás?

Én Skype-olnék a munkaállomásomról, az nreppel szondáznám a munkaállomásom kommunikációját, és abban garantáltal találnék olyan mintát, amely igen nagy valószínűséggel (vagy szinte teljesen egyértelműen) a Skype-kapcsolatra jellemző. Még netstattal vagy tcpdumppal megnézném, milyen külső géppel kommunikál a munkaállomásom, ezután az nreppel szondáznám a külső gép kommunikációját is, ott is keresve mintát. Ha az megvan, a mintatalálat bekövetkeztekor néhány percre letiltanám az észlelt kommunikációt. Jól meg kell vizsgálni, milyen portot használ a két Skype-ozó gép, mert más forgalmat is tilthatok az adott gépekről, amiket esetleg nem szándékozok. Ezt kell hatékonnyá és teljesen automatává tenni!

Skype-ot még nem vizsgáltam meg, és nem szűrtem így, de mindenféle más, kimondottan támadási módokat igen. El sem hittem, mi mindent meg lehet tenni az ngrep segítségével, amíg ki nem próbáltam. Bár még van néhány megoldandó feladat, egy roppant hatékony automata védelmi rendszert lehet kialakítani vele. A crontab helyett -- amivel csak percenkénti ellenőrzésre voltam képes -- valami mást kell alkalmazni, valamit, ami sűrűbb időzítésre, vagy események vizsgálatára képes. Tud valaki ajánlani egy ilyesmi időzítő vagy eseményfigyelő (az API-szintjéig lemenő) eszközt?

A naplóalapú és más behatolás-figyelő rendszereknek nagy jövője van. Szükséges a csomagszűrő tűzfal, de nem elégséges.

Remélem, tudtam segíteni.

Készítettem egy hasonló elveken alapuló, több részből álló automata programot, ami a támadásokat naplózza, és elvégzi a további szükséges lépéseket. Sajnos hosszú ideig támadt a szerverünket -- sokaknak biztosan nem mondok újat -- egy román banda, eleinte sikerrel. Az elkészült, és folyamatosan igazított program segítségével végül közelébe sem értek a roppant fontos és bizalmas adatokat tartalmazó internetes szervernek (bár tulajdonképpen nem információtolvajok voltak, hanem kakukkok, élősködők, akik saját anonim chatprogramjaikat kívánták feltelepíteni számukra ingyenes területre).

Persze ahhoz, hogy a program hatékonyan működjön, rengeteget kellett figyelni és vizsgálni. A szerver és a belső hálózat sajátosságaira nagyon oda kellett figyelni (tulajdonképpen ez volt a legnagyobb, sőt, igazából az egyetlen feladat), hogy ne vélje támadásnak azt, ami nem az. (Magyarul a szabály ez volt: minden tilos, ami nem szabad).

No, persze a résekkel rendelkező szolgáltatás-programok befoltozásával a támadók kizárhatók, de mindig, minden szolgáltatást nyújtó programban van valamilyen rés, ami kijátszható. A folyamatos frissítés mellet más eszközök is szükségesek, hiszen a rés a támadó által való felfedezése és a foltozás között hosszabb idő is eltelhet. Ha minden mögött (nem előtte, hanem utána, de garantáltan) áll egy behatolásfigyelő rendszer, akkor a támadóknak sokkal nehezebb dolguk van támadni, mint nekünk védekezni.

[quote:42a40e1442="kecsa"]
BTW, sose feledd, hogy minden TCP ketiranyu, tehat ha kiengedsz egy SSH-t, akkor azon vissza is lehet jonni, szoktam Skype-olni SSH tunnel felett is.

És ha ssh alagutat használnak a felhasználók, az ngrep se sokat segít ugye.

[quote:91f483ab6f="dandor"][quote:91f483ab6f="kecsa"]
BTW, sose feledd, hogy minden TCP ketiranyu, tehat ha kiengedsz egy SSH-t, akkor azon vissza is lehet jonni, szoktam Skype-olni SSH tunnel felett is.

És ha ssh alagutat használnak a felhasználók, az ngrep se sokat segít ugye.

Attól függően, hogy hol engedélyezik az ssh-alagutat, lesz odáig titkosított a kapcsolat. Ha nem a Skype-osok a Skype-szerveren, hanem te az átjáródon, akkor számodra semmi probléma. És egyébként sincs! Az ngrep természetesen csak a titkosított, értelmezhetetlen adatfolyamot fogja mutatni, de az IP-címek és portszámok titkosítatlanul maradnak, és a jellemzők is csak más formát öltenek. Lényegtelen, hogy azt látod, hogy "GET blablabla", vagy azt, hogy "kriksz-kraksz", ha az egyedi, vagy legalábbis nagy valószínűséggel egyedi. Nem a beszélgetésük tartalmára, a szövegre vagy kíváncsi, hanem a beszélgetésük tényére, különösen akkor nem, amikor a Skype valamiféle rejtjelezéssel továbbítja az üzeneteket.

Próbáld ki az ngrepet!

Nagyon egyszerű a használata:

[code:1:91f483ab6f]
ngrep -d eth0 -t -i 'minta' >> minta.log
[/code:1:91f483ab6f]
És hamarosan megtalálod a minta.log állományban azon kommunikációkat, amelyek tartalmazzák a "minta" karakteregyüttest, legyen az értelmezhető vagy értelmezhetetlen.

Természetesen egy RSA-alapú titkosított kapcsolatban sokkal nehezebb jellemzőket találni, hiszen az elküldött kódolt szöveg változik az eredeti szövegtől, hosszától, mindenétől, de -- szinte -- minden programkapcsolatnak van valamiféle fejlécrésze (pl. azonosításkérés-, vétel, adás stb.), ami mindig azonos.

Az a jó az ngrep-ben, hogy nincs olyan, hogy elrejtőzöm előle, meg hogy megtámadom a kiskapuját, mert az nem egy szolgáltatás, démon, amihez kapcsolódni kell. Az egyetlen eszköz ellene a titkosítás, de ahhoz nagyobb tudomány kell, mint ami az átlagfelhasználóban meg van. Következésképpen olyan programokat kell készíteni kliens oldalon is, amik támogatják mondjuk az RSA-alapú titkosítást.