[members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Previous message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Next message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Benedikt Neuffer
ripe.discuss at itfriend.de
Fri May 1 09:32:00 CEST 2020
Hi Elad, in Germany we have an phrase that reads as follows: "The opposite of well is well-meaning." Regards, Bene On 01.05.20 00:18, Elad Cohen wrote: > I'm only trying to help. > > Respectfully, > Elad > ------------------------------------------------------------------------ > *From:* Wesley Berendsen | GXW.nl <wesley at gxw.nl> > *Sent:* Friday, May 1, 2020 1:16 AM > *To:* Elad Cohen <elad at netstyle.io> > *Cc:* members-discuss at ripe.net <members-discuss at ripe.net> > *Subject:* Re: [members-discuss] Technical solution to resolve Spoofed > IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT > botnet infections and Botnet C&Cs > > Omfg here we go again with the spam and “technical solutions” just leave > it already! > > > -- > > Met Vriendelijke Groet, > > Wesley Berendsen > -verstuurd vanaf mijn iPhone- > > >> Op 30 apr. 2020 om 22:32 heeft Elad Cohen <elad at netstyle.io> het >> volgende geschreven: >> >> >> Hello Ripe Members! >> >> I will share the following solution in the near General Meeting and >> I'm interested to share the following technical solution with you as >> well, it will completely resolve: Spoofed IP traffic, Spoofed >> amplification DDoS attacks, BGP&RIR hijacking. And will dramatically >> lower: IoT botnet infections and Botnet C&Cs. >> >> By a single update to any BGP router, not any router needs to be >> updated, only active BGP routers. If I will have the honor of being >> elected to the Ripe Board I will harness all the power of Ripe and all >> of the 5 RIR's and all of the LIR's in the 5 RIR's so routing >> manufacturing companies will implement the below processes and methods >> with a single firmware update to their BGP routers. >> >> I'm asking for your support in electing me so I will be able to enter >> the Ripe Board and then I will be able to make everything which is >> written in this post to come true. >> >> >> Regarding the bgp-anycasted infrastructure written below, ICANN is >> written but the global bgp-anycasted infrastructure can be managed by >> the 5 RIR's and/or by the ccTLDs registries (my main point is that who >> will operate the bgp-anycasted infrastructure is not important for >> now, as long as it will be an agreed authoritative non-governmental >> non-commercial global entity/ies) >> >> With new tracking protocol over ip, routers will be able to confirm >> that source ip came from the network of the announcing ASN, and hence >> spoofed amplification DDoS attacks will be completely annihilated. >> >> >> The Process: >> >> At the source BGP router, for any ip packet with a source address that >> is from the network of the source BGP router (lets call it original ip >> packet) - the source BGP router will create a new ip packet (lets call >> it tracking ip packet) with a new transport layer protocol and with >> the same source address and with the same destination address and with >> the same IP-ID such as the original ip packet. >> >> In the new tracking ip packet there will be a new transport layer >> protocol (tracking protocol) with the following fields: >> AS number of source BGP router in clear text >> AS number of source BGP router encrypted with the private key of the >> source BGP router >> >> The destination BGP router (a BGP router that the destination address >> is in its network) whenever it receive a 'tracking ip packet' will >> check if its have the internal boolean 'Check tracking flag' in it - >> 'on' or 'off': >> If 'off' then the destination BGP router will drop that 'tracking ip >> packet' >> >> If 'on' then the destination BGP router will decrypt the 'encrypted AS >> number' with the public key of the specific AS number >> and after decryption the AS number need to be the result: >> if not then to drop the tracking ip packet and the original ip packet >> related to it >> if yes then to drop the tracking ip packet and to forward the related >> original ip packet to destination but only if the source address is >> originated from the specific ASN (according to the local ASNs+ranges >> table in the BGP router, such table will be received from ICANN) >> >> >> If the 'Check tracking flag' is set to 'on' then any original ip >> packet that arrive to the destination BGP router will wait for the >> related tracking ip packet (in case the related tracking ip packet >> didn't already arrived to the destination BGP router). The destination >> BGP router will manage such waiting for X number of seconds. >> >> The destination BGP router will match between a tracking ip packet and >> an original ip packet - based on their source address and their >> destination address and their IP-ID which will all be identical. >> >> >> >> More Aspects: >> >> - The end-devices will not need to be updated, any router will not >> need to be updated, only all the BGP routers will need to be updated. >> - Any BGP router in the routing path, which the original ip packet and >> the tracking ip packet are not destined to an ip address in its own >> network - will not check the content of the tracking ip packet and >> will forward both the tracking ip packet and the original ip packet as >> they are. >> - Each BGP router will have all the public keys (of all the ASN's) >> locally. >> - Each BGP router will have a full list of all the ASN's and all the >> route objects ranges which are related to them locally. >> >> >> >> How BGP routers will receive all the ranges in all the route objects >> of all the ASNs (in the 5 RIRs) and all the public keys of all the >> ASNs (for decrypting the encrypted strings in 'tracking ip packets'): >> >> - Each BGP router will create a tcp session with ICANN backend >> infrastructure (the backend infrastructure of ICANN will use BGP >> anycast and will be available from many locations worldwide with >> automatic syncing) >> - At this stage there will be a handshake process between the BGP >> router and the ICANN backend infrastructure in order for ICANN to know >> the correct ASN which is operating the BGP router - the BGP router >> will send its ASN in cleartext and also its ASN encrypted with its >> ICANN-communication-private-key , ICANN will know the related public >> key for the specific ASN from the specific ASN object in the RIR (the >> public key for communication with ICANN will be displayed there) - >> after decryption ICANN will compare the decrypted string to the AS >> Number for successful authentication. >> - After successful authentication, all the communication will be >> encrypted, ICANN will notify the BGP router about its public key and >> ICANN will use the public key of the ASN for the communication with >> ICANN - from the ASN object in the RIR. >> - The BGP router will send over the session its public key to be used >> by other BGP routers in order to decrypt the encrypted string in the >> tracking ip packets that it will originate (that private key and >> public key will be managed in the BGP router GUI or CLI). >> - ICANN will notify all the other BGP routers through the sessions >> with them about a newly updated such public key of any other BGP router. >> - ICANN will also receive in real-time any route object >> creation/modification/deletion notification from any of the 5 RIRs and >> will then update all the BGP routers through all of their sessions. >> >> - In case a BGP router doesn't have an active session to ICANN backend >> infrastructure (for any reason, might be due to networking issue) - >> then temporarily the internal 'Check tracking flag' of it will be set >> to 'off'. After the session with ICANN backend infrastructure will be >> re-established and the BGP router will receive all the meantime >> updates - the boolean value of 'Check internal flag' will return to >> initial state. >> - Any update from ICANN backend infrastructure to a BGP router (such >> as a public key of another BGP router, or a routing object update) - >> will be confirmed that the update was received well by the BGP router >> side. >> >> >> >> 'Check tracking flag' in BGP Routers: >> >> - BGP routers, in their GUI and CLI interfaces - will not allow the >> end-user to set the boolean value of 'Check tracking flag', in order >> to avoid misconfiguration. >> - The ICANN backend infrastructure through the session with the BGP >> router - will be able to set the boolean value of the 'Check tracking >> flag'. >> - The reason for it, is that if 'Check tracking flag' will be set on >> some destination BGP routers while some other source BGP routers >> weren't upgraded yet (and will not send the 'tracking ip packet' due >> to it) - then 'tracking ip packet' will never reach the destination >> BGP router and the internet will break. >> - Central setting of 'Check tracking flag' through ICANN backend >> infrastructure - will allow ICANN to inform all the BGP routers at >> once to switch 'on' the 'Check tracking flag' >> - ICANN, in the session to any BGP router, will also receive the >> percentage of ip packets that were destained to that BGP router >> network - that also had ip tracking packets, in this way ICANN will >> know when all the BGP routers were properly globally updated and when >> it is time to enable the 'Check tracking flag' in all the BGP routers. >> - ICANN will know if all the BGP routers in the world were upgraded >> based on keeping the full BGP table and comparing it to all the BGP >> routers that did and that did not open a session to ICANN backend >> infrastructure. >> >> >> >> Automatic preventation of IoT botnet infections: >> >> - IoT botnets are based on default credentials, if we can block >> default credentials of IoT devices then these kind of botnets (such as >> Mirai-variants and similar) will stop to have an impact in the internet. >> - The data field in an ip packet - will always be the same for an >> access attempt to a IoT device with default credentials - hence these >> kind of "IP protocol data fingerprints" which are related to specific >> "IP protocol numbers" will be provided by ICANN backend infrastructure >> to each BGP router through the opened session with it. >> - There are two issues with matching incoming ip packets to the >> "locally stored IP protocol data fingerprints" - the first one is that >> ip packets can be sent by fragments (so not all the data field will be >> sent at once in order to be able to be compared with the locally >> stored data fingerprints) and the second is that usernames (or url's) >> or any other textual data in the incoming ip packet data field can be >> in uppercase or in lowercase. In order to overcome the possibility of >> the existence of a single data fingerprint in multiple incoming ip >> packet fragments - then in case the BGP router is recognizing the >> incoming fragmented ip packet data value as part of an existing >> fingerprint data in its local database then it will keep track of the >> arrival ip packet fragments based on their specific IP-ID identifier >> and the BGP router will not forward the last ip packet fragment if the >> last ip packet fragment will cause all the related ip packet fragments >> to match a specific ip fingerprint data (last ip packet doesn't have >> to be the last fragmented part but it is the last ip packet that >> arrived with that IP-ID identifier, so the BGP router will keep track >> of the specific fragmented IP packets that arrived and their indexes >> in order to know when the last one of them arrived). Regarding the >> second issue - the stored data fingerprints in the local BGP router >> will be stored in a way that some bytes of them (in specific indexes) >> will not be compared and in case all the other bytes will match - then >> the bytes in these indexes - will first be lowered case - and only >> then comparison will be made to the specific indexed bytes in the >> specific ip packet data fingerprint. >> - In case a IoT device behind a BGP router will be infected somehow >> (for example when a specific fingerprint data with default credentials >> for a specific device wasn't updated yet through ICANN backend >> infrastructure), it will be able to infect all the other IoT devices >> in the local network when the connectivity to them is not through the >> BGP router, that kind of impact will be much much lower than infected >> IoT device which can infect any other IoT device in the internet and >> then massive botnets in the internet are created which are being used >> for DDoS. >> >> >> >> Automatic prevention of botnet C&C ip addresses: >> >> - Botnets C&C are also a problem in the internet. >> - This problem can be overcome using the following technical addition: >> the 5 RIR's will operate end-users honeypots machines all over the >> world (it will be implemented by a single physical machine in each >> location, for example in each datacenter and in each major ISP, each >> single physical machine will emulate a virtual router and virtual >> VM's, the virtual VM's will emulate many different kinds of 'real >> world machines', any kind of automatic updating (in the operating >> system configurations) will be disabled, these honeypots machines are >> not intended to make any outgoing connection, the virtual routers will >> monitor if any outgoing connection is made and if yes then it is to a >> botnet C&C, the virtual router will update the ICANN backend >> infrastructure regarding it and the ICANN backend infrastructure will >> update all the BGP routers (in their open sessions) regarding it to >> completely block any communication to that botnet C&C ip address. >> There will be a web-based system and only the related Law Enforcement >> Agency of that C&C ip address region - will be able to remove that C&C >> ip address from being blocked after their manual check. >> - Honeypot machines will be deployed using 'templates' - these >> templates must be signed and not anyone can create them, they should >> be created and signed by an agreed Law Enforcement Agency such as >> Interpol in order to make sure that these templates are by-design not >> making any outgoing connection. The templates will be deployed in an >> automatic way (major ISP's and datacenters will be able to easily add >> a 'physical honeypot' server in their network, that will be shipped to >> them), the re-initiation of a compromised 'virtual machine' that made >> an outgoing connection - will also be automatic through the system in >> the physical server. >> >> >> Respectfully, >> Elad >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://lists.ripe.net/mailman/listinfo/members-discuss >> Unsubscribe: >> https://lists.ripe.net/mailman/options/members-discuss/wesley%40gxw.nl > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe.discuss%40itfriend.de >
- Previous message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
- Next message (by thread): [members-discuss] Technical solution to resolve Spoofed IP traffic, Spoofed amplification DDoS attacks, BGP&RIR hijacking, IoT botnet infections and Botnet C&Cs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]