niepeĹnosprawny intelekt
Guest
Mon May 08, 2017 7:18 pm
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ę!
niepeĹnosprawny intelekt
Guest
Mon May 08, 2017 7:19 pm
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 $
Uzytkownik
Guest
Mon May 08, 2017 7:39 pm
W dniu 2017-05-08 o 21:18, niepełnosprawny intelektualnie 'POPIS/EU pisze:
Quote:
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
SnCu
Guest
Mon May 08, 2017 8:40 pm
W dniu 2017-05-08 o 21:19, niepełnosprawny intelektualnie 'POPIS/EU pisze:
Quote:
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.
Grzegorz Niemirowski
Guest
Mon May 08, 2017 9:24 pm
SnCu <taj@emni.ca> napisał(a):
Quote:
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/
SnCu
Guest
Mon May 08, 2017 11:08 pm
W dniu 2017-05-08 o 23:24, Grzegorz Niemirowski pisze:
Quote:
SnCu <taj@emni.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.
Grzegorz Niemirowski
Guest
Tue May 09, 2017 8:19 pm
SnCu <taj@emni.ca> napisał(a):
Quote:
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/
SnCu
Guest
Wed May 10, 2017 12:56 pm
W dniu 2017-05-09 o 22:19, Grzegorz Niemirowski pisze:
Quote:
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.
Marek
Guest
Wed May 10, 2017 2:14 pm
On Wed, 10 May 2017 14:56:34 +0200, SnCu <taj@emni.ca> wrote:
Quote:
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