Agentschap Telecom doet aanbevelingen voor beveiligen BGP
Het Agentschap Telecom heeft verschillende aanbevelingen gepubliceerd voor het beveiligen van het Border Gateway Protocol, dat wordt gebruikt om verkeer tussen internetproviders te routeren en essentieel is voor de werking van het internet.
BGP werkt door een tabel van ip-netwerken of 'prefixes' bij te houden die de netwerkbereikbaarheid tussen autonome systemen aangeeft. Dit zijn onafhankelijk beheerde netwerken, bijvoorbeeld van internetproviders. Via BGP wordt de meest efficiënte route gezocht voor het routeren van verkeer.
In het verleden zijn er meerdere incidenten met BGP-hijacking geweest waarbij aanvallers het internetverkeer via hun netwerken weten te routeren en zo kunnen onderscheppen of manipuleren. Aanvallers doen dit door aan te kondigen dat ze eigenaar van bepaalde ip-prefixes zijn, terwijl dit in werkelijkheid niet het geval is.
"Zonder BGP kan er ook geen internet zijn. Beveiliging van dat protocol is dan ook erg belangrijk. Om beheerders van autonome systemen daarbij te helpen hebben we een aantal best practices in een infographic verzameld. Als iedereen die met BGP te maken heeft de best practices volgt beperken we gezamenlijk de risico's", zo laat het Agentschap Telecom vandaag weten.
De aanbevelingen bestaan onder andere uit monitoring, detectie, filtering, gebruik van Resource Public Key Infrastructure (RPKI) en TTL Security. Zo moet RPKI het kapen van routes voorkomen en is TTL Security bedoeld om aanvallen met vervalste ip-pakketten tegen te gaan.
"Organisaties zoals internetproviders en ondernemingen worden aangemoedigd om deze aanbevelingen te implementeren, aangezien ze de security en stabiliteit van het internet verbeteren. Een veerkrachtig internet is essentieel voor het publieke welzijn en economische stabiliteit", stelt het Agentschap Telecom.
TTL bij de peer wel op 1 stond kwamen er allerlei problemen omdat kennelijk niet alle peers in staat waren deze
instelling te doen. Ik ben er eigenlijk nooit achter gekomen of hun routers dat niet konden of dat het de admins waren
die dat niet konden.
Toch maar weer eens proberen aan de orde te stellen...
natuurlijk kun je elk routeringsprotocol voor internet gebruiken, desnoods statische routes.
onhandig, ja, bijna onwerkzaam, ook wel, maar onmogelijk, nee, zeker niet
natuurlijk kun je elk routeringsprotocol voor internet gebruiken, desnoods statische routes.
onhandig, ja, bijna onwerkzaam, ook wel, maar onmogelijk, nee, zeker niet
is die 20 jaar gaat duren als er geen dwang achter zit.
En het zal waarschijnlijk nog best lastig zijn om een geleidelijke overstap te doen waarbij iedereen op een moment dat
em zelf goed uitkomt de overstap maakt...
Daarom worden er steeds pleisters op het bestaande protocol geplakt.
Vergelijk het met het gebruik van SMTP voor mail, daar kom je ook niet meer vanaf en wordt ook vanalles op geplakt
zoals STARTTLS, SPF, DKIM, DMARC enz enz.
TTL bij de peer wel op 1 stond kwamen er allerlei problemen omdat kennelijk niet alle peers in staat waren deze
instelling te doen. Ik ben er eigenlijk nooit achter gekomen of hun routers dat niet konden of dat het de admins waren
die dat niet konden.
Toch maar weer eens proberen aan de orde te stellen...
Liever niet - Je doet juist de verkeerde check .
Lees de RFC over het TTL security mechanisme .
Als ik 10 hops verderop zit, zet ik de TTL op 11, en komt ik bij jouw firewall precies aan met TTL=1 .
https://tools.ietf.org/html/rfc5082
Je wilt de TTL op 255 zetten en daarop controleren omdat alleen een directe peer verkeer met TTL = 255 (of evt 254, als de decrement in het uitgaande interface gedaan wordt) kan afleveren.
Iedere aanvaller die een hop verder zit , komt met een te lage TTL aan.
natuurlijk kun je elk routeringsprotocol voor internet gebruiken, desnoods statische routes.
onhandig, ja, bijna onwerkzaam, ook wel, maar onmogelijk, nee, zeker niet
- Nederland werd in 1982 aangesloten op het internet (CWI)
- In 1993 kwam Internet in Nederland publiekelijk beschikbaar door XS4ALL (ontstaan vanuit Hacktic).
- BGP is in 1994 op het internet in gebruik gekomen.
BGP is dus niet randvoorwaardelijk voor 'het internet'; met de hedendaagse complexiteit en omvang zijn we wel heel afhankelijk van BGP. Maar de stelling: 'zonder BGP geen internet' is inderdaad iets te kort door de bocht.
natuurlijk kun je elk routeringsprotocol voor internet gebruiken, desnoods statische routes.
onhandig, ja, bijna onwerkzaam, ook wel, maar onmogelijk, nee, zeker niet
Geboren pedant ?
Ga maar RSA-2048 op papier doen - en kom niet terug voordat je klaar bent.
natuurlijk kun je elk routeringsprotocol voor internet gebruiken, desnoods statische routes.
TTL bij de peer wel op 1 stond kwamen er allerlei problemen omdat kennelijk niet alle peers in staat waren deze
instelling te doen. Ik ben er eigenlijk nooit achter gekomen of hun routers dat niet konden of dat het de admins waren
die dat niet konden.
Toch maar weer eens proberen aan de orde te stellen...
Liever niet - Je doet juist de verkeerde check .
Lees de RFC over het TTL security mechanisme .
Als ik 10 hops verderop zit, zet ik de TTL op 11, en komt ik bij jouw firewall precies aan met TTL=1 .
https://tools.ietf.org/html/rfc5082
Je wilt de TTL op 255 zetten en daarop controleren omdat alleen een directe peer verkeer met TTL = 255 (of evt 254, als de decrement in het uitgaande interface gedaan wordt) kan afleveren.
Iedere aanvaller die een hop verder zit , komt met een te lage TTL aan.
Dat is een manier. Maar als ik de TTL op 1 zet en jij zit 11 hops weg dan krijg je de SYN ACK niet binnen en komt
er dus nooit een connectie. De check op TTL = 1 is meer om te controleren of jij het aan jouw kant ook wel goed hebt
ingesteld...
En die manier om met 255 te beginnen en dan op 254 te checken is denk ik meer bedacht voor routers waar je de TTL
van BGP verkeer niet kunt instellen.
TTL bij de peer wel op 1 stond kwamen er allerlei problemen omdat kennelijk niet alle peers in staat waren deze
instelling te doen. Ik ben er eigenlijk nooit achter gekomen of hun routers dat niet konden of dat het de admins waren
die dat niet konden.
Toch maar weer eens proberen aan de orde te stellen...
Liever niet - Je doet juist de verkeerde check .
Lees de RFC over het TTL security mechanisme .
Als ik 10 hops verderop zit, zet ik de TTL op 11, en komt ik bij jouw firewall precies aan met TTL=1 .
https://tools.ietf.org/html/rfc5082
Je wilt de TTL op 255 zetten en daarop controleren omdat alleen een directe peer verkeer met TTL = 255 (of evt 254, als de decrement in het uitgaande interface gedaan wordt) kan afleveren.
Iedere aanvaller die een hop verder zit , komt met een te lage TTL aan.
Dat is een manier. Maar als ik de TTL op 1 zet en jij zit 11 hops weg dan krijg je de SYN ACK niet binnen en komt
er dus nooit een connectie. De check op TTL = 1 is meer om te controleren of jij het aan jouw kant ook wel goed hebt
ingesteld...
Default is/was al dat eBGP met TTL=1 naar buiten gaat, zodat je alleen een directly connected peer kunt configureren.
Maar deze thread gaat over BGP _security_ , en daarvoor heeft een TTL=1 check geen waarde.
Er zijn goede redenen waarom je aanvallers ook geen kans wilt geven om one-way verkeer naar je control plane af te leveren.
En die manier om met 255 te beginnen en dan op 254 te checken is denk ik meer bedacht voor routers waar je de TTL
van BGP verkeer niet kunt instellen.
Er zijn/waren platformen waarop de uitgaande lijnkaart een TTL decrement doet van verkeer, ook als het afkomstig van main processor. Dan wel , waar de ontvangende lijnkaart eerst de decrement TTL doet voordat de vergelijking TTL= gedaan wordt .
Dat is de reden waarom je de ontvangende check eventueel op 254 doet en niet op 254 .
Maar voor het doel 'een aanvaller die meer dan één hop weg zit kan nooit matchend verkeer leveren' werkt alleen met de hoogst mogelijke TTL waarde als start.
Default is/was al dat eBGP met TTL=1 naar buiten gaat, zodat je alleen een directly connected peer kunt configureren.
Maar deze thread gaat over BGP _security_ , en daarvoor heeft een TTL=1 check geen waarde.
Er zijn goede redenen waarom je aanvallers ook geen kans wilt geven om one-way verkeer naar je control plane af te leveren.
BGP werkt met TCP. Dat betekent dat er alleen verkeer kan worden afgeleverd als er beide kanten op connectiviteit is.
Met uitgaand verkeer op TTL 1 is dat niet mogelijk als de peer meer dan 1 hop weg zit. Immers die krijgt nooit de SYN ACK.
Er zijn omdat dit een meerledig issue is meerdere zaken die ook moeten gebeuren,
BCP84 en BCP38.
Oftewel antspoofing. Ik snap niet dat daar een supergeleerde, of in dit geval het Agentschap Telecom iets over moet blaten. Dit zijn items die standaard bekend zijn bij netwerkspecialisten. Het wordt tijd dat men luistert naar hun specialisten.
Default is/was al dat eBGP met TTL=1 naar buiten gaat, zodat je alleen een directly connected peer kunt configureren.
Maar deze thread gaat over BGP _security_ , en daarvoor heeft een TTL=1 check geen waarde.
Er zijn goede redenen waarom je aanvallers ook geen kans wilt geven om one-way verkeer naar je control plane af te leveren.
BGP werkt met TCP. Dat betekent dat er alleen verkeer kan worden afgeleverd als er beide kanten op connectiviteit is.
Met uitgaand verkeer op TTL 1 is dat niet mogelijk als de peer meer dan 1 hop weg zit. Immers die krijgt nooit de SYN ACK.
Zuch en zucht. Ik zit hier niet om aanvallers wijs te maken .
Als je iets van doen hebt met internet facing BGP routers - ga leren over router security - en router architectuur. De vendors van die dingen hebben een hoop presentaties.
Denk breder over risico's dan "er is niks aan de hand als er maar geen twee weg verkeer mogelijk is".
Er zijn omdat dit een meerledig issue is meerdere zaken die ook moeten gebeuren,
BCP84 en BCP38.
Oftewel antspoofing. Ik snap niet dat daar een supergeleerde, of in dit geval het Agentschap Telecom iets over moet blaten. Dit zijn items die standaard bekend zijn bij netwerkspecialisten. Het wordt tijd dat men luistert naar hun specialisten.
Yep. Iedere netwerk specialist heeft bcp38 allang goed ingesteld.
https://spoofer.caida.org/country_stats.php
Ip6 draait bij allemaal al jaren, tls1.3 ook iedereen al in orde..mailservers hebben allemaal al láng spf, dkim, dmarc..
Maar inderdaad, niet iedere specialist heeft de ruimte waar die werkt om protocollen uit 1998 uit te faseren.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Medior OT Security Specialist
Samen werken aan een stabiel energie-netwerk en daarmee een mooie bijdrage leveren aan de maatschappij. Daar haal jij veel energie uit als Medior OT Security Specialist! Met jouw expertise draag jij graag bij aan de veilige verduurzaming van Nederland.
Security Architect
Samenwerken aan de veilige verduurzaming van Nederland. Jij bent de security architect die er graag voor zorgt dat oplossingen in de IT en/of OT veilig zijn. De impact die jij samen met jouw collega’s hebt op de digitalisering binnen Alliander is groot. Kunnen wij op jou rekenen?
Senior Security Specialist
Ben je geïnteresseerd in de nieuwste technologieën en wil je werken in een innovatieve omgeving waar je echt kunt bijdragen aan het welzijn van onze klanten, de melkveehouderijen? Jouw kans om te komen werken bij de grootste robotfabrikant van Nederland, het familiebedrijf van het jaar met een hightech campus in Maassluis.