mi lehet ez a cím, és miért próbálják a gépek elérni?

Microsoft Windows

(bocs a címért :)

lehet, hogy láma a kérdés: routeren logoltam a forgalmat, hátha találok valami turpisságot valamelyik gépen (nem találtam :) ), és ez az egy dolog, amire nem jöttem rá, mi akar lenni:
DOD:UDP trigger from 192.168.2.127:58927 to 192.168.115.10:161
a hálón lévő összes win-es gépről (vista business x64 és 1db w2k) jönnek ilyenek rendszeresen, a linux gépről nem.
a gépek 192.168.2.0/24 hálózatban vannak. tudtommal nincsen 192.168.115.10-es címünk és nem is volt soha. úgyhogy nem tudom, honnan szedte ezt a címet a windows... és mit akar ott... snmp?
valaki elmagyarázná? thanks!

  • 1892 megtekintés

( Dwokfur v | 2010. 01. 20., sze – 22:35 )

google port udp 161: snmp

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

nem. nincsen ilyen cím a hálózatban, és soha nem is volt.

habár, most azon gondolkozok, hogy szolgáltató által adott "hálózati végpontunk" elég messze van mindentől, esetleg elképzelhető-e az, hogy a bejövő kábelünk és a routerünk előtt még lehet, hogy leraktak valami wireless routert, mint bridge-t, vagy esetleg valami mikrohullámú "átlövés" van, és annak a modeme vagy hasonló eszköz lehetne ez?
na majd holnap jól kipróbálgatom :)

( hawk | 2010. 01. 21., cs – 10:00 )

Egy apró kérdés.

Belső vagy külső interfacen érkezik be a 192.168.x.x-es tartományból a kérés?

Ha külső azaz internet felöl (tehát nem privát tartományból), akkor nem kell foglalkozni vele különösebben.
Naponta több száz ilyen és ehhez hasonló csomagot dob el minden linux gépünk.

Publikus internet felöl ugyanis nem érkezhet Privát tartományból kérés.
Nyugodtan lehet alkalmazni az alábbit:

iptables -N IN-tcphack
iptables -A IN-tcphack -j LOG --log-prefix "FireWall: IN-tcphack "
iptables -A IN-tcphack -j DROP

iptables -A INPUT -i eth0 -s 127.0.0.1 -j IN-tcphack
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j IN-tcphack
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j IN-tcphack
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j IN-tcphack

Nem felejtkeztek szerintem el csak meg kellene nézni az RFC linkeket is.
Linkelhettem volna be amúgy én is 20-30 RFC dokumentációt de nem biztos, hogy abból gyorsan és hatékonyan ki lehet nyálazni, ami kell ide.

Amúgy meg nem biztos, hogy hitvitát kellene nyitni arról, hogy egy szolgáltató jól teszi vagy sem azt, hogy privát IP tartományból
rendel IP címet a klienseknek vagy sem. A szabbvány egyértelműen tisztázza mit mire használhat az ember és mik származnak ebből.

Szerver hostingban lehet definiálni privát tartományt és meglátjuk kivel kommunikál majd a szerver.
ADSL/cablenet stb kliens oldali internet kapcsolatnál pedig megint egészen más tészta a dolog.

Én már szembesültem olyan szolgáltatóval, aki egyik pillanatról a másikra mindenféle értesítés vagy más nélkül
megváltoztatta a PPPOE kapcsolat felépítésének metódusát és a szolgáltató oldali végpont IP címe 192.168.1.1 volt.

Az eredmény pedig az lett, hogy a szintén 192.168.1.1-es IP címet használó kliens oldali szerver működésébe
igen kellemetlen problémák léptek fel. Mondhatjuk úgy is, hogy hol ment hol nem az elérése. Internet felé
pedig teljesen megszünt mindenfajta kommunikációja. Vicces volt.

Ha a 169.254.0.0/16 hálózatra gondolsz akkor az nem ugyanaz, mint a privát tartományok.
Szerintem egy privát tartományból vett NAT mögötti cím nem teljes értékű szolgáltatás.
Hogyan küldesz rá levelet, használsz VNC-t VPN-t vagy bármilyen kívülről elérhető szolgáltatást külső szerver segítsége nélkül?
Szóval nem elég a privát cím. Kell hálózatonként legalább egy publikus és majd én beállítom a NAT-ot a tűzfalamon ahogy én akarom és nem ahogy a szolgáltató gondolja.
Az én saját hálózatom nem tartozik a szolgáltató érdekkörébe így az ottani IP kiosztás és szolgáltatás elosztás sem.

"Szerintem egy privát tartományból vett NAT mögötti cím nem teljes értékű szolgáltatás.": ez igaz, de van, ahol ennek is örülnek.

A levélküldésben már régen nem ez a kérdés a probléma, a mai szolgáltatói gyakorlat az, hogy az smtp port csukva van. Csak a szolgáltatói smtp szerver érhető el mindkét oldalról. Én ezzel nem értek egyet, de ettől változni semmi nem fog:)

Routing meg szűrés szempontjából mi a különbség a 169.254 meg a 192.168 között? Szerintem semmi.

van vírusirtó és működik is, legalábbis ránéztem más vírusirtókkal gépekre és azok se találtak semmit.
de pont emiatt néztem a kimenő forgalmat, hátha elkapok valami gyanúsat. de semmi gyanús nem volt, kivéve a fenti ip címre menő udp csomagot. de ez nem hinném, hogy vírus vagy hasonló lenne, szerintem a windows csinálja, csak nem tudom, mit és minek.