❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz

Krádeže konektivity - analýza NATovaných paketů

Návody a problémy s konfigurací.
Zuhan
Příspěvky: 31
Registrován: 18 years ago

Krádeže konektivity - analýza NATovaných paketů

Příspěvekod Zuhan » 17 years ago

Dobrý den,
jako zřejmě každý, monitorujeme případy krádeže konektivity velmi primitivním způsobem, kdy klient u nás konektivitu odebírá NATujícím klientem (v našem případě CaCC WA-2204), za který připojí nějaké svoje AP a přerozděluje (přeprodává) dalším lidem, tzn. odsledováním provozu "vzduchu" dokážu určit, které MAC adresy "kradou". Pak ovšem tyto pakety prosviští NATem a přistanou na mém AP (MikroTik).
Můj dotaz směřuje k tomu, zda lze na MT nějak sofistikovaně analyzovat hlavičky paketů, vytáhnout z nich jejich původní adresy (před. NATem), případně je podle nich selektivně markovat a patřičně s nimi naložit ??
Vím, že je to asi boj s větrnými mlýny, ale rád bych se o to pokusil alespoň v případech, kdy se mi zloděj okatostí provedení přímo vysmívá :-(

Předem díky i za náznak řešení !!
0 x

soooc
Příspěvky: 1586
Registrován: 18 years ago

Příspěvekod soooc » 17 years ago

Zuhan píše:Dobrý den,
jako zřejmě každý, monitorujeme případy krádeže konektivity velmi primitivním způsobem, kdy klient u nás konektivitu odebírá NATujícím klientem (v našem případě CaCC WA-2204), za který připojí nějaké svoje AP a přerozděluje (přeprodává) dalším lidem, tzn. odsledováním provozu "vzduchu" dokážu určit, které MAC adresy "kradou". Pak ovšem tyto pakety prosviští NATem a přistanou na mém AP (MikroTik).
Můj dotaz směřuje k tomu, zda lze na MT nějak sofistikovaně analyzovat hlavičky paketů, vytáhnout z nich jejich původní adresy (před. NATem), případně je podle nich selektivně markovat a patřičně s nimi naložit ??
Vím, že je to asi boj s větrnými mlýny, ale rád bych se o to pokusil alespoň v případech, kdy se mi zloděj okatostí provedení přímo vysmívá :-(

Předem díky i za náznak řešení !!


Co takhle TTL na 1 na poslednim routeru pred klientem ? Zakazat lidem NAT a hotovo :)
0 x

teo
Příspěvky: 401
Registrován: 19 years ago

Příspěvekod teo » 17 years ago

soooc píše:Co takhle TTL na 1 na poslednim routeru pred klientem ? Zakazat lidem NAT a hotovo :)


Můžete to prosím trochu více rozebrat, proncip, funkce a kde to zakázat.


Doplňková otázka - a co režimy WISP u klientů, bude stále routovat jejich Wirelless Clietn Router?
0 x

soooc
Příspěvky: 1586
Registrován: 18 years ago

Příspěvekod soooc » 17 years ago

teo píše:
soooc píše:Co takhle TTL na 1 na poslednim routeru pred klientem ? Zakazat lidem NAT a hotovo :)


Můžete to prosím trochu více rozebrat, proncip, funkce a kde to zakázat.


Doplňková otázka - a co režimy WISP u klientů, bude stále routovat jejich Wirelless Clietn Router?


Bohuzel si clovek musi vybrat - bud bude mit u klientu WISP a nebo mu nebudou krast net - jina moznost neni.

Z packetu, co jdou z poza natu nejde nijak vycist, ze sli pres nat :(
Naposledy upravil(a) soooc dne 12 Nov 2007 13:52, celkem upraveno 1 x.
0 x

Zuhan
Příspěvky: 31
Registrován: 18 years ago

Příspěvekod Zuhan » 17 years ago

soooc píše:Co takhle TTL na 1 na poslednim routeru pred klientem ? Zakazat lidem NAT a hotovo :)


Myslíš zakázat NAT přímo na jeho WLAN klientovi ?? Do toho bych určitě nešel :-(
On už za tím klientem znovu nutně NATovat nemusí - co když si celou jeho "distribuční sí" postaví jednoduše bez dalšího routování a NATování - nechá to jako jeden segment.

Opravdu se ty pakety nedají na MT nějak zanalyzovat ??
Každý paket přece v sobě někde nese info, kdo ho před NATem vygeneroval, nebo ne ??
0 x

pajdys
Příspěvky: 16
Registrován: 19 years ago

Příspěvekod pajdys » 17 years ago

Zuhan píše:
soooc píše:Co takhle TTL na 1 na poslednim routeru pred klientem ? Zakazat lidem NAT a hotovo :)


Myslíš zakázat NAT přímo na jeho WLAN klientovi ?? Do toho bych určitě nešel :-(
On už za tím klientem znovu nutně NATovat nemusí - co když si celou jeho "distribuční sí" postaví jednoduše bez dalšího routování a NATování - nechá to jako jeden segment.

Opravdu se ty pakety nedají na MT nějak zanalyzovat ??
Každý paket přece v sobě někde nese info, kdo ho před NATem vygeneroval, nebo ne ??

Právě že ne odkud je ten paket si pomatuje ten natovací router... :-(
0 x

Zuhan
Příspěvky: 31
Registrován: 18 years ago

Příspěvekod Zuhan » 17 years ago

:-( V tom případě zbývá jedině blokovat nepřípustné MAC adresy až u klientova, což je dost surové řešení.
0 x

LT.CLOUD
Příspěvky: 94
Registrován: 18 years ago

Příspěvekod LT.CLOUD » 17 years ago

Zuhan píše:Dobrý den,
jako zřejmě každý, monitorujeme případy krádeže konektivity velmi primitivním způsobem, kdy klient u nás konektivitu odebírá NATujícím klientem (v našem případě CaCC WA-2204), za který připojí nějaké svoje AP a přerozděluje (přeprodává) dalším lidem, tzn. odsledováním provozu "vzduchu" dokážu určit, které MAC adresy "kradou". Pak ovšem tyto pakety prosviští NATem a přistanou na mém AP (MikroTik).
Můj dotaz směřuje k tomu, zda lze na MT nějak sofistikovaně analyzovat hlavičky paketů, vytáhnout z nich jejich původní adresy (před. NATem), případně je podle nich selektivně markovat a patřičně s nimi naložit ??
Vím, že je to asi boj s větrnými mlýny, ale rád bych se o to pokusil alespoň v případech, kdy se mi zloděj okatostí provedení přímo vysmívá :-(

Předem díky i za náznak řešení !!


Zdravím, není lepší řešení dát klijentům ,,nějakou,, rychlost za kterou zaplatí a stou at si dělají co chtějí. Tohle se mě zdá trochu divné. Když už si to jednou někdo zaplatil... Jinak si dej do slmlouvy že nesmí rosprodávat linku jinak je odpojíš.
0 x

Zuhan
Příspěvky: 31
Registrován: 18 years ago

Příspěvekod Zuhan » 17 years ago

To samozřejmě mám - ve smlouvě i ve všeobecných obchodních podmínkách. Kdybych chtěl jít do detailu, mužu řict, že borec nemá telekomunikační koncesi a prodává konektivitu sousedům a pod.
Je ovšem jasné, že z této strany do toho nemá cenu zajiždět, protože to situaci jedině zhorší. Proto v tom vidím poměrně marný boj a pokusil jsem se vysondovat, zda už to někoho nevytočilo natolik, že by to řešil nějak technicky.
Musíme dále brzdit a hlavně FUPovat ...
0 x

teo
Příspěvky: 401
Registrován: 19 years ago

Příspěvekod teo » 17 years ago

Zuhan píše:To samozřejmě mám - ve smlouvě i ve všeobecných obchodních podmínkách. Kdybych chtěl jít do detailu, mužu řict, že borec nemá telekomunikační koncesi a prodává konektivitu sousedům a pod.
Je ovšem jasné, že z této strany do toho nemá cenu zajiždět, protože to situaci jedině zhorší. Proto v tom vidím poměrně marný boj a pokusil jsem se vysondovat, zda už to někoho nevytočilo natolik, že by to řešil nějak technicky.
Musíme dále brzdit a hlavně FUPovat ...


Já to mám udělané takto:
veškeré LINKY nesmí být poskytování třetí straně - a to a za peníze či "zdarma". Tento stav kontrolujeme. Porušením je pokuta 10.000Kč. Pokud stojíte o poskytování třetí straně lze se domluvit na částečném cenovém navýšění za každou další stranu. Negarantujeme poskytnutí této možnosti, záleží na rozhodnutí hlavního administrátora.
0 x

Zuhan
Příspěvky: 31
Registrován: 18 years ago

Příspěvekod Zuhan » 17 years ago

Tak jak to píšeš by to mělo fungovat. Ale např. o vymahatelnosti (vymáháníschopnosti) zmíněné pokuty určitě nezapochybuji jenom já - při predstavě, že někoho kvůli pár stovkám poženu skoro do Haagu ...
0 x

teo
Příspěvky: 401
Registrován: 19 years ago

Příspěvekod teo » 17 years ago

Prostě já říkám, že poplatek za internet má být pro každou domácnost zvl᚝ stejně jako voda, plyn, elektrika, tv, radio, sat poplatek atd... :wink:
0 x

Petr Vlašic
Příspěvky: 588
Registrován: 19 years ago
Bydliště: Lanžhot
Kontaktovat uživatele:

Příspěvekod Petr Vlašic » 17 years ago

Zuhan píše:Dobrý den,
jako zřejmě každý, monitorujeme případy krádeže konektivity velmi primitivním způsobem, kdy klient u nás konektivitu odebírá NATujícím klientem (v našem případě CaCC WA-2204), za který připojí nějaké svoje AP a přerozděluje (přeprodává) dalším lidem, tzn. odsledováním provozu "vzduchu" dokážu určit, které MAC adresy "kradou". Pak ovšem tyto pakety prosviští NATem a přistanou na mém AP (MikroTik).
Můj dotaz směřuje k tomu, zda lze na MT nějak sofistikovaně analyzovat hlavičky paketů, vytáhnout z nich jejich původní adresy (před. NATem), případně je podle nich selektivně markovat a patřičně s nimi naložit ??

V případě NATu to není jednoduché jelikož zdrojová IP i MAC adresa se změní na adresu routeru, takže tímto způsobem to asi jde těžko. Lze ovšem sledovat hlavičku TTL(Time-to-Live) a v případě, že ji má "pachatel" o jednu menší než TTL od ostatních, je jasné že má na cestě oproti ostatním o jeden router navíc. Jinak se dá u NATu dostat i proti proudu(pokud víte co hledat a dotyčný to nemá zakázáno), viz. článek na rootu. Jinak ale než hledat skulinku v protokolech doporučuji sledovat činnost na aplikační vrstvě, je to mnohem sofistikovanější metoda. Pokud má někdo např. současně dvě ICQ spojení na jednu IP, už to o něčem svědčí(a pokud jich má 20, tak není o čem diskutovat).
0 x
Vždyť je to tak jednoduché…stačilo se zamyslet, špetku toho RTFM et voilà!

fujara
Příspěvky: 130
Registrován: 19 years ago

Příspěvekod fujara » 17 years ago

0 x

Leeonek
Příspěvky: 3485
Registrován: 19 years ago

Příspěvekod Leeonek » 17 years ago

Tohle je debata o ničem, pokud klient chce tak to rozprodá a nikdo s tím nic neudělá. Když mu dáš jednu ip a on si hodí vlastní router tak ste víme kde. Klient může argumentovat tím že má vlastní domací sí a nechce aby komple šli vidět, na tohle mu nemůžeš nic říct.
Ošetřit to smluvně je jediné co s tím de dělat ale jak to dokázat? Když klient řekně že mají doma 3 komple a na každém z nich běží jedno ICQ, to teda nevím, možná když jich bude 20 tak jo ale jinak.....
Když mu to dokážeš, můžeš z něj vymáhat pokutu ale ten borec pujde jinam protože má svou klientelu a tam to bude zkoušet zase, nemá smysl to vůbec řešit. Bohužel to je česká mentalita a pokles cen kvalitních wifi komponent jen umocňuje stále větší nárust těchto přicmrndávačů, byli tu a vždycky budou....
0 x