Hi @h134352RET, 

Deze meldingen komen omdat iets of iemand je modem bestookt met data om te proberen deze offline te laten gaan, en scanned op open staande poorten. Dat je de melding ziet is goed, dat betekend dat de ze worden tegengehouden door de firewall van het modem. 

Je kan inderdaad je modem een paar dagen uitzetten met de hoop dat je een nieuw ip adres krijgt, maar er is geen zekerheid op. De kans is zelf zeer klein gezien een DHCP server je altijd hezelfde ip adres zal proberen te geven aan hetzelfde mac adres, zelfs als het een offline is geweest. 

Hi @h134352RET, 

Sinds 12juli2024 krijg ik ook in mijn veiligheidslogboek van de Zyxel EX5601-T1 ook elke dag dit soort meldingen.

het begint met 2 óf 3 óf 4 PORT SCANS vanaf een internet adres naar het WAN IP-adres van mijn Zyxel router. Daarna gaan er verschillende PING OF DEATH's van een IP-adres uit mijn DHCP range naar verschillende internet adressen toe. Hierdoor lijkt het alsof de aanval dan vanuit mij komt (weliswaar staat er een verkeerde SRC MAC adres bij) maar toch. Hoe komen ze aan dat IP adres uit mijn DHCP range.
Mogelijk kunnen ze het verkeer wat uit mijn router komt sniffen.
Volgens de tijdstempel gebeurt dat 's nachts maar dan is de betreffende IP-adres niet in gebruik (mijn PC staat dan écht uit).

Voor zover het kon worden uitgezocht komen de aanvallen uit China en Thailand en/of dat ze via verschillende andere landen naar ons land een aanval doen, waardoor ze moeilijk te achterhalen zijn !?

Ze proberen maar wat en als het hun lukt ……. dan zouden er grote problemen kunnen ontstaan !

Als ik mijn Zyxel router voor een paar dagen spanningsloos maak zal ik geen internet en dus ook geen TV meer hebben waar iedereen thuis zo verzot op is.

Hoe je zoiets goed moet aanpakken weet ik nog niet.
 

Hey @widwi 

Die poortscans hoef je je niet al te veel zorgen over te maken. Dit is ‘normaal’. Vaak zijn dit botnets die op zoek zijn naar services die misbruikt kunnen worden en deze scannen niet specifiek jouw ip adres maar hele ranges. Zolang je zelf geen poorten openzet is er niks aan het handje. Doe je dat wel, omdat je bijvoorbeeld een webserver voor buitenaf hebt draaien, dan moet je er natuurlijk wel voor zorgen dat e.a. goed beveiligd is.

Het uit en aanzetten van je router om een nieuw ip adres te vergaren is overigens betrekkelijk zinloos. De kans is namelijk redelijk groot, zo niet 100%, dat het nieuwe ip ook weer gescanned gaat worden. Juist om bovenstaande reden.

Wat ik niet kan verklaren, ik ben ook niet zo bekend met de Zyxel modems, is waarom je in die logs een ip uit je interne range als source ziet staan. Je router doet iets dat ze Network Address Translation noemen om het verkeer van je interne netwerk verder het internet op te kunnen sturen. Dit houdt in dat het source adres juist het externe ip adres van je router zou moeten zijn. Ik ben wel benieuwd naar dit dus zou je de entry kunnen posten waar dit gebeurt? Let er hierbij op dat je wel even je externe adres door X.X.X.X vervangt mocht dit hierin staan.

Hi @Marty_J 

Hieronder de veiligheidslogboek items van vandaag:

Hoop dat het een beetje te lezen is !

Het begint met PORT SCANS daar lijkt het wel of mijn interne ip-adres als proxy wordt gebruikt om naar buiten aan te vallen.

Het vreemde is dat het MAC-adres slechts uit 14 bytes bestaat, IPv6 MAC adres is 16 bytes…. !?

Misschien is het een storm in een glas water maar dat ze mijn interne IP-adres hebben baart mij zorgen.

Ik heb een totale listing van het veiligheidslogboek vanaf 13juli, zo kan ik mooi de gang van zaken volgen.

1    Jul 19 08:20:16    kern    alert    attack    kernel: a545417.480644] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.39.75 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=5897 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=20 ZEXTMARK=0x8
2    Jul 19 08:20:16    kern    alert    attack    kernel: 545417.480608] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.39.56 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=25896 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=19 ZEXTMARK=0x8
3    Jul 19 08:20:15    kern    alert    attack    kernel: �545416.452962] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.40.175 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=33294 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=15 ZEXTMARK=0x8
4    Jul 19 08:20:15    kern    alert    attack    kernel: J545416.452960] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.40.121 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=33383 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16 ZEXTMARK=0x8
5    Jul 19 08:20:15    kern    alert    attack    kernel: 8545416.452703] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.40.16 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=1769 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=14 ZEXTMARK=0x8
6    Jul 19 08:20:15    kern    alert    attack    kernel: =545416.452701] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=18.65.40.202 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=3304 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=13 ZEXTMARK=0x8
7    Jul 19 08:20:15    kern    alert    attack    kernel: C545415.641090] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=65.9.86.97 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=32981 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=12 ZEXTMARK=0x8
8    Jul 19 08:20:15    kern    alert    attack    kernel: T545415.640824] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.160 DST=65.9.86.112 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=16038 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=11 ZEXTMARK=0x8
9    Jul 19 02:10:35    kern    alert    attack    kernel: 2523259.512072] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=159.192.106.207 DST=AAA.BBB.CCC.DDD LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=59523 DF PROTO=TCP SPT=13679 DPT=34393 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=63630
10    Jul 18 23:45:51    kern    alert    attack    kernel: C514585.215312] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=128.199.181.4 DST=AAA.BBB.CCC.DDD LEN=60 TOS=0x00 PREC=0x00 TTL=50 ID=20067 PROTO=TCP SPT=43690 DPT=7735 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=44390

Voor de zekerheid haal ik deze PC, waar ik nu mee dit stuur, van Wifi af voor een aantal dagen.
Voorheen kon je nog een dhcp ip-adres blokkeren zodat je een andere ip-adres van de dhcp server kan krijgen. Tegenwoordig blijkt dat niet zo makkelijk te gaan. Je kan het wel releasen maar daar heb je weinig aan.

Nog bedankt voor je reactie ! 
 

Hey @widwi 

Als ik het zo lees heb je idd 192.168.1.160  op eth1.3 staan Dit is op z’n zachts gezegd apart te noemen. Er horen geen rfc-1918 adressen op die interface te staan. Dit lijkt me een bug te zijn in de Zyxel firmware.

@Waqqas kan jij hierr iets over zeggen?

@widwi 

Het zal aan mij liggen maar wat ik tevens niet begrijp is waarom waarom die router  icm echo requess als een ‘ping of death’ ziet. 

Iemand als een @Tommie van Odido kan je e.a. missdhien beter uitleggen hoe dat precies zit. Die kan je ook vertellen dat een pintg of death niks te maken heeft met icm type 8. 

Hallo @widwi en @Marty_J 

@Marty_J geeft al aan wat het is, wat ik er nog aan kan toevoegen is dat alle Odido gebruikers met een Zyxel deze meldingen in het logboek zien. Het zijn meldingen van je firewall die al deze pogingen blokkeert en daarvan zie je meldingen terug.

Mocht je deze meldingen willen verbergen dan kan dat bij onderhoud > logboek instellingen > onder veiligheidslogboek vink attack uit en klik op toepassen.

Ik pakte ook even mijn logboek erbij en bij de meeste meldingen zag ik geen interne IP adressen maar toen ik even verder keek kwam ik een reeks meldingen tegen met SRC: 192.168.1.168 (dit is een OPPO 3 Lite in huis).

Ik weet hier echter ook niet veel over en omdat ik hier geen problemen door ervaar, negeer ik ze.

Ik zie ze bij mij ook.

Bijzonder is dat het mac adres bij de zyxel hoort…

LAN-informatie

• IP-adres 192.168.1.1
• Subnetmasker 255.255.255.0
• DHCP Server
• MAC-adres =========

Hallo @Waqqas en @Marty_J 

Alvast bedankt voor jullie inzet.

Op 13 juli ben ik in de logging gaan kijken omdat een notebookje in de nacht van 12/13 plotseling geen internet meer had via mijn extender. Op geen enkele wijze kon ik dit meer eenvoudig aan de praat krijgen.

Vanaf 13 juli j.l. volg ik deze meldingen nauwlettend. De interne ip-adres .160 is een van de twee PC’s die ik als SRC naar buiten zie gaan in de betreffende logging. Op deze PC’s ben ik vaak aan het werk.

Vandaar mijn zorgen !  Direct nadat ik de logging had bekeken heb ik de PC’s meteen volledig gescanned  met up-to-date vulnerabilty software, er werd gelukkig niets gevonden maar gaf toch geen fijn gevoel omdat het lijkt dat er ‘iemand’ in de buitenwereld mijn interne ip-adressen weet. Deze PC’s heb ik ‘s nachts uit staan.

Ik laat de logging aan staan omdat ik dan kan “zien” wat de boze buitenwereld enigzins van plan is.

Mochten jullie nog een briljant idee hebben dan zou ik het graag willen weten.

Ciao !

@JwBokx 

Het MAC adres lijkt er veel op maar nog net niet ! 
In de meldingen is MAC adres slechts 14 bytes. Voor IPv6 zou dit 16 bytes(128bits totaal) moeten zijn… !

Voor IPv4 zouden dit er 6 bytes(48bits totaal) moeten zijn !

Dit is op zich al vreemd wat er in de meldingen staan.
Het kan zijn dat je er een bepaalde UUID ervoor gebruiken.

@JwBokx 

Herstel:
Je hebt gelijk, het IPv4 LAN MAC-adres staat er wel in z'n geheel in de logging,

Waar maakt u zich druk om?

Er is niets gevonden. Interne IP-adressen zijn wereldwijd hetzelfde.

Mijn interne IP-adressen zitten in de range 192.168.0.XXX. Niemand kan daar wat mee.

Zorg dat uw OS up-2-date is, en dat u een grenommeerd beveiligingspakket hebt geinstalleerd.

@Darkman wat ipadres, ja dat is natuurlijk zo.

Maar bij het macadres lijkt het nu alsof de aanval van binnen uit komt…

Nu kan een macadres natuurlijk ook vals zijn, maar vind het wel raar.

Als het goed is, komt het toch van buiten?

Aanvallen komen van buiten, communicatie in het interne netwerk speelt binnen uw interne netwerk plaats.

Ook u hoeft zich geen zorgen te maken. Zorg dat uw windows (neem ik aan) up-2-date is, en dat u niet te pas en te onpas software installeert.

Een goed beveiligingspakket is bv eset NOD32, die hier draait op de google-TV (echt waar) en mijn Pixel 8 en Samsung TAB s8.

Ben een Linux gebruiker.

@Darkman 

Bij Crowdstrike maakten ze zich ook niet druk om een simpele update en zie de gevolgen wereldwijd ervan.

Je hebt gelijk ik maak mij ook geen zorgen maar wat ik niet uit kan staan is dat ik nog steeds geen verklaring heb waarom mijn MAC adres en het interne IP adres in een “Ping Of Death” naar buiten ging zoals JwBokx ook opmerkte.
Hoe komen mijn MAC - en IP-adres in een  uitgaande “Ping Of Death” terecht vanuit mijn Zyxel ????

Na bovenstaande voorval tot op het moment van dit schrijven zijn er “gelukkig”  alleen nog maar TCP PORT SCANS geweest. 

Nadat er de afgelopen 3 dagen alleen PORT SCANS zijn geweest zijn er vandaag weer PING OF DEATH's op mijn router afgevuurd.

Het interne IP-adres had ik gewijzigd en is fixed i.p.v. DHCP.

Toen ik de logging vandaag opende was ik stom verbaasd dat mijn gewijzigde interne IP-adres weer als SRC en mijn MAC in een uitgaande  “Ping Of Death”  vanuit mijn Zyxel worden verstuurd ???

Het lijkt wel of ik (mijn router) gepinpoint ben daarbuiten.

Vraag is: Hoe komen ze aan mijn interne IP-adres ??? (ondanks dat deze is gewijzigd …. ??)

Bij deze mijn VeiligheidsLogboek van deze ochtend:(logging begint onderaan)

Mijn externe IP-adres is heb ik gemaskeerd met AAA.BBB.CCC.DDD

1    Jul 23 10:08:41    kern    alert    attack    kernel: �897144.944397] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=5.195.53.41 DST=AAA.BBB.CCC.DDD LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=25253 DF PROTO=TCP SPT=179 DPT=22 WINDOW=15369 RES=0x00 URGP=0
2    Jul 23 09:37:33    kern    alert    attack    kernel: r895279.595672] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=159.192.106.207 DST=AAA.BBB.CCC.DDD LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=63704 DF PROTO=TCP SPT=36909 DPT=1025 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=45443
3    Jul 23 08:09:39    kern    alert    attack    kernel: :890011.347751] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=18.65.39.3 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=23080 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=19 ZEXTMARK=0x8
4    Jul 23 08:09:39    kern    alert    attack    kernel: �890011.327694] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=18.65.39.56 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=44086 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=18 ZEXTMARK=0x8
5    Jul 23 08:09:38    kern    alert    attack    kernel: A890010.300691] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=18.65.40.16 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=58582 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=16 ZEXTMARK=0x8
6    Jul 23 08:09:38    kern    alert    attack    kernel: =890010.300516] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=18.65.40.121 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=61337 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=13 ZEXTMARK=0x8
7    Jul 23 08:09:37    kern    alert    attack    kernel: Y890009.311665] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=65.9.86.121 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=34750 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=12 ZEXTMARK=0x8
8    Jul 23 08:09:37    kern    alert    attack    kernel: 5890009.311483] PING OF DEATH ATTACK:IN=br0 OUT=eth1.3 MAC=f8:0d:a9:07:ad:7a:e4:b3:18:62:98:b9:08:00 SRC=192.168.1.183 DST=65.9.86.112 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=20820 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=11 ZEXTMARK=0x8
9    Jul 23 08:05:43    kern    alert    attack    kernel: 889774.869777] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=218.161.74.135 DST=AAA.BBB.CCC.DDD LEN=60 TOS=0x00 PREC=0x00 TTL=53 ID=51235 DF PROTO=TCP SPT=58689 DPT=21857 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=43984
10    Jul 23 00:46:53    kern    alert    attack    kernel: R863473.442716] TCP PORT SCAN ATTACK:IN=eth1.3 OUT= MAC=f8:0d:a9:07:ad:7f:00:02:00:00:00:03:08:00 SRC=1.34.85.243 DST=AAA.BBB.CCC.DDD LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=34694 DF PROTO=TCP SPT=16659 DPT=11038 WINDOW=0 RES=0x00 URG ACK PSH RST SYN FIN URGP=18396

De belangrijkste vraag die je jezelf moet stellen, welk device in je netwerk heeft dit interne IP?

Als het een Windows machine is, dan zou het kunnen zijn dat er een achtergrond service draait.

Als het windows is, installeer dan eens Sysinternals Suite om een kleine deep dive te doen op die machine.

@Pieter_B 

Bedankt voor de tip !

Ben er inderdaad mee bezig, heb een aantal tools uit de Suite gehaald om de poorten te kunnen monitoren. Daarnaast draait ook nog Wireshark . Ik activeer elke keer de interface van het notebook pas als alles gereed staat. Voor zover ik het in het Veiligheidslogboek kan zien lijkt het dat er NA een PORT SCAN een sessie, met mijn interne IP-adres, naar buiten gaat maar dit gebeurt ook niet altijd na een PORT SCAN. 

Inmiddels is gevonden dat het IP adres 159.192.106.207 in de AbuseIPDB staat (www.abusipdb.com/check) . Dit is een van de IP-adressen vanwaar PORT SCANS worden geinitieerd. Het schijnt dat er afgelopen weken veel meldingen betreffende dit IP-adres bij AbuseIPDB zijn binnengekomen.

Het IP-adres 1.34.85.243 blijkt te zijn geregistreerd met DNS Hostname (PTR Record):1-34-85-243.hinet-ip.hinet.net  bij de Asia Pacific Network Information Centre in Taiwan.

Maar, dat is nog niet direct de oplossing op de vraag waarom mijn interne IP-adres na zo’n PORT SCAN in een uitgaande verkeer voorkomt…..

IP adressen kun je gewoon SPOOFEN he..