Het kan zijn dat er in een hostsbestand staat

127.0.0.1 security.nl

Dit betekend dat je niet meer op security.nl kan komen omdat hij doorverwijst naar je pc en daar staat het niet :)

There is no place like home :)

gast ...... ga naar tweakers.net ofzo .... lees een boek ..... maar kom ons hier niet mee lastig vallen ....

alles wat begint met 127.x.x.x is je localhost, waarschijnlijk is jouw computer een gevaar voor je jezelf :p

loopback=127.0.0.1
zie wikipedia
& niet zo onaardig doen! ;-)

ies grappig..

Waaruit haal je dat het gevaarlijk zou zijn?

Google en Wiki zijn je vriend...
http://nl.wikipedia.org/wiki/Localhost
http://tools.ietf.org/html/rfc3330

Of ga naar www.bol.com en bestel een boek "TCP/IP voor Dummies", Daar staan al dit soort dingen duidelijk in.

Ja inderdaad de localhost is standaard altijd 127.0.0.1,dus ik denk dat die gewoon per abbuis is aangemerkt als gevaarlijk ip addres.
Het ip addres wat je krijgt van je provider staat hier totaal los van,en is ook geheel anders.
Achter dat addres kan je zelf regelen welk ip addres je toewijst voor je interne netwerk,of server.
Ach ja wat internet betreft, ieder netwerkverkeer daar zit een risico aan, geen enkele beveiliging is waterdicht.
Maar goed je bent zelf verantwoordelijk voor de beveiliging van je pc,de provider doet zelf ook wel wat aan internetbeveiliging.
Maar de hoofdtaak van de beveiliging ligt bij je zelf.
Iedere dag worden er weer nieuwe veiligheidslekken ondekt, welke op deze site worden gemeld.
Zo zullen de softwarefabrikanten weer met patches komen voor hun software, welke de nieuwe desbetreffende lekken dan dichten,die je desgewenst op je pc kan installeren.

127.*.*.* is inderdaad je eigen pc.

Vandaag dat in firewalls wordt aangeraden deze pakketten (mits ze over een andere netwerkkaart dan localhost binnenkomen) te blokkeren. Een pakket dat van het internet afkomstig is en is gericht aan 127.0.0.1 oid. wil je niet binnen hebben.

De kans dat het pakket aankomt is echter vrijwel 0 aangezien routers het niet bij jou kunnen afleveren.

waarom is de 'hosts file' zo gevaarlijk. Er is niemand die enig idee heeft wat er afspeeld in zo klein bestandje en dat je daarmee zulke geweldig dingen kan doen! Oke, van de hosts file, is er maar eentje van in je computer! Stel je voor dat je de computer gebruikt met de helen familie. We draai met de meest vriendelijk bestuuringsysteem Windows Vista! Ik stel in de hosts file 127.0.0.1 www.java.com Dat betekent dan ,niet alleen mijn user account Jeroen, maar ook die van mijn zusje, moeder en vader nu niet meer op 127.0.0.1 www.java.com kunnen bereiken. Ik gebruik de ACMA blacklist en voeg deze toe aan de hosts file voor goed doeleinden!

Je vergeet alleen dat er ook mallware bestaat die je hosts file aanpast en hier bv gespoofde sites in kan zetten.

Mallware zou bv je hosts file kunnen aanpassen zodat www.postbank.nl (of een andere bank site) naar een ander IP gestuurd word dan het echte ip van je bank.
Op dat andere IP heeft men dan een nep site draaien die gewoon lijkt op die van jou bank en als je daar vervolgens je gegevens invoerd ben je de sjaak!

Je hosts file is het 1e waar je OS naar kijkt om een translatie van een FQDN naar IP te maken. Zodra hier dus een match is komt de rest (en dus ook DNS) er niet meer aan te pas.

de vraag was waarom de reactie van soeperees zo reageerde op het betreffende artikel op security nl en was trouwens aan hem gericht
ps ik denk dat de stapel pc boeken(waaronder ook voor de dumies)die ik bezit en gelezen heb voldoende is om jou een paar jaartjes zoet te houden en de twintig jaartjes aan de computer tellen mischien ook wel mee,dus aub niet meer zo lomp reageren ok groetjes dejeff

als je het artikel 15 gevaarlijke ip lijst had gelezen had ik graag het antwoord gehad van soeperees die 127XXX1als gevaarlijk aanstipte,het is inderdaad een hostfile,maar mischien weet hij wel wat wij niet weten en daar dient security.nl
toch ook voor of niet soms groetjes dejeff

Ah.. Nu snap ik de vraag ook..

Zoals hierboven al een paar keer is gemeld is 127.0.0.1 een speciaal IP adres. Dit is de eigen computer, oftewel localhost.
De meeste gebruikers lopen zelf het meeste risico van hun eigen acties.. Gewoon een insider joke dus ;)

En voor wat betreft de lompe opmerkingen, niets van aantrekken. De meeste "goeroes" vergeten dat ze zelf ook ooit van niets wisten.

Natuurlijk weet ik hoe gevaarlijk de Windows hosts file is! Ik moest zelf eens voor collega van mijn oom een Nikon Capture NX2 installeren, en daarbij moest ik deze website blockeren met betreking tot de licencie! Mijn oom reageert verontwaardigd op even een regeltje blockeren en deze website is voor altijd verleden tijd. Hij moet eens weten over de Magie van de Windows Hosts file! Dat deze gewoon via google kan worden omgeleiding door een simpel ip address naar een heel andere website.

Dit is ook zo iets mooies , je type gewoon een ip address in en je komt automatisch op een bepaalde website uit!
http://87.233.159.186

Exclusief in de 'Hosts file' een link naar Brein.nl

# Brein
87.233.159.186 www.brein.nl
87.233.159.186 brein.nl
127.0.0.1 extranet.brein.nl
127.0.0.1 www.extranet.brein.nl

# Nikon Capture NX2
127.0.0.1 www.sams.nikonimaging.com
127.0.0.1 sams.nikonimaging.com

Maar layer-2 switches zullen dit niet tegenhouden.

Weet iemand wat een standaard XP PC doet als je er vanaf een andere PC op je LAN handmatig gefabriceerde UDP ethernetpakketten naar toe stuurt met als sender- en destination IP-adres 127.0.0.1? Komen die bijv. door de standaard XP firewall heen?

Pakketjes genereren kan vast wel met pacgen, packeth, bittwist etc., en luisteren op een UDP poort kan bijv. met netcat.
(klachten over portscans e.d. kun je naar abuse@127.0.0.1 sturen ;)

RFC1918 Recommended practice filtering of IP addresses
In zone based firewalls zul je dit tegen komen als policy van de in-zone naar de out-zone:
drop traffic van 127.0.0.0/0.255.255.255 naar any IP address;
heeft te maken met het voorkomen van IP spoofing.

127.0.0.1 is niet routeerbaar! en zal dus ook het netwerk niet op gaan vanaf je host systeem.
127.0.0.1 staat voor localhost, wat het dus het host station is waar je op zit.

Doe maar eens een "route print" vanuit een "dos-box" op je windows systeem.
Daar zul je deze zien staan:
Netwerkadres Netmask Gateway Interface
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1

127.0.0.1 is geen fisieke interface en heeft geen layer2 MAC adres.

Kortom, "verkeer" naar 127.0.0.x zal de pc niet verlaten en het netwerk niet op gaan.

wahahaha, laat me niet lachen met je boeken. Als jij zoveel boeken hebt zou ik ze is beginnen te lezen als ik jou was dan hoef je over 20 jaar teminste niet van die lompe vragen te stellen.

Één troost voor jou, zo te zien weet de helft van de mensen die hierop gereageerd niet waarover ze het hebben ;)

gebruik de reactie van Thasaidon maar als leidend, volgens mij één van de weinige die weet waar hij het over heeft.


@SirDice

De meeste "goeroes" zijn eerste begonnen met kennis op te doen over de werking van besturingssystemen, netwerken , etc etc. Als je die basis kennis hebt kun je überhaupt gaan praten over security.......

Kennis die vergaard wordt door o.a. vragen te stellen.

Een wijs persoon leert meer van het stellen van een domme vraag dan een dom persoon leert van een wijs antwoord.

Er is niets gevaarlijks aan de hosts file (wordt overigens ook op *nix gebruikt, sterker nog, daar komt het eigelijk vandaan).


Misschien moet je eens legale software proberen.



Een hosts file heeft niets met Google te maken.


Dan begrijp je duidelijk de functie van een hosts file niet.

Dat vroeg ik niet. Dat je via de standaard Windows TCP/IP stack geen willekeurige pakketjes naar buiten kunt sturen begrijp ik, maar attackers houden zich over het algemeen niet zo aan de regels die meneer Ballmer of collega's hebben opgesteld.

Met de tooltjes die ik noemde kun je (in elk geval onder Linux, en anders desnoods met tooltjes die bouwen op een good old DOS-based packet driver) elk gewenst ethernetpakket het netwerk opsturen.

Ik begrijp de functie van de hosts file echt wel! Op spyderweb.eu zoek je eerst ip address op van bepaald domain. Deze website kan je in hotst file plaatsen, en omleiden naar de betrefde fake website.

Ik heb geen ervaring met die tooltjes en ik zou ook niet weten hoe deze dus verkeer naar een systeem op het netwerk sturen met daarin het destination adres 127.0.0.1. Dit zal wel door spoofing van een mac of ip geveuren neem ik aan, maargoed.

Wat ik kan bedenken is dat het "target" systeem dus verkeer ziet binnen komen voor 127.0.0.1 en het dus vermoedelijk naar zijn localhost stuurt. Hierdoor zou in theorie dus bepaalde code geïnjecteerd kunnen worden op een "target"systeem.

Wat je hiertegen zou kunnen doen is in een firewall localhost verbieden verkeer naar buiten toe te sturen en/of van buiten te ontvangen.
Ik heb alleen geen idee of dat met de standaard Windows firewall kan, want ik gebruik daar andere software voor.

Met spoofing wordt over het algemeen het vervalsen van afzender gegevens bedoeld, en hoewel dat voor de hand ligt, hoeft dat hier niet het geval te zijn.

Een ethernet pakket bestaat uit 4 delen:
- een bestemmingsadres (6 bytes)
- een afzenderadres (6 bytes)
- een type-aanduiding (2 bytes), voor IP pakketten is dit 0x800 (decimaal 2048)
- de inhoud van het ethernetpakket, de lengte is meestal beperkt tot 1500 bytes.

Indien de inhoud van het ethernetpakken een IP-pakket is, zal er opnieuw sprake zijn van een header (inclusief bron- en bestemmings IP-adressen) en een inhoud, die op zijn beurt weer een TCP of een UDP pakket kan zijn (het zijn dus enveloppen in enveloppen etc).

De ethernetkaart in een PC aangesloten op een switch zal elk pakket ontvangen dat door die switch wordt doorgelaten. Normaal gesproken zal die netwerkkaart alle pakketten negeren tenzij het bestemmingsadres FF-FF-FF-FF-FF-FF (Ethernet broadcast) is, of gelijk is aan zijn eigen ethernetadres (unicast). Zowel bij broadcast als een match op het bestemmingsadres zal de netwerkkaart, zodra het hele pakket ontvangen is, de driver (via een hardware interrupt) er op wijzen dat er een ethernetpakket in een geheugenbuffer staat dat moet worden afgehandeld.

Overigens bestaan er "slimmere" ethernetkaarten die een stuk "TCP-offload" voor hun rekening nemen waarmee de CPU in je PC wat minder belast wordt (is gangbaar bij servers).

Omdat je met de juiste tools elk gewenst ethernetpakket kunt maken, kun je een volledig legitiem ethernetpakket maken met daarin als afzender ethernetadres dat van de netwerkkaart van de zendende PC (maar dat hoeft niet), en als doeladres dat van de PC die je wilt testen. Ethernet-broadcast mag ook, dan worden alle PC's aan je LAN getest! In de IP-header kun je ook het IP-adres van de zendende PC opnemen wat mij betreft (geen spoofing dan, maar 127.0.0.1 als afzenderadres is voor dit experiment natuurlijk ook interessant), waar ik in geïntereseerd ben is hoe Windows PC's en eventuele firewalls reageren op via het netwerk binnenkomende pakketten bestemd voor 127.0.0.1 (zelf heb ik dat nog nooit getest).

Iemand ervaring hiermee?

Correcter, alle PC's binnen het broadcast domain (een LAN kan meerdere broadcast domains hebben ;) )


Zelf ook nooit getest. Lijkt me overigens redelijk makkelijk te testen met http://nemesis.sourceforge.net/.

Met "spoofen" bedoelde ik in dit geval het faken van het destination adres, want dat moet uiteindelijk op de target host als 127.0.0.1 uit komen.

Voor wat betreft een broadcast, dat zou idd alleen binnen hetzelfde LAN werken. (een router laat immers standaard geen broadcasts door). Aangezien de meeste ISP modems als router werken zal dat dus vanaf het internet niet zomaar werken.
Daarnaast draaien die meeste routers ook nog eens NAT, en dus zou het nog lastiger worden om vanaf het internet een target host achter een NAT router op deze manier te benaderen omdat je dan ook de range zult moeten weten die achter de router zit.

Wat ik nog wel even wil opmerken is dat switches niets met ip's doen, maar met mac adressen (layer2). iig de huis tuin en keuken switches dan.

En ja, ook mij lijkt het interesant om te weten wat een default firewall hiermee doet.
Mijn firewall zal verkeer naar 127.0.0.x vanaf een "extern" adres blocken omdat ik dat zo zelf heb geconfigureerd.
Localhost mag alleen benaderd worden door 127.0.0.x zelf en door mijn lokaal geconfigureerde IP's zodat lokale applicaties en processen gewoon hun ding kunnen doen, maar van buiten af dus niets hierheen mag.

Call me paranoid :)

Een LAN kan welliswaar meerdere IP-broadcast domains hebben, maar niet meerdere Ethernet-broadcast domains. Er bestaat maar 1 ethernet broadcast adres, en dat is FF-FF-FF-FF-FF-FF (er bestaat niet zoiets als Ethernet subnetting).

Nemesis begint wat grijze haren te krijgen en is nauwelijks geschikt voor moderne script-kiddies (commandline, wat is dat?).

De pakketten die ik gisteren noemde zijn wat nieuwer en ook allen op sourceforge te vinden: http://pacgen.sf.net, http://packeth.sf.net en http://bittwist.sf.net. Hoewel pacgen en bittwist ook alleen commandline zijn, biedt packeth (volgens de screenshots) een GUI. Bij bittwist zit een mogelijk interessante pcap file editor en (niet voor win32, maar wel voor BSD ;) een pcap based ethernet bridge. Onderaan deze page: http://bittwist.sf.net/doc.html staan een aantal gerelateerde tools. Als ik wat meer tijd zou hebben zou ik wel spelen met dit soort spul...

Nee hoor. Sterker, niet paranoid genoeg. Doe in een CMD prompt maar eens: ping 127.9.9.9 of zo, dan krijg je ook antwoord (gek genoeg van 127.0.0.1). Indien mogelijk in jouw Windows firewall kun je het beste 127.x.x.x blokkeren, zoals ene Carlos Moreno ook terecht opmerkt in het geval van Linux iptables (in zijn voorbeeld staat "lo" voor de loopback interface, zeg maar de virtuele netwerkkaart waar 127.0.0.1 "aan hangt"), zie: http://forum.soft32.com/linux2/Iptables-127-ftopict45058.html

Aanvulling: roepen dat een IP adres (of -reeks) niet routeerbaar is, is onverstandig. Correct is dat het niet routeerbaar zou moeten zijn, maar ik heb genoeg voorbeelden gezien van routers die 192.168.x.x, 10.x.x.x, 172.16.x.x t/m 172.31.x.x en 169.254.x.x gewoon naar hun upstream doorstuurden (in elk geval oudere Draytek Vigor en een oudere Speedtouch routers doen dit, maar ik heb ook grote Cisco dozen wel eens onverwachte dingen zien doen). Doe maar eens alle vier (tracert voor windows users, gebruik in plaats daarvan traceroute voor Linux en dergelijke):

tracert 192.168.254.254
tracert 172.31.254.254
tracert 169.254.254.254
tracert 10.254.254.254

Neem in elk geval adressen die niet bestaan in je eigen LAN en laat het resultaat hier ff weten! Zelf krijg ik antwoord van de eerste router bij m'n ISP (die laat het pakket dus niet door, maar m'n ADSL router in drie van de vier bovenstaande gevallen wel)...

Of er routers zijn die IP pakketten met destination adres 127.x.x.x doorlaten betwijfel ik, maar uit ervaring weet ik dat maar weinig routers naar source IP-adressen kijken (toen ik er, enkele jaren geleden voor het laatst naar keek, waren udp en icmp pakketten met spoofed source IP adres gangbaar op "het internet"). Als je in je NAT-routertje een server gedefinieerd hebt zou het me niet verbazen als die IP pakketten met source-IP=127.x.x.x kan ontvangen vanaf de internet-zijde. Ik vertrouw geen enkele router totdat ikzelf het tegendeel bewezen heb, wat bij een ADSL routertje niet zo eenvoudig is natuurlijk...

Welke dus strand bij de eerste de beste router (module). Je begrijpt waarschijnlijk de term broadcast domain niet helemaal.


http://en.wikipedia.org/wiki/Broadcast_domain

De data link layer is laag 2 weet u nog?

Vergelijk een subnet-broadcast (laag 3) eens met een broadcast (laag 2).

Zet je NAT een keertje uit en exact hetzelfde gebeurd. Het punt is dat de meeste routers een default gateway hebben. Alles wat niet expliciet in een andere route is opgenomen wordt daar naar gerouteerd.


Een router heeft ook een localhost interface. Als het ergens heen gerouteerd wordt dan is het daar naar.


Dat is ook de functie niet van een router. Een router route verkeer op basis van het destination IP, niets meer en niets minder.


Iets wat ik in de praktijk heb gezien. RST pakketjes naar onze webserver port 80, destination IP klopte. Het source IP was echter 127.0.0.1. Werd niet door de router tegengehouden (waarom zou 't). Wel door de firewall (daar heb je zo'n ding voor).

Zoals SirDice al zei, routers kijken naar destination adres en sturen het verkeer daarheen waar het naartoe moet.

Een source adres is daarbij helemaal niet van belang voor een router.
Het enige wat een router zal doen is het source adres aanpassen naar dat van zichzelf zodat de volgende "hop" in het netwerk weet waar het vandaan komt. Voor zover ik weet zou het MAC adres van de source wel onveranderd blijven.

Alleen als een router niet weet waar het heen moet zal de router een "destination host unreachable" oid terug proberen te sturen.
(afhankelijk van de router natuurlijk).

@Bitwiper

Nee hoor, dat is helemaal niet gek. Doe op je windows machine maar eens een route print daar zul je zien dat het gehele class A netwerk (127.0.0.0/8) als gateway de 127.0.0.1 heeft met interface 127.0.0.1.
Alles wat je dus naar 127.x.y.z stuurt gaat automatisch naar 127.0.0.1. Dit zit voor zover ik weet standaard in Windows. (Linux zou ik zo even niet weten.)

Err, nee. Het source MAC adres is de router, het source IP wordt alleen aangepast indien men NAT gebruikt. Destination MAC is de next hop, destination IP blijft ongewijzigd.


Elke router zou dit terug moeten sturen. Indien een router echter een default gateway heeft wordt het simpelweg daarheen gestuurd.


Nog simpeler, ifconfig lo0 (op *nix) en ipconfig /all (windows). Dan zul je zien dat localhost een subnetmask 255.0.0.0 heeft.

@SirDice: volgens mij hebben wij geen verschil van inzicht over layer 2 broadcast domains, maar wel over het volgende:



In mijn definitie (maar dat kan best fout zijn) is een LAN hetzelfde als een broadcast domain. Een VLAN is een soort van LAN, namelijk eentje die gebruik maakt van trunks waar ook andere VLAN's over kunnen lopen. Natuurlijk kun je het hele netwerk van een campus ook een LAN noemen, maar gezien vanaf Jupiter kun je dan net zo goed het hele Internet een LAN noemen. Kortom, voor mij houdt een LAN op zodra je door een router (layer 3 device) gaat. Dus is een LAN (in mijn definitie) hetzelfde als een (Ethernet) broadcast domain.

@Thasaidon: als ik naar www.security.nl ping verwacht ik antwoordpakketjes met daarin als afzenderadres het IP-adres van www.security.nl, niet dat van mijn default gateway. Dus als ik naar 127.9.9.9 ping verwacht ik antwoord van dat adres - dat pakketjes via een gateway met een ander IP adres gerouteerd worden boeit niet.

Aanvulling: ook achter een NAT/PAT router verwacht ik transparant met www.security.nl te kunnen communiceren. Als ik dit venster refresh en snel netstat -an uitvoer zie ik iets dergelijks (underscores toegevoegd voor de duidelijkheid):

TCP__192.168.1.12:1540__213.156.1.80:80__ESTABLISHED

Daar hebben (NAT) routers a.k.a. gateways niks mee te maken (dat www.security.nl een ander IP-adres en mogelijk een ander poortnummer van mij ziet is een ander verhaal).

Nee, een LAN kan meerdere subnetten bevatten waarmee je automatisch ook meerdere broadcast domains hebt. De definitie van LAN zegt niets over het wel of niet aanwezig zijn van routers.


http://en.wikipedia.org/wiki/Local_area_network




Een VLAN maakt het makkelijker om subnetten aan te maken en deze eenvoudig aan elkaar te koppelen over verschillende switches. VLANs gebruik je om je broadcast domain te verkleinen. Het zelfde effect bereik je ook door "fysieke" subnets te maken. VLANs maken het alleen eenvoudiger.

Bedenk dat een broadcast (255.255.255.255 en MAC FF:FF:FF:FF:FF:FF), standaard, niet gerouteerd wordt. Waardoor dit automatisch de grens is van het broadcast domain. Daarom moet je voor zaken als DHCP relays of ip-helper gebruiken.

@SriDice

Je hebt helemaal gelijk... maar ik ging in mijn gedachten uit van een NAT router, omdat de meeste ISP's een modem leveren welke als NAT router draait, en bij NAT wordt wel het source IP aangepast.
Sorry voor de verwarring.

@Bitwiper
Als ik achter een NAT router zit met een pc 192.168.1.12 en ga naar www.security.nl, dan zal idd het destination ip van www.security.nl niet veranderen in de pakketten, maar wel het source IP.

De nat router zal in de pakketten het source ip van 192.168.1.12 veranderen naar het public ip wat de router zelf heeft, anders zou de server van www.security.nl namelijk een source van 192.168.1.12 zien en dat is een zgn "private ip" wat dus niet routeerbaar is op het internet (volgens alle afspraken dan).

Dus het source IP word wel degelijk door de router aangepast.
Dat jou systeem een session ziet tussen 192.168.1.12 naar www.security.nl is logisch, want jou systeem merkt niets van die NAT translatie die jou router doet.

Dat was volgens mij niet helemaal het punt.

Meer dat als je een ping doet naar www.security.nl (213.156.1.80) dat je geen antwoord terug krijgt van 74.125.77.106.

Iets wat met 127.9.9.9 schijnbaar wel gebeurd op Windows:



Onder bsd overigens niet:

Ik snap hier even niet wat je bedoeld...
Als ik ping naar www.security.nl word dat gewoon geresolved door DNS wat het ip van het domain oplevert.

thasaidon@DellBuntu:~$ ping www.security.nl
PING securehosting.pine.nl (213.156.1.80) 56(84) bytes of data.

--- securehosting.pine.nl ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7008ms

thasaidon@DellBuntu:~$

Blijkbaar reageerde de server niet op ICMP (ping request), maar DNS resolved wel gewoon naar het goede IP.


Met Ubuntu dus wel...
thasaidon@DellBuntu:~$ ping 127.9.9.9
PING 127.9.9.9 (127.9.9.9) 56(84) bytes of data.
64 bytes from 127.9.9.9: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 127.9.9.9: icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from 127.9.9.9: icmp_seq=3 ttl=64 time=0.041 ms

--- 127.9.9.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.040/0.040/0.041/0.007 ms
thasaidon@DellBuntu:~$

Dus ik denk dat het wel of niet reageren van een ping naar 127.x.y.z afhangt van de default routeringen die een OS gebruikt en welke interface er uiteindelijk wel of geen responce geeft.

Ubuntu:
thasaidon@DellBuntu:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.0.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 1000 0 0 eth1
default 172.16.0.254 0.0.0.0 UG 100 0 0 eth1
thasaidon@DellBuntu:~$

Windows XP:
C:\Documents and Settings\Thasaidon>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 02 44 69 20 8e ...... Realtek RTL8139 Family PCI Fast Ethernet NIC - P
acket Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.0.254 172.16.0.1 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.16.0.0 255.255.255.0 172.16.0.1 172.16.0.1 30
172.16.0.1 255.255.255.255 127.0.0.1 127.0.0.1 30
172.16.255.255 255.255.255.255 172.16.0.1 172.16.0.1 30
224.0.0.0 240.0.0.0 172.16.0.1 172.16.0.1 30
255.255.255.255 255.255.255.255 172.16.0.1 172.16.0.1 1
Default Gateway: 172.16.0.254
===========================================================================
Persistent Routes:
None

C:\Documents and Settings\Thasaidon>

Als je een ping doet naar een bepaald IP adres (ww.security.nl in mijn voorbeeld) dan verwacht je niet dat een ander IP adres (74.125.77.106; welke overigens van google is) hierop reageert.

Dit gebeurd dus bij 127.9.9.9 wel, 127.0.0.1 reageert.


Resolving heeft er ook niet zoveel mee te maken, het was een voorbeeld.



Dat geloof ik.


Link-local is 169.254.0.0/16. Als ik het lijstje verder bekijk zie ik nergens dat 127.0.0.0/8 gerouteerd wordt naar 127.0.0.1, wat je in de Windows routing tabel dus wel ziet.

Yup, ik snap em nu

Ok, ik dacht dat Link-local hetzelfde zou zijn als localhost dus 127.0.0.1. Maar zoveel verstand heb ik niet van Linux.
Waarom Ubuntu dan wel een reply geeft op een ping naar 127.9.9.9 is mij dan een raadsel.
Van Windows snap ik het nog omdat alles naar 127.x.y.z "opgevangen" word door 127.0.0.1 welke dus een reply geeft.

@SirDice: formeel heb je gelijk dat de definitie van Local Area Network niets zegt over het medium en de gebruikte protocollen en dus nogal subjectief is. Misschien moet ik voortaan maar de term LAN-segment hanteren...

Overigens is de term "broadcast domain" ook niet duidelijk meer sinds private VLAN's, d.w.z. dat je switchpoorten zo kunt instellen dat een server met een hele reeks clients kan communiceren, terwijl elk van die clients slechts de server "ziet".

en
't is een beetje muggeziften, maar geen enkel MAC-adres wordt gerouteerd. Sterker, achter de router kan best een ander medium dan Ethernet gebruikt worden, de next hop heeft dan geen Ethernetadres.

Volgens http://tools.ietf.org/html/rfc1812 5.3.5.1 mogen "limited broadcasts" (destination = 255.255.255.255) niet worden geforward. De situatie bij subnet broadcast (bijv. 192.168.255.255 die natuurlijk ook met destination MAC adres FF:FF:FF:FF:FF:FF bij de router aankomen) is echter een stuk minder duidelijk....


M.b.t. door routers filteren van pakketten op basis van source adressen: In http://tools.ietf.org/html/rfc1812 (en http://tools.ietf.org/html/rfc2644) staat in 4.2.2.11 dat pakketten met source IP-adres 0.0.0.0 moeten worden geblokkeerd tenzij de router daar zelf iets mee doet (bootp etc). Ook 255.255.255.255 (aangegeven als {-1, -1}) mag niet als source adres worden gebruikt. Dus zal elke router iets aan filtering op source adressen moeten kunnen doen. Verder staat in 4.2.2.11 achter (e) dat 127.x.x.x niet op het netwerk voor mag komen, zonder aanduiding of het hier om source of destination adres gaat. Logischerwijs lijkt het me dat routers dus ook pakketten met dit sourceadres zouden moeten blokkeren; immers, waar zou een eventueel antwoord of ICMP foutmelding naar toe moeten?

Interessant is overigens wel dat 5.3.7 dit lijkt af te zwakken, door er SHOULD c.q. SHOULD NOT van te maken: Van een beetje moderne router mag je toch wel verwachten dat ie dit implementeert?

"Een pakket dat van het internet afkomstig is en is gericht aan 127.0.0.1 oid. wil je niet binnen hebben."

Een pakket dat van het internet afkomstig is, en gericht is aan 127.0.0.1, zal nimmer bij jouw computer terecht komen.... Dat zou net zoiets zijn als verwachten dat je brieven bezorgd krijgt door de postbode waarop de afzender zijn eigen adres als afleveradres heeft geschreven. Waarom zou de postbode immers zo'n brief bij jou bezorgen ?

Als je dit draadje een beetje doorgelezen had, had je dus kunnen lezen dat er tools zijn die dit allemaal kunnen faken waardoor dit dus wel werkt.

...omdat 't de postbode zijn werk is brieven te bezorgen en hij zal hierbij alleen kijken naar het aflever-adres...

Die vergelijking is leuk geprobeerd maar gaat natuurlijk mank. Je kunt best een brief naar jezelf verzenden en die zal (mits voldoende gefrankeerd) echt wel door een postbode bezorgd worden. (Net zoals je ook naar jezelf email kan verzenden.) Met IP packets net zo, als je de betrokken nodes (postbodes) op het netwerk niet expliciet vermeld dat ze 't niet moeten doen, zullen ze 't gewoon wel doen...

En zover ik de discussie nu (goed?) volg, gaat 't er nu om in hoeverre de ip-stacks van verschillende Operating Systems dit zo geïmplementeerd hebben dat dit dus niet gebeurd.

dat een eenvoudig vraagje waarop ik een antwoord wilde zulke reakties en discuties heeft losgemaakt bewijst toch maar de waarde van een goed forum zeker als de meeste van het onderwerp echt wel werk van gemaakt hebben.
bedankt SIRDICE voor de steun,en deskundige uiteenzetting,en predju,GA EEN BOEK LEZEN en leer mens wezen.
groetjes dejeff

Sorry dat ik het toch even vraag, want blijkbaar weet ik iets (nog) niet. Ik heb het zelfs via mijn oude bookmarks even nageslagen op: ftp://ftp.ripe.net/rfc/rfc1918.txt & daar staat dat ip niet bij. Dus waarom & sinds wanneer is of moet 169.254.x.x een internet-onzichtbaar ip?

Ik ben me overigens niet lang geleden de hieperdepieperhopsasa geschrokken toen ik erachter kwam dat een switch naar die ip-range bleek te verwijzen, meteen veranderd.

De 169.254.x.x/16 range is geen private range zoals de ranges in rfc1918.
Deze range is een soort "zero config" range.
Als een systeem geconfigureerd is om middels DHCP een ip te verkrijgen, maar om wat voor reden dan ook, dit niet krijgt, dan zal het OS de interface standaard met een IP uit deze range configureren.
Of Linux dit ook doet weet ik niet, want ik heb alles met vaste ip's geconfigureerd, maar ik weet dat Windows dit wel zo doet.
Ondanks dat deze range dus niet echt een "private range" is welke bij LAN netwerken gebruikt wordt, wordt ook deze range niet op internet gerouteerd.


http://en.wikipedia.org/wiki/Private_network

Ik heb er ooit maar eens ééntje bijgezet en dat is deze:
127.0.0.1 pagead2.googlesyndication.com

Grappig topic...



"helemaal" klopt niet, voor een pakketje dat naar buiten gaat wordt source adres wel gechecked. Zonder IP kun je niets.
En bij ACL is het zeer zeker van belang als je een inkomende ACL hebt op je lan interface dusss...



Is een apipa adres dat vooral gebruikt wordt door Microsoft, IANA is de eigenaar van deze reeks.
Zo zijn er meer reeksen die speciaal zijn zoals ook 1.0.0.0/8

Maar ontopic, de host file van Windows moet je afblijven als je niet weet wat je doet, mocht je daar wel geinteresseerd in zijn kun je erg leuke dingen daarmee doen, onderhoud ervan is wel noodzakelijk als je de hosts file bijvoorbeeld wil gebruiken om spyware of adware te blokkeren. Of
Er zijn op internet genoeg hosts file te vinden die je daarvoor kunt gebruiken, als je je eraan stoort ben je ook af van de meeste banners, addoubleclicks e.d.
Of de phone home appz is ook een leuke zoals Adobe..... 192.168.112.2o7.net
Heel nasty..

Volgens mij zou het invoeren van het hoofd domain (googlesyndication.com) genoeg moeten zijn.
alles wat je hiervoor zet is volgens mij een sub-domain en heeft volgens mij niet zo veel zin om te "blocken".

Nee, dan heb je het niet goed begrepen. DNS is een hiërarchisch systeem dat later is bedacht omdat het -op elke aan Internet gekoppelde host- bijhouden van een hosts file met alle hostname(s) naar adres koppelingen al snel niet erg praktisch bleek.

Volgens jouw theorie zou "127.0.0.1 com" volstaan om geen enkele .com host meer te kunnen bereiken, en dat is echt niet zo (niet getest overigens ;)

PS om het wat verwarrender te maken bestaat er niet zoiets als een FQHN (Fully Qualified Host Name). Ook www.security.nl wordt een FQDN genoemd (waarbij de D voor Domain staat)... (zie http://en.wikipedia.org/wiki/Hostname).