On 2018-11-01, Mateusz Viste <m...@n...pamietam> wrote:
> On Wed, 31 Oct 2018 21:02:57 +0000, Marcin Debowski wrote:
>> A routery? Nie modyfikują licznika?
>
> Routery to i owszem, oczywiście. Od tego ten licznik właśnie jest, by
> pakiety IP nie zapętlały się zbyt długo w meandrach internetu. Tutaj
> maksymalna ilość skoków jest zależna od tego ile sobie zażyczy nadawca (w
> granicach do 255 skoków, bo TTL IP to ośmiobitowa wartość). No ale
> dyskusja była, zdaje się, o przełącznikach.

Tak tak, ale korzystam z okazji i z Twojej wiedzy co by poukładac sobie
to w głowie w sposób nieco bardziej systematyczny.

> Wracając do tematu TTL, to istnieją urządzenia routujące które nie
> zmieniają licznika. Urządzenia te czynią tak dlatego, że chcą być
> niewidzialne ("stealth"), bo często poza wymuszaniem swojego trasowania
> wykonują także szereg innych operacji filtrująco-analizujących (DPI, IDS,
> IPS...). Zdarzyło mi się widzieć jak wielo-gigabitowa sieć z takimi
> urządzeniami została zabita przez 1 (jeden) błędny pakiet - właśnie przez
> brak mechanizmu wykrywania pętli w postaci TTL.

Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
(OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
zdarzenie (modyfikujące lub nie licznik).

--
Marcin

do góry

On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:
> Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
> (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
> z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
> zdarzenie (modyfikujące lub nie licznik).

Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt
ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala
odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa
się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna,
dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia
podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

Mateusz

do góry

On 2018-11-02, Mateusz Viste <m...@n...pamietam> wrote:
> On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:
>> Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
>> (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
>> z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
>> zdarzenie (modyfikujące lub nie licznik).
>
> Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt
> ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala
> odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa
> się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna,
> dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia
> podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

To nie było takie proste, ale nie moge obie przypomnieć teraz
szczegółów. Jak odgrzebię to zapodam.

--
Marcin

do góry

On 02 Nov 2018 07:29:34 GMT, Mateusz Viste wrote:

>> Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
>> (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten sposób
>> z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
>> zdarzenie (modyfikujące lub nie licznik).
>
> Licznik TTL to średnio interesujące źródło informacji, a sam jego odczyt
> ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie pozwala
> odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego który chowa
> się za danym adresem. Ale to informacja tak czy inaczej bardzo luźna,
> dużo lepsze wyniki w tym kontekście daje analiza flag, które host ustawia
> podczas hand-shake'u TCP (tzw. "TCP fingerprinting").

Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
windowsowych socketów. Od czego zacząć, jak ugryźć?

--
pozdrawiam
Roman Tyczka

do góry

On Fri, 02 Nov 2018 07:39:35 +0000, Marcin Debowski wrote:
> On 2018-11-02, Mateusz Viste <m...@n...pamietam> wrote:
>> On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:
>>> Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
>>> (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten
>>> sposób z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
>>> zdarzenie (modyfikujące lub nie licznik).
>>
>> Licznik TTL to średnio interesujące źródło informacji, a sam jego
>> odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie
>> pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego
>> który chowa się za danym adresem. Ale to informacja tak czy inaczej
>> bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag,
>> które host ustawia podczas hand-shake'u TCP (tzw. "TCP
>> fingerprinting").
>
> To nie było takie proste, ale nie moge obie przypomnieć teraz
> szczegółów. Jak odgrzebię to zapodam.

To jest bardzo proste. Jak kto ciekawy to sięgnie po gugla i znajdzie
m.in. to:
https://en.wikipedia.org/wiki/TCP/IP_stack_fingerpri
nting

Mateusz

do góry

On Fri, 02 Nov 2018 09:40:09 +0100, Roman Tyczka wrote:
> Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
> Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
> niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
> chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
> windowsowych socketów. Od czego zacząć, jak ugryźć?

Na tak zadane pytanie naprawdę nie wiem co odpowiedzieć, bo nie rozumiem
co kolega kombinuje. Odpowiem jak umiem.

Połączenie P2P to nic innego jak połączenie między jednym hostem a
drugim, bez udziału dedykowanego serwera. W praktyce jeśli chcemy móc
nawiązać połączenie w sposób niezależny od tego która ze stron jest
inicjatorem, to obie strony muszą posiadać socket otwarty w trybie LISTEN.
Czyli de facto oba hosty są "serwerami". Przykładem takiej implementacji
jest popularne NTP. NTP działa co prawda z UDP, ale przy TCP zasada jest
podobna. W naturze TCP leży pojęcie "serwera" i "klienta", więc dodatkowa
trudność przy TCP polega na ustaleniu kto będzie robił za serwer a kto za
klienta. Tutaj rozwiązania do głowy przychodzą mi (tak na zaraz) trzy:

1. jeśli adresy IP obu hostów są z góry znane, to ew. przyjąć że ten
niższy jest zawsze serwerem, więc niech wyższy się łączy.

2. oba hosty nasłuchują na porcie x, jednocześnie starając się nawiązać
równoległe połączenie z rozmówcą z innego socketu. Jak tylko komuś uda
się nawiązać połączenie, likwiduje swój socket nasłuchujący (a druga
strona zaprzestaje prób połączenia w drugą stronę).

3. oba hosty przechodzą losowo w tryb serwer/klient. Np. pierwsze 5s host
czeka na połączenie z zewnątrz. Jeśli się nie uda, to przechodzi w tryb
klienta i sam próbuje nawiązać połączenie z drugą stroną przez kilka
sekund. Długość okresów klient/serwer wypadałoby losować, coby uniknąć
nieszczęśliwej synchronizacji w której oba hosty zawsze są w tym samym
trybie.

Każda z powyższych metod ma swoje wady i zalety. Wybór zależy głównie od
założeń projektowych.

Od strony programowej nie ma tu nic szczególnego. Logika będzie różna
zależna od wersji 1/2/3, ale "klient" zawsze będzie musiał wykonać kroki
socket() + connect()
...a "serwer" zawsze będzie musiał wykonać kroki socket() + bind() +
listen() + accept()

Jeśli celem jest stworzenie jakiegoś własnego protokołu do wymiany
danych, to wybór UDP wydaje się (hobbystycznie patrząc) ciekawszy.
Pozwoliłby w dużo bardziej elegancki sposób rozwiązać etap nawiązywania
sesji, i pozwoliłby na dużo większą dowolność w implementacji metod
transferu danych.

Całkiem możliwe również że kompletnie nie zrozumiałem pytania, w takim
razie zalecam uściślenie.

Mateusz

do góry

On 02 Nov 2018 09:37:23 GMT, Mateusz Viste wrote:

>> Widzę, że kolega obcykany w TCP, więc skorzystam z okazji i spytam.
>> Na czym od strony TCP polega połączenie P2P, jak je uzyskać? Chodzi mi o
>> niskopoziomowy dostęp do socketa, od strony programowej. Załóżmy, że
>> chciałbym się pobawić w połączenia P2P i je zakodować na poziomie
>> windowsowych socketów. Od czego zacząć, jak ugryźć?
>
> Na tak zadane pytanie naprawdę nie wiem co odpowiedzieć, bo nie rozumiem
> co kolega kombinuje. Odpowiem jak umiem.
>
[...]

> Jeśli celem jest stworzenie jakiegoś własnego protokołu do wymiany
> danych, to wybór UDP wydaje się (hobbystycznie patrząc) ciekawszy.
> Pozwoliłby w dużo bardziej elegancki sposób rozwiązać etap nawiązywania
> sesji, i pozwoliłby na dużo większą dowolność w implementacji metod
> transferu danych.
>
> Całkiem możliwe również że kompletnie nie zrozumiałem pytania, w takim
> razie zalecam uściślenie.

Rzeczywiście za mało precyzyjnie napisałem. Używając określenia P2P miałem
na myśli nie tylko bezpośrednie połączenie host-host, co jest oczywiste,
ale dalsze problemy jakie za tym idą, czyli nawiązanie połączenia
omijającego NAT. Czytałem gdzieś kiedyś o tym, że sprawa opiera się o
niskopoziomowe manipulowanie nagłówkami TCP/IP w czasie zestawiania
połączenia, potem to już z górki (w sensie, że sama komunikacja jest innym
etapiem, a problemem jest nawiązanie połączenia). Takie rzeczy robi skype,
torrenty czy kiedyś emule.

--
pozdrawiam
Roman Tyczka

do góry

On 2018-11-02, Mateusz Viste <m...@n...pamietam> wrote:
> On Fri, 02 Nov 2018 07:39:35 +0000, Marcin Debowski wrote:
>> On 2018-11-02, Mateusz Viste <m...@n...pamietam> wrote:
>>> On Fri, 02 Nov 2018 04:02:17 +0000, Marcin Debowski wrote:
>>>> Nb. czytałem jakiś czas temu o bardzo ciekawym ataku opierającym się
>>>> (OIDP) własnie na odczycie stanu licznika - sprawdzane było w ten
>>>> sposób z jakim hostem łączył się atakowany serwer czy tez jakie zaszło
>>>> zdarzenie (modyfikujące lub nie licznik).
>>>
>>> Licznik TTL to średnio interesujące źródło informacji, a sam jego
>>> odczyt ciężko uznać za "atak". Swoją drogą, jego wartość faktycznie
>>> pozwala odgadnąć (z dużą dozą tolerancji) typ systemu operacyjnego
>>> który chowa się za danym adresem. Ale to informacja tak czy inaczej
>>> bardzo luźna, dużo lepsze wyniki w tym kontekście daje analiza flag,
>>> które host ustawia podczas hand-shake'u TCP (tzw. "TCP
>>> fingerprinting").
>>
>> To nie było takie proste, ale nie moge obie przypomnieć teraz
>> szczegółów. Jak odgrzebię to zapodam.
>
> To jest bardzo proste. Jak kto ciekawy to sięgnie po gugla i znajdzie
> m.in. to:
> https://en.wikipedia.org/wiki/TCP/IP_stack_fingerpri
nting

Ta forma ataku nie byłą prosta, nie fingerprintinig. Zresztą, mam coraz
więcej wątpliwości czy czegoś nie pomieszałem. Natrafiłem na opis chyba
na Niebezpieczniku, po którym dotarłem do oryginału, ale cholera nie
mogę się tego teraz doszukać.

--
Marcin

do góry

On Fri, 02 Nov 2018 10:11:30 +0000, Marcin Debowski wrote:
>>> To nie było takie proste, ale nie moge obie przypomnieć teraz
>>> szczegółów. Jak odgrzebię to zapodam.
>>
>> To jest bardzo proste. Jak kto ciekawy to sięgnie po gugla i znajdzie
>> m.in. to:
>> https://en.wikipedia.org/wiki/TCP/IP_stack_fingerpri
nting
>
> Ta forma ataku nie byłą prosta, nie fingerprintinig. Zresztą, mam coraz
> więcej wątpliwości czy czegoś nie pomieszałem. Natrafiłem na opis chyba
> na Niebezpieczniku, po którym dotarłem do oryginału, ale cholera nie
> mogę się tego teraz doszukać.

Ach bo ty o tym ataku o którym niewiele wiemy, że był skomplikowany.
Myślałem że odnosisz się do mechanizmu fingerprintingu TCP :)

Ataki to swoją drogą jak najbardziej, istnieją przeróżne i zaiste bywają
często mocno pokręcone.

Mateusz

do góry

On Fri, 02 Nov 2018 10:59:01 +0100, Roman Tyczka wrote:
> Rzeczywiście za mało precyzyjnie napisałem. Używając określenia P2P
> miałem na myśli nie tylko bezpośrednie połączenie host-host, co jest
> oczywiste,
> ale dalsze problemy jakie za tym idą, czyli nawiązanie połączenia
> omijającego NAT. Czytałem gdzieś kiedyś o tym, że sprawa opiera się o
> niskopoziomowe manipulowanie nagłówkami TCP/IP w czasie zestawiania
> połączenia, potem to już z górki (w sensie, że sama komunikacja jest
> innym etapiem, a problemem jest nawiązanie połączenia). Takie rzeczy
> robi skype, torrenty czy kiedyś emule.

Nie ma cudów - aby Grześ z Krzysiem mogli pogadać po TCP, to jeden z nich
co najmniej musi być poza NATem. Jeśli obaj są za NATem, to pomóc może
jedynie oparcie się na osobie trzeciej.

Z UDP można próbować kombinować, ale to niezwykle upierdliwa sprawa:

Krzyś wysyła datagramy UDP do Grzesia, z portu src 5000 do portu dst 6000.

Krzyś -> RouterK -> INTERNET -> RouterG -> Grześ

Po drodze RouterK zmienia port źródłowy datagramów na, dajmy na to, 20000.

W takiej sytuacji Grześ może tylko próbować wysyłać tysiące pakietów do
Krzysia, z losowymi portami src licząc, że RouterG w którymś momencie
podmieni port src na akurat ten wybrany przez RouterK. Słowem całkowita
loteria. Dla zwiększenia szans powodzenia, Krzyś może rozpocząć
kilkanaście sesji UDP z różnymi portami src, coby Krzysiowi było łatwiej
trafić.

Aby zrozumieć tandetność tej sytuacji, należy zrozumieć co tak naprawdę
robią RouterK i RouterG.

Kiedy router dostaje jakiś pakiet z wewnątrz:
1. zmienia port src
2. zmienia IP src
3. oblicza nowy checksum TCP (lub UDP)
4. zapisuje sobie w pamięci (w tzw. tablicy sesji) informację co
przetłumaczył, od kogo i na co.

Kiedy router dostaje jakiś pakiet z zewnątrz:
1. sprawdza w tablicy sesji czy posiada wpis odpowiadający tuplowi IPsrc
+IPdst+portSrc+portDst.
2. Jeśli któryś z wpisów tablicy sesji się zgadza, to podmienia adres
DST i port DST zgodnie z wpisem.

Wynika z tego, że aby ustalić połączenie z kimś za NATem, trzeba
wystarczająco szczęścia by wstrzelić się w parametry wpisu tablicy sesji.
A parametry te zna tylko sam router. Porty to wartości szesnastobitowe
(przy czym zakres 0-1024 można pominąć), więc kombinacji jest tylko nieco
ponad 4 miliony. Ale to dalej loteria.

Odpowiadając na pierwotne pytanie: nie ma takiej magii, która pozwoliłaby
ustawić na sockecie flagę "P2P" aby dostać się do dowolnego hosta za
NATem.

Ale cierpliwości - IPv6 już u progu :) (od 20 lat)

Mateusz

do góry