Onderwerp: ADSL en IP spoofing

Hallo, ik ben een beetje met raw sockets bezig dus ook even kijken
of packets met een spoofed ip wel geroute worden.

Nou heb ik 2 dial-up accounts bij verschillende providers en een adsl
account bij wanadoo , met beide dial-up accounts worden packets
gewoon geroute mits de source ip uit hetzelfde blok (zoals bekend bij
ripe) als mijn echte ip komt. Maar bij mijn adsl account worden alléén
packets met mijn echte ip geroute.

Nou mijn vraag is wie gooit mijn packets weg ?
Is dat kpn en heeft dus iedereen die adsl via kpn heeft daar last van,
of is het wanadoo die ze weg gooit en zijn andere isp's niet zo strict hierin ?

Henkie

Henkie wrote:
> Hallo, ik ben een beetje met raw sockets bezig dus ook even kijken
> of packets met een spoofed ip wel geroute worden.
>
> Nou heb ik 2 dial-up accounts bij verschillende providers en een adsl
> account bij wanadoo , met beide dial-up accounts worden packets
> gewoon geroute mits de source ip uit hetzelfde blok (zoals bekend bij
> ripe) als mijn echte ip komt. Maar bij mijn adsl account worden alléén
> packets met mijn echte ip geroute.
>
> Nou mijn vraag is wie gooit mijn packets weg ?

Ik vermoed zelf KPN.

> Is dat kpn en heeft dus iedereen die adsl via kpn heeft daar last van,
> of is het wanadoo die ze weg gooit en zijn andere isp's niet zo strict hierin ?

Geen idee, nog nooit geprobeerd.

> Henkie



Igmar

On Thu, 14 Aug 2003 05:42:56 +0200, Henkie <henkie@nospam.invalid> wrote:

> Nou heb ik 2 dial-up accounts bij verschillende providers en een adsl
> account bij wanadoo , met beide dial-up accounts worden packets
> gewoon geroute mits de source ip uit hetzelfde blok (zoals bekend bij
> ripe) als mijn echte ip komt. Maar bij mijn adsl account worden alléén
> packets met mijn echte ip geroute.
>
> Nou mijn vraag is wie gooit mijn packets weg ?
> Is dat kpn en heeft dus iedereen die adsl via kpn heeft daar last van,
> of is het wanadoo die ze weg gooit en zijn andere isp's niet zo strict hierin ?

Bij DSL is het KPN (of de l1 DSL provider). De apparatuur waar jouw DSL
lijntje aan hangt kijkt mee met de authenticatie en weet zodoende welke
IP range wel en niet naar jou d-sletje mag.

--
Sabri Berisha "I route, therefore you are"

"Wij doen niet aan default gateways" - anonymous engineer bij een DSL klant.

Henkie wrote:

> Nou mijn vraag is wie gooit mijn packets weg ?

Een beetje ISP (en ik eis dat van alle toko's waar ik zaken mee moet/wil
doen) heeft Network Ingress Filtering volgens RFC 2827 toegepast.

zie http://www.ietf.org/rfc/rfc2827.txt?number=2827

CU,
Harro

On Thu, 14 Aug 2003 10:38:44 +0200, Harro Verton
<none.of.your.bussiness@dont.mail.me> wrote:

>> Nou mijn vraag is wie gooit mijn packets weg ?
>
>Een beetje ISP (en ik eis dat van alle toko's waar ik zaken mee moet/wil
>doen) heeft Network Ingress Filtering volgens RFC 2827 toegepast.

Maar dat voorkomt niet het spoofen van adressen uit het netwerk van die
toko.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ

On Thu, 14 Aug 2003 08:54:20 +0200, Igmar Palsenberg
<news-harvested@al-sahhaf.nl> wrote:

>> Nou heb ik 2 dial-up accounts bij verschillende providers en een adsl
>> account bij wanadoo , met beide dial-up accounts worden packets
>> gewoon geroute mits de source ip uit hetzelfde blok (zoals bekend bij
>> ripe) als mijn echte ip komt. Maar bij mijn adsl account worden alléén
>> packets met mijn echte ip geroute.
>>
>> Nou mijn vraag is wie gooit mijn packets weg ?
>
>Ik vermoed zelf KPN.

Dat doet KPN zelfs met alle pakketjes van bepaalde legitiem uitgereikte
IP-adressen als dat IP-adres hen niet uitkomt.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ

begin _quotations from: Peter Peters <P.G.M.Peters@nospam.utwente.net>:

> Maar dat voorkomt niet het spoofen van adressen uit het netwerk van die
> toko.

In geval van DSL heb je nog een ander verschijnsel. Omdat het onderliggende
netwerk geen switched ethernet maar gerouteerd ATM is, zal een gespoofed IP
niet werken, tenzij er expliciet een route gezet is in de ATM-laag. Het
DHCP-request of de PPP-login wordt door de ATM-laag gebruikt om die route te
zetten. Hoe het met KPN zit weet ik niet, maar op het BBNed-netwerk werkt
een 'extra' addressje aan je nic binden niet. Pas na een DHCP-request/reply
of een succesvolle PPP-login (waarbij je je anonimiteit verliest) gaat er
iets werken. Zowiezo worden er ATM-parameters ('option 82') meegegeven,
waardoor de fysieke lijn te traceren valt.

--
Ruben

Maar het schijnt dat je tegenwoordig onder het mom van individualisme en
vrijheid elke vorm van onbeschoftheid mag toepassen. En niet alleen op
internet."
johns in nl.verkeer

On Thu, 14 Aug 2003 12:45:59 +0000 (UTC), Ruben van der Leij
<ruben-news@nutz.nl> wrote:

>> Maar dat voorkomt niet het spoofen van adressen uit het netwerk van die
>> toko.
>
>In geval van DSL heb je nog een ander verschijnsel. Omdat het onderliggende
>netwerk geen switched ethernet maar gerouteerd ATM is, zal een gespoofed IP

Je kunt ook een switch DSL netwerk aanleggen.

>zal een gespoofed IP
>niet werken, tenzij er expliciet een route gezet is in de ATM-laag. Het
>DHCP-request of de PPP-login wordt door de ATM-laag gebruikt om die route te
>zetten. Hoe het met KPN zit weet ik niet, maar op het BBNed-netwerk werkt
>een 'extra' addressje aan je nic binden niet.

Laat ik het nu juist wel werkend hebben gezien in een BBned netwerk.
Epacity van KPN blijkt het niet te kunnen. Maar daar kun je ook geen
x.x.x.255 o.i.d. gebruiken.

>Pas na een DHCP-request/reply
>of een succesvolle PPP-login (waarbij je je anonimiteit verliest) gaat er
>iets werken. Zowiezo worden er ATM-parameters ('option 82') meegegeven,
>waardoor de fysieke lijn te traceren valt.

Bij de DHCP, maar je kunt (ook bij BBned) volledig met vaste adressen
werken. Een en ander is afhankelijk hoe je het in de ATM switch
termineert.

--
Peter Peters, senior netwerkbeheerder
Dienst Informatietechnologie, Bibliotheek en Educatie (ITBE)
Universiteit Twente, Postbus 217, 7500 AE Enschede
telefoon: 053 - 489 2301, fax: 053 - 489 2383, http://www.utwente.nl/civ

In article <slrnbjn147.mlo.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>begin _quotations from: Peter Peters <P.G.M.Peters@nospam.utwente.net>:
>
>> Maar dat voorkomt niet het spoofen van adressen uit het netwerk van die
>> toko.
>
>In geval van DSL heb je nog een ander verschijnsel. Omdat het onderliggende
>netwerk geen switched ethernet maar gerouteerd ATM is, zal een gespoofed IP
>niet werken, tenzij er expliciet een route gezet is in de ATM-laag.

Het lijkt me dat als je ethernet bridging gebruikt (RFC-1483/RFC-2684) en
verder niets filtert, alle trucs op een ADSL subnet werken die ook op een
bridged ethernet werken.




Philip Homburg

begin _quotations from: Philip Homburg <philip@pch.home.cs.vu.nl>:

>>netwerk geen switched ethernet maar gerouteerd ATM is, zal een gespoofed IP
>>niet werken, tenzij er expliciet een route gezet is in de ATM-laag.

> Het lijkt me dat als je ethernet bridging gebruikt (RFC-1483/RFC-2684) en
> verder niets filtert, alle trucs op een ADSL subnet werken die ook op een
> bridged ethernet werken.

Dan laten we het even zien. Ik heb nu 217.19.20.242 via DHCP als geldige
lease. Ik voeg 217.19.20.243 toe:

# ifconfig eth0:0 217.19.20.243 netmask 255.255.254.0

check:

eth0 Link encap:Ethernet HWaddr 00:A0:C9:EF:19:13
inet addr:217.19.20.242 Bcast:217.19.21.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

eth0:0 Link encap:Ethernet HWaddr 00:A0:C9:EF:19:13
inet addr:217.19.20.243 Bcast:217.19.20.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1


Eens?

Nu een traceroute er naar toe:

$ /usr/sbin/traceroute 217.19.20.243
[..]
4 217.19.16.35 2.665 ms 3.288 ms 4.347 ms
5 213.239.156.42 2.263 ms 1.785 ms 3.004 ms
6 217.19.16.35 5.166 ms 8.619 ms 6.780 ms
7 213.239.156.42 2.247 ms 3.217 ms 2.332 ms
8 217.19.16.35 7.685 ms 5.260 ms 7.301 ms
etc. De resterende 22 mag je zelf inkleuren.

Of een traceroute er vanaf:

# /usr/sbin/traceroute -s 217.19.20.243 213.239.176.42
traceroute to 213.239.176.42 (213.239.176.42) from 217.19.20.243, 30 hops
max, 38 byte packets
1 * * *
2 * * *
etc. De resterende 28 mag je zelf inkleuren.

Da's geen route-probleem:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
217.19.20.0 * 255.255.254.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 217-19-20-1.dsl 0.0.0.0 UG 0 0 0 eth0

En geen iptables-probleem:

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
142 46576 ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68
7654 2527K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
952 194K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
3505K 1832M fw2net all -- * eth0 0.0.0.0/0 0.0.0.0/0
1691K 1601M fw2masq all -- * eth1 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0

Geen rejects in de chain OUTPUT, dus ze zijn de draad opgegaan.

Geloof je me nu? (En jij ook, Peter?)


--
Ruben

Maar het schijnt dat je tegenwoordig onder het mom van individualisme en
vrijheid elke vorm van onbeschoftheid mag toepassen. En niet alleen op
internet."
johns in nl.verkeer

In article <slrnbjn98p.t31.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>begin _quotations from: Philip Homburg <philip@pch.home.cs.vu.nl>:
>
>>>netwerk geen switched ethernet maar gerouteerd ATM is, zal een gespoofed IP
>>>niet werken, tenzij er expliciet een route gezet is in de ATM-laag.
>
>> Het lijkt me dat als je ethernet bridging gebruikt (RFC-1483/RFC-2684) en
>> verder niets filtert, alle trucs op een ADSL subnet werken die ook op een
>> bridged ethernet werken.
>
>Dan laten we het even zien.
>lease. Ik voeg 217.19.20.243 toe:
>
># ifconfig eth0:0 217.19.20.243 netmask 255.255.254.0
>
>check:
>
>eth0:0 Link encap:Ethernet HWaddr 00:A0:C9:EF:19:13
> inet addr:217.19.20.243 Bcast:217.19.20.255 Mask:255.255.254.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>
>
>Eens?

Ik zie nog niets over RFC-1483. Ik kan hetzelfde laten zien bij een
gebruik van 'SIP_SPOOF' (die is het geloof ik).

>Geen rejects in de chain OUTPUT, dus ze zijn de draad opgegaan.

En wat zegt dit over eventuele filtering in de ethernet switch die achter
de DSLAM/access concentrator hangt? Misschien is het helemaal geen
gebridged ethernet.




Philip Homburg

On Thu, 14 Aug 2003 15:04:58 +0000 (UTC),
Ruben van der Leij <ruben-news@nutz.nl> wrote:
> Geen rejects in de chain OUTPUT, dus ze zijn de draad opgegaan.
>
> Geloof je me nu? (En jij ook, Peter?)

Misschien ten overvloede, 'wij' (Cistron) nemen bbned dsl af op ATM. Op
de ATM->IP switch wordt aan 'n specifieke fiber/vci/vpi combinatie 'n
specifiek IP geknoopt. Andere IP's komen er dan ook gewoon niet
doorheen; die hebben alleen toegang vanaf *dat* framed IP address (of 'n
IP in een eventuele framed route). Da's heel simpel te doen ook,
trouwens.

Groetjes,
Robert
--
/^"- '-(\__/)-' -"^\
'-.' oo '.-' Holy Jesus! What are these goddamn animals?!
`-..-'
Finger rvdm@db.debian.org for my GPG key.

begin _quotations from: Philip Homburg <philip@pch.home.cs.vu.nl>:

>>lease. Ik voeg 217.19.20.243 toe:
^^^^^

> Ik zie nog niets over RFC-1483. Ik kan hetzelfde laten zien bij een
> gebruik van 'SIP_SPOOF' (die is het geloof ik).

De RFC-1483 zit in mijn 'modem' (technisch correcter: bridge.
ATM/Ethernet-bridge.) dus hoe wil je die zien op een linux-doos?

>>Geen rejects in de chain OUTPUT, dus ze zijn de draad opgegaan.

> En wat zegt dit over eventuele filtering in de ethernet switch die achter
> de DSLAM/access concentrator hangt? Misschien is het helemaal geen
> gebridged ethernet.

Ik liet je zien dat in het stukje ethernet waar ik zelf controle over heb
niet gefilterd wordt. Ik kan je laten zien dat als ik een DHCP-request doe
ik wel packets met dezelfde source en destination over hetzelfde pad krijg.
Filters zijn er dus niet. Of je moet denken dat iedere keer dat iemand een
DHCP/PPP doet de access-list van een Cisco herschreven wordt? Da's een leuke
manier om die 7500's bezig te houden.

Wat is het probleem met me gewoon geloven trouwens? Ik geef je een perfect
plausibele en testbare verklaring, met deel 1 van het experiment
gedocumenteerd, en jij komt met iets wat op z'n minst onwaarschijnlijk is.

$ cat /var/log/messages | grep "Aug 11" | grep DHCPACK | wc -l
26419

Jouw plannetje zou op 26419 nieuwe access-lists per dag uitkomen. Meer dan
1000 per uur. Iedere 3 seconden een ander. Beetje onwaarschijnlijk, dat zul
je met me eens zijn. Hoop ik.

--
Ruben

Maar het schijnt dat je tegenwoordig onder het mom van individualisme en
vrijheid elke vorm van onbeschoftheid mag toepassen. En niet alleen op
internet."
johns in nl.verkeer

In article <slrnbjnrjr.3kd.ruben-news@its.blacklisted.nl>,
Ruben van der Leij <ruben-news@nutz.nl> wrote:
>begin _quotations from: Philip Homburg <philip@pch.home.cs.vu.nl>:
>
>>>lease. Ik voeg 217.19.20.243 toe:
> ^^^^^
>
>> Ik zie nog niets over RFC-1483. Ik kan hetzelfde laten zien bij een
>> gebruik van 'SIP_SPOOF' (die is het geloof ik).
>
>De RFC-1483 zit in mijn 'modem' (technisch correcter: bridge.
>ATM/Ethernet-bridge.) dus hoe wil je die zien op een linux-doos?

Als je wat wilt laten zien, dan laat je ook de configuratie van het
'modem' zien.

>Ik liet je zien dat in het stukje ethernet waar ik zelf controle over heb
>niet gefilterd wordt. Ik kan je laten zien dat als ik een DHCP-request doe
>ik wel packets met dezelfde source en destination over hetzelfde pad krijg.
>Filters zijn er dus niet. Of je moet denken dat iedere keer dat iemand een
>DHCP/PPP doet de access-list van een Cisco herschreven wordt? Da's een leuke
>manier om die 7500's bezig te houden.

Als je een statisch IP adres hebt, waarom zou je dan de access-list van die
Cisco herschrijven?

>Wat is het probleem met me gewoon geloven trouwens? Ik geef je een perfect
>plausibele en testbare verklaring, met deel 1 van het experiment
>gedocumenteerd, en jij komt met iets wat op z'n minst onwaarschijnlijk is.

Hoe bedoel je? Als in een RFC een standaard voor ethernet bridging over
ATM netwerken beschreven staat, dan is het wel zo handig als dat ook
geimplementeerd wordt. Stel je wilt als bedrijf een VPN opzetten (inclusief
broadcasts), je koopt wat poorten in op DSLAMs, laat dat af leveren als
ATM, en je zet dat om naar ethernet. Dan zou het toch jammer zijn als iemand
gedacht heeft 'ADSL wordt alleen voor internet gebruikt, dus kunnen we
die ethernet broad- en multicasts wel weglaten.'

>$ cat /var/log/messages | grep "Aug 11" | grep DHCPACK | wc -l
> 26419
>
>Jouw plannetje zou op 26419 nieuwe access-lists per dag uitkomen. Meer dan
>1000 per uur. Iedere 3 seconden een ander. Beetje onwaarschijnlijk, dat zul
>je met me eens zijn. Hoop ik.

Zou dat 26419 nieuwe access lists opleveren?




Philip Homburg

begin _quotations from: Philip Homburg <philip@pch.home.cs.vu.nl>:

> Als je wat wilt laten zien, dan laat je ook de configuratie van het
> 'modem' zien.

Je toon staat me niet aan. Laatste reactie, derhalve. Ik probeer jou en
anderen uit te leggen waarom het doet wat het doet. Als jij daar een
pissing-contest in ziet: prima. Je hebt gewonnen. Veel plezier met je
overwinning.

--
Ruben

Maar het schijnt dat je tegenwoordig onder het mom van individualisme en
vrijheid elke vorm van onbeschoftheid mag toepassen. En niet alleen op
internet."
johns in nl.verkeer