The problem with the spoofer project is that the spoofer test client is most often not testing networks where attackers are sourcing their spoofed traffic from. The client is often run on volunteer’s laptops behind NATs on business or residential networks. I can assure you that spoofing is very much a problem, and the open tunnel vulnerability is going to make it much worse! https://github.com/vanhoefm/tunneltester
On top of implementing SAV wherever possible, you need to be actively looking for spoofed traffic traversing your network and blocking it when you find it. Finding spoofed traffic can be done with netflow and/or ACLs (see Damian Menscher’s NANOG presentation https://youtu.be/q3TpdMZNeHg?t=969) . An easy way to look for this is to find traffic that matches this PCAP filter: ‘ip and udp and (src port 0 or src port 22 or src port 80 or src port 443) and (dst port 17 or dst port 19 or dst port 53 or dst port 69 or dst port 111 or dst port 123 or dst port 137 or dst port 161 or dst port 177 or dst port 389 or dst port 427 or dst port 520 or dst port 523 or dst port 631)’ This looks for invalid traffic with a forged source port of 0,22,80,443 to common ports used for DDoS amplification (port 53 is used the most by attackers). I have an open-source tool called Tattle Tale that will ingest netflow and help identify spoofed DDoS amplification traffic in real-time on your network. https://github.com/racompton/tattle-tale -Rich From: Hank Nussbacher via NANOG <[email protected]> Date: Saturday, April 5, 2025 at 11:05 PM To: [email protected] <[email protected]> Cc: Hank Nussbacher <[email protected]> Subject: [NANOG] Re: How can the IP spoofing problem be solved within a country? On 06/04/2025 1:40, William Herrin via NANOG wrote: Based on the Spoofer project: https://urldefense.com/v3/__https://spoofer.caida.org/country_stats.php__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9DM7O6BQ$<https://urldefense.com/v3/__https:/spoofer.caida.org/country_stats.php__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9DM7O6BQ$> https://urldefense.com/v3/__https://spoofer.caida.org/recent_tests.php?country_include=tur__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk-_Q7mn4A$<https://urldefense.com/v3/__https:/spoofer.caida.org/recent_tests.php?country_include=tur__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk-_Q7mn4A$> the problem is diminishing constantly. Regards, Hank > On Sat, Apr 5, 2025 at 8:07 AM T. Fırıncı via NANOG > <[email protected]> wrote: >> I thought that bcp38 could be a solution, but some people said that >> this solution would create a problem in multihome networks. > Hi Taygun, > > BCP 38 works great on multihomed networks. Where it doesn't work is: > > 1) Large core peering scenarios where an ISP trades routes with > another ISP and has to take that ISP's word for it that the offered > routes are valid. > 2) The customer side of Internet Transit service where the customer > has to take the ISP's word for it that the presented routes are > legitimate. > > What _does not_ work in multihomed networks is Reverse Path Filtering. > You have to explicitly filter the routes and source IP addresses your > customer has authenticated to you. You can't rely on their route > advertisement to tell you what packets are legitimate because BGP > routing tends to be asymmetric: packets in one direction often follow > a different path than packets in the other. Strict RPF breaks > multihoming and loose RPF falls far far short of meeting BCP 38's > filtering requirement. > > >> What is the exact optimum solution? > Depends on your source of authority. If you're constructing a > government mandate then you require anyone selling Internet service in > Turkey to implement BCP 38 on every paid Internet connection. That > means egress filtering everywhere they buy transit or peering service > inside or outside of Turkey and ingress filtering everywhere they sell > Internet service inside and outside of Turkey. And you set large and > escalating fines for every incident where the ISP is found to be in > non-compliance. Then you sit back and let capitalism do what it does > best: optimize for cost. > > If you're talking about voluntary industry action... give up. The > BGPSEC effort fell apart and the people who care about BCP 38 already > implement it. > > Regards, > Bill Herrin > > _______________________________________________ NANOG mailing list https://urldefense.com/v3/__https://lists.nanog.org/archives/list/[email protected]/message/TW3OVQKQOBT774TFRVFV27FDGELLJDJM/__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9jdhy8Gw$<https://urldefense.com/v3/__https:/lists.nanog.org/archives/list/[email protected]/message/TW3OVQKQOBT774TFRVFV27FDGELLJDJM/__;!!CQl3mcHX2A!D1XX16jenk9EjKnal3DcxL-tWND9vKJ0llxv-Eeok2pGlAspWrDz6IokiNhSiHok_QqOjZSDmay6Wk9jdhy8Gw$> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/H22X7IZSZ56YM6AYA64X7WTW5I23EH7L/
