Firewall DoS logs / port_scan

[Gino]

Sinds enkele dagen hebben we volgende soort logs op onze firewall (Vigor2926ac, up-to-date firmware)

Lijkt alsof het verkeer vanuit de google / microsoft komt. Lijkt me raar dat we van die bron port_scans zouden krijgen.

Is dit iets om zorgen over te maken? Wat kunnen we eraan doen?

code:

2023/04/25 17:57:29 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:38699][UDP][HLen=20, TLen=237]
2023/04/25 17:57:34 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:41072][UDP][HLen=20, TLen=237]
2023/04/25 17:57:40 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:60870][UDP][HLen=20, TLen=237]
2023/04/25 17:57:45 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:49476][UDP][HLen=20, TLen=237]
2023/04/25 17:57:52 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:59071][UDP][HLen=20, TLen=268]
2023/04/25 17:58:00 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:35807][UDP][HLen=20, TLen=237]
2023/04/25 17:58:15 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:40567][UDP][HLen=20, TLen=237]
2023/04/25 17:58:30 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:57154][UDP][HLen=20, TLen=237]
....
2023/04/25 20:43:12 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:12 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:14 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63552][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=1278]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=845]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=201]
2023/04/25 20:43:15 -- [DOS][Block][port_scan][142.250.179.138:443->xxx.xxx.xxx.xxx:63042][UDP][HLen=20, TLen=52]
....

2023/04/25 20:38:09 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:09 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:54435][UDP][HLen=20, TLen=155]
2023/04/25 20:38:10 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]
2023/04/25 20:38:10 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=175]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:11 -- [DOS][Block][port_scan][8.8.8.8:53->xxx.xxx.xxx.xxx:33185][UDP][HLen=20, TLen=215]
2023/04/25 20:38:13 -- [DOS][Block][port_scan][195.130.130.3:53->xxx.xxx.xxx.xxx:60303][UDP][HLen=20, TLen=179]

[biomass]

Afgaand op de bron poorten van de UDP datagrammen gaat het om DNS en HTTP/3? Wikipedia: List of TCP and UDP port numbers. Als je externe IP adres ook net een paar dagen oud is, totaal niets om zorgen over te maken.

[Gino]

Het is een vast IP wat op xxx.xxx.xxx.xxx staat. Heb het daarom ook weggehaald.

[EricJH]

Het kan ook komen door een vertraagde response van de server en dat de Stateful Inspection van de firewall het pakket niet meer ziet als zijnde een antwoord op een vraag van je pc en dus ziet als ongevraagde toegang.

[Kabouterplop01]

wellicht omdat het UDP is denk ik dat het allemaal gespoofde pakketjes zijn. Op het moment dat je besluit dat die pakketjes niet gedropped hoeven te worden doe je vrolijk mee aan een DDoS op de echte IP adressen.
Het zijn er gelukkig niet heel veel anders zou je er last van krijgen.
Goed dat je ze blokkeert. \o/

[Gino]

Als ze gespoofd zouden zijn kunnen we dan op de een of andere manier de echt afzender vinden, zodat we die op de firewall kunnen bannen?

[LanTao]

Dit zijn geen portscans, dit zijn allemaal valse alarmen omdat de IDS niet voldoende state kan bijhouden en dus niet doorheeft dat dit antwoorden zijn op eerder van binnenuit opgezette verbindingen (cq 'verbindingen' voor de DNS requests), of het eerste uitgaande packet niet als zodanig herkende. Wat @EricJH al zei, maar dan met zekerheid.

De packets zijn niet gespoofd want dergelijke packets spoofen op een dergelijke rate heeft nul kans van slagen voor bijv. DNS cache poisoning. En hoe dacht je de dat het bannen van de aanstichter gaat werken tegen spoofed packets?

Doe jezelf een lol en zet al deze fearmongering logging uit. Als ik een euro zou hebben gekregen van iedereen die me "Why are you scanning my ports?" mailde of zelfs opbelde naar aanleiding van dergelijke logs, dan was ik rijk geweest.

[Kabouterplop01]

LanTao schreef op donderdag 27 april 2023 @ 01:32:

De packets zijn niet gespoofd want dergelijke packets spoofen op een dergelijke rate heeft nul kans van slagen voor bijv. DNS cache poisoning. En hoe dacht je de dat het bannen van de aanstichter gaat werken tegen spoofed packets?

Weet je hoeveel van dit soort dingetjes er over het internet gaan? Met 100k machientjes te gelijk, dan is er genoeg packetrate. We hebben het helemaal niet over DNS cache poisoning, maar over amplifications, kleine vraag groot antwoord, met als doel de internet verbinding dichtdrukken.

@TS, je kunt de aanstichter van spoofed packets niet aanpakken, je kunt niet zien waar ze vandaan komen. De ISP's die het toelaten moeten worden aangepakt. Ze moeten eigenlijk wat policies op hun core routers (BCP38/84 ingress filtering) implementeren.

[LanTao]

Kabouterplop01 schreef op donderdag 27 april 2023 @ 08:07:
Weet je hoeveel van dit soort dingetjes er over het internet gaan? Met 100k machientjes te gelijk, dan is er genoeg packetrate. We hebben het helemaal niet over DNS cache poisoning, maar over amplifications, kleine vraag groot antwoord, met als doel de internet verbinding dichtdrukken.

Als dit 'n amplification attack gericht op 8.8.8.8 was geweest dan was de destination port niet 'n random oplopende geweest.

Voor de gein heb ik 'n paar uur lang alle packets van/naar 8.8.8.8 hier geteld: nul. Dus de kans is klein dat dit spoofed traffic onderdeel van 'n DDoS was.

[Kabouterplop01]

LanTao schreef op vrijdag 28 april 2023 @ 01:37:
[...]

Als dit 'n amplification attack gericht op 8.8.8.8 was geweest dan was de destination port niet 'n random oplopende geweest.

Het suggereert DNS en/of HTTPS als elke socket terug streamt naar de src_port...
Waarom denk je dat er UDP wordt gebruikt? Het is echt geen portscan van google. (Of Telenet, waar ik denk dat het issue speelde, ik heb even zitten snorren in mijn logging en ik zie het ook niet. (De logging die ik heb is van ISP Ziggo) Dus ik denk dat @Gino Telenet als provider heeft. [Maar dat is een aanname])
195.130.130.3=telenet, de andere IP adressen zijn van Google.)

Voor de gein heb ik 'n paar uur lang alle packets van/naar 8.8.8.8 hier geteld: nul. Dus de kans is klein dat dit spoofed traffic onderdeel van 'n DDoS was.

Dat versterkt mijn eerdere gedachte.

trouwens een IDS houdt geen states bij, dat doet een firewall, of een router. (met een sessie tabel) Hier is er niet eens sprake van een state.

Overigens ik kan het helemaal fout hebben he want we kunnen niet verder kijken dan die 15 log regeltjes van de TS, maar gezien m'n ervaring in deze materie denk ik dat het zo is.