Geen BOGON filter bij Freedom

Is er bij Freedom geen BOGON filter? Ik zie in mijn firewall zo nu en dan connecties die “afkomen van RFC1918 adressen”. Dat had ik bij XS4ALL nooit.
Wordt een ISP niet geacht dat soort ranges te filteren?

Stuur even een mail naar helpdesk@freedomnet.nl met je abonnementsgegevens. Dan kan ik zien op welk access-netwerk je zit en dan verder kijken.

De routers hebben wel degelijk BOGON-filters.

Het komt maar zelden voor, iedere dag zo’n 1 tot 3 packets…
Het zijn TCP connects naar poort 445 en 3306 die binnen komen van diverse RFC1918 adressen…
Ik zit in netwerk 45.83.232.0/22

Ik wil er echt meer van weten. Maar aan de /22 prefix kan ik niet zien op welk access-netwerk je zit:) Alle prefixes worden door elkaar gebruikt op alle access-netwerken.

O bedoel je de techniek? Dat is VDSL.

Naar aanleiding van dit topic heb ik ook eens een tcpdump op m’n ppp interface gestart en zie inderdaad ook af en toe wat binnen komen, wat voorbeelden:

~ # tcpdump -n -i ppp0 net 10.0.0.0/8 or net 192.168.0.0/16 or net 172.16.0.0/12
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
10:22:24.243868 IP 10.86.31.80.50867 > 45.80.x.x.445: Flags [S], seq 3661602943, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
11:03:16.939934 IP 192.168.1.9.49940 > 45.80.x.x.22: Flags [R], seq 3409369708, win 0, length 0

Ik zit ook op VDSL. Mocht dat verschil maken: Dit zijn adressen uit m’n subnet, naar het reguliere vaste IP adres heb ik ze nog niet gezien. Als je wil kan ik de output ook met de volledige IP adressen PM’en of mailen.

Ik zie trouwens ook dat ik zelf af en toe wat FIN/ACK’s zonder NAT het net op gooi, eens kijken hoe ik dat tegen kan gaan :thinking:

Met welk VLAN-tag zie je die pakketen binnenkomen?

Bij mij komen ze binnen op de PPPoE verbinding. Die op zijn beurt weer via VLAN 6 loopt.
(ik heb geen telefoon of TV)

Dat van die niet-geNATte FIN/ACK packets dat is een welbekende en heel oude Linux bug.
De NAT entry wordt meteen weg gemikt bij de eerste FIN/ACK en als de andere kant die niet ontvangt en nog een FIN stuurt dan wordt daarop geantwoord met een niet geNATte FIN/ACK. Jammer maar helaas.

Naar aanleiding van dit topic hier ook de detectie aangezet en had er inderdaad eentje in het log zitten:

Apr/05/2022 09:18:13 Bogon prerouting: in:pppoe (vlan6), proto TCP (SYN), 192.168.0.100:30232->45.138.231.X:5555, len 44

Nieuwe:

Apr/06/2022 05:45:00 Bogon prerouting: in:pppoe:(vlan6), proto TCP (SYN), 172.18.92.42:55128->45.138.231.X:445, len 52

Bedankt voor de info.
Mede hierdoor heb ik inmiddels gevonden hoe ze te filteren zijn. Ik gebruik nu deze nftables rule in een chain gekoppeld aan de forward hook:

ip saddr 192.168.0.0/16 tcp flags fin ct state invalid log prefix "Late FIN: " counter drop
Apr/07/2022 18:17:36 Bogon prerouting: in:pppoe:(vlan6), src-mac 00:30:88:11:7f:c2, proto ICMP (type 11, code 0), 172.19.6.9->188.72.82.46, len 80
Apr/07/2022 21:37:49 Bogon prerouting: in:pppoe:(vlan6), proto TCP (SYN), 10.10.28.105:33995->45.138.231.X:3306, len 48

Company: Ericsson
Range: 00:30:88:00:00:00 - 00:30:88:FF:FF:FF

Het MAC adres is niet zo relevant, dat is het MAC adres van de PPPoE server en die heeft het vast niet zelf gestuurd.

Ik had er niet bij stilgestaan dat het inderdaad de PPPoE server is van Cambrium waar ik mijn PPPoE verbinding mee heb.

Dacht dat het MAC adres ook fake was, dus niet.

Toch wel bekende poorten die anders voorheen bij Xs4all kon laten filteren.

Nog geen verandering.

Hoi

Hier een automagies gegenereerd overzichtje;
http://www.sput.nl/wan-weirdness/
Soms komt er wat ICMP langs en dan kan je zien waar het vandaan komt. Is nu UK maar was eerder India en Bangladesh. Er is onderweg gewoon niemand die die pakketten dropt.
Ik heb er verder geen last van maar het kwam in eerste instantie wel een beetje vreemd over.

Vr.Gr,
Rob

2 likes

Het is hier behoorlijk terug gelopen maar het is nog niet weg. 1 packet op 1 mei en 1 op 2 mei waren de laatsten, een was naar poort 445 en de ander naar poort 23.
Het is niet hinderlijk maar het verbaast me gewoon dat dit soort packets er door komen, ik dacht dat “RFC1918 filteren” wel standaard was bij iedere ISP en backbone provider.

Ik vermoed dat het ‘unknown unicast flooding’ in het, niet onder ons beheer zijnde, access-netwerk betreft. Als dat zo is, dan betreft het hier dus laag-2 (ethernet). BOGON-filters werken op laag-3. Die hebben dus betrekking op het al dan niet routeren van pakketten. Terwijl laag-2 betrekking heeft op het switchen van ethernetframes.

Ethernet-switches moeten nu eenmaal unicast verkeer waarvan een destination MAC-adres niet (meer) bekend is naar alle poorten sturen (flooding). Aan de hand van het source MAC-adres van het terugkerende verkeer leert de switch naar welke poort de volgende frames met die bestemming moeten worden gestuurd. Het verschijnsel dat het steeds maar enkel frame (pakket) betreft komt overeen met dit gedrag.

En nogmaals de routers van Freedom zijn echt voorzien van BOGON-filters.

De pakketjes zijn wel GERICHT aan het IP adres wat ik van Freedom gekregen heb, maar het AFZENDER adres is een RFC1918 adres.
Ik kan me voorstellen dat er wellicht mensen zijn die routers gebruiken waar de NAT wel eens vergeten wordt en er een pakketje naar buiten lekt, maar het is dan wel vreemd dat het SYN pakketjes zijn want die worden meestal wel goed ge-NAT. Er is een bekend probleem met Linux, wat uiteraard vaak gebruikt wordt in routers, dat pakketjes aan het eind van een TCP sessie (FIN ACK, ACK, RST) wel eens buiten de NAT om gaan.
Wat ik ook vreemd vind is dat het source adres vaak “ongebruikelijk voor een home netwerk” is, hier een lijstje van source adressen die ik de afgelopen 2 maanden hier gezien heb:
10.0.5.30
10.0.42.1
10.6.0.4
10.10.10.10
10.10.10.172
10.10.28.105
10.24.0.196
10.25.149.139
10.25.149.140
10.27.1.37
10.71.1.171
10.80.78.67
10.86.7.64
10.110.47.61
10.192.93.60
10.202.132.61
10.250.134.118
172.16.3.62
172.16.12.28
172.16.42.132
172.16.45.3
172.16.109.1
172.17.10.40
172.18.70.4
172.18.140.45
172.18.179.41
172.19.33.73
172.30.50.20
192.168.0.77
192.168.14.124
192.168.15.240
192.168.18.7
192.168.20.17
192.168.20.21
192.168.32.30
192.168.100.4
192.168.181.36
Dat is een dermate “wilde” collectie dat ik niet direct denk aan “bugje in een router van merk X”.
En dit zou dan als ik je goed begrijp allemaal afkomstig moeten zijn van mede-klanten van Freedom.

@arien ,
Ik zag dit topic en heb sindsdien (5 mei) logging aangezet.
Het gebeurt niet veel, maar de poorten en ip-adressen zien er bekend uit.

Datum Interface Source Destination:port Protocol
May 9 14:23:23 WAN 10.10.28.105:8891 185.238.128.xxx:3306 TCP:S
May 6 23:16:53 WAN 192.168.19.1:34394 185.238.128.xxx:445 TCP:S
May 5 14:07:46 WAN 10.12.15.23:64011 185.238.128.xxx:445 TCP:S

De WAN interface vlan 6 met PPPoE.
Heb je interesse in mijn volledige ip adres? Kan dat via een PM of liever via een ticket?

toevoeging: (ik denk niet relevant maar toch)
1)Ik heb dit gedrag eerder met vdsl2 niet waargenomen. Onlangs ben ik overgegaan naar xgs-pon.
2) Sindsdien komt er ook veel igmp? verkeer op de interface (zonder vlan) vanaf het mac adres van de genexis. (naar mijn vermoeden is dit iets anders onverklaarbaar)
3) Packet Capture heb ik aangezet. Met wat geluk loopt deze nog als het weer gebeurt.

1 like