chciałbym nawiązać do mojego wcześniejszego postu w którym pytałem jak
wykryć IP urządzenia pobierającego IP z DHCP...

zwłaszcza do Kolegi Przemola!

przepraszam chłopaki, ale nic z tamtego nie zrozumiałem...

chciałbym odpalić to na ENC

możecie mi jeszcze raz wyjaśnić? ale bez zalecany przez komisję dżołków
wnioskujących... powoli i dokładnie! jakie dokumenty powinienem poznać?

prawda jest brutalna - nic nie czaję!

do góry

a no wiadomo, urządzenie wpięte do sieci, a posukiwanie IP spod programu
w Windows!

P.S.
a może Ktoś by mi napisał za $

do góry

W dniu 2017-05-08 o 21:18, niepełnosprawny intelektualnie 'POPIS/EU pisze:
> chciałbym nawiązać do mojego wcześniejszego postu w którym pytałem jak
> wykryć IP urządzenia pobierającego IP z DHCP...
>
> zwłaszcza do Kolegi Przemola!
>
> przepraszam chłopaki, ale nic z tamtego nie zrozumiałem...
>
> chciałbym odpalić to na ENC
>
> możecie mi jeszcze raz wyjaśnić? ale bez zalecany przez komisję
> dżołków wnioskujących... powoli i dokładnie! jakie dokumenty
> powinienem poznać?
>
> prawda jest brutalna - nic nie czaję!


Donka pytałeś? On tam w Brikseli to chyba rozwala takie problemy w 5
minut :)

do góry

W dniu 2017-05-08 o 21:19, niepełnosprawny intelektualnie 'POPIS/EU pisze:
> a no wiadomo, urządzenie wpięte do sieci, a posukiwanie IP spod programu
> w Windows!
>

Najprościej to niech urządzenie po pobraniu IP robi w odstępach czasu
jakiś broadcast informujący "jestem i mam IP a.b.c.d". Albo odwrotnie -
niech program pod Windows broadcastuje, a urządzenie odpowiada.

Ale skoro to musi być LAN, bo tylko tam broadcasty przechodzą, to ja
bym: olał protokół IP, wyłuskał urządzenie po Ethernecie i gadał
wyłącznie po Ethernecie, nawet w razie potrzeby zestawił połączenie TCP
over Ethernet.

do góry

SnCu <t...@e...ca> napisał(a):
> Ale skoro to musi być LAN, bo tylko tam broadcasty przechodzą, to ja bym:
> olał protokół IP, wyłuskał urządzenie po Ethernecie i gadał wyłącznie po
> Ethernecie, nawet w razie potrzeby zestawił połączenie TCP over Ethernet.

Trudne implementacyjne a zysk niewielki.

--
Grzegorz Niemirowski
http://www.grzegorz.net/

do góry

W dniu 2017-05-08 o 23:24, Grzegorz Niemirowski pisze:
> SnCu <t...@e...ca> napisał(a):
>> Ale skoro to musi być LAN, bo tylko tam broadcasty przechodzą, to ja
>> bym: olał protokół IP, wyłuskał urządzenie po Ethernecie i gadał
>> wyłącznie po Ethernecie, nawet w razie potrzeby zestawił połączenie
>> TCP over Ethernet.
>
> Trudne implementacyjne a zysk niewielki.
>
Jedyna trudność to obejście zabezpieczeń, zwłaszcza na platformie
Windows. Z uwagi na malware używający podsystemu sieciowego Windowsa w
różny dziwny sposób, Microsoft poblokował wiele rzeczy, np. otwierając
socket w trybie gołym IP (bez TCP czy UDP), nie możemy wysłać pakietu IP
z identyfikatorem protokołu 6 (TCP) albo 17 (UDP), bo w ten sposób
omijamy normalną implementację TCP i zdaniem Microsoftu możemy narobić
jakichś szkód. Jak otworzymy socket w trybie Ethernet Frame, pewnie
będzie jeszcze więcej ograniczeń, ale ogólnie to się da, bo mam taki
stary już programik wysyłający ramkę Wake-on-lan i on działa poprawnie
nawet pod najnowszymi windowsami.

Zaś jeśli chodzi o resztę implementacji, to ja nie widzę większej
trudności w pracy z ramką Ethernet, niż z datagramem UDP. Przynajmniej
na *NIX-ach.

do góry

SnCu <t...@e...ca> napisał(a):
> Jedyna trudność to obejście zabezpieczeń, zwłaszcza na platformie Windows.
> Z uwagi na malware używający podsystemu sieciowego Windowsa w różny dziwny
> sposób, Microsoft poblokował wiele rzeczy, np. otwierając socket w trybie
> gołym IP (bez TCP czy UDP), nie możemy wysłać pakietu IP z identyfikatorem
> protokołu 6 (TCP) albo 17 (UDP), bo w ten sposób omijamy normalną
> implementację TCP i zdaniem Microsoftu możemy narobić jakichś szkód. Jak
> otworzymy socket w trybie Ethernet Frame, pewnie będzie jeszcze więcej
> ograniczeń, ale ogólnie to się da, bo mam taki stary już programik
> wysyłający ramkę Wake-on-lan i on działa poprawnie nawet pod najnowszymi
> windowsami.
> Zaś jeśli chodzi o resztę implementacji, to ja nie widzę większej
> trudności w pracy z ramką Ethernet, niż z datagramem UDP. Przynajmniej na
> *NIX-ach.

Nadal jednak jest to niepotrzebne kombinowanie, szczególnie jeśli naprawdę
chcesz nawiązać połączenie TCP bez warstwy IP. Prościej po prostu wysłać
broadcast żeby poznać IP drugiego hosta, tak jak pisałeś, i korzystać z
istniejącego stosu zamiast tworzyć alternatywny.

--
Grzegorz Niemirowski
http://www.grzegorz.net/

do góry

W dniu 2017-05-09 o 22:19, Grzegorz Niemirowski pisze:
>
> Nadal jednak jest to niepotrzebne kombinowanie, szczególnie jeśli
> naprawdę chcesz nawiązać połączenie TCP bez warstwy IP. Prościej po
> prostu wysłać broadcast żeby poznać IP drugiego hosta, tak jak pisałeś,
> i korzystać z istniejącego stosu zamiast tworzyć alternatywny.
>

Ale istnieje pojęcie Ethernet Przemysłowy (Industrial Ethernet) i tam
takie rozwiązania są standardem - są na to gotowe biblioteki.

A jedna z korzyści jest taka, że haker nie może wówczas z zewnątrz
połączyć się z takim urządzeniem - jeśli nie ma IP, to na zewnątrz ono
nie istnieje, nawet jeśli po tym samym LAN-ie biegają pakiety IP.

do góry

On Wed, 10 May 2017 14:56:34 +0200, SnCu <t...@e...ca> wrote:
> A jedna z korzyści jest taka, że haker nie może wówczas z zewnątrz
> połączyć się z takim urządzeniem - jeśli nie ma IP, to na zewnątrz
ono
> nie istnieje, nawet jeśli po tym samym LAN-ie biegają pakiety IP.

Ale co bz tego? Więlkszośćb popularnych ataków wykorzystuje
(przejęte) urządzenia brzegowe jako punktu styku z celem, to że cel
atalu nie ma IP nie ma znaczenia.

--
Marek

do góry