Hallo @cker 

Hackers exploit critical Zyxel firewall flaw in ongoing attacks (Mei 2023)

Zyxel's latest security announcements and advices

Het begon allemaal met verdachte activiteit op mijn netwerk, zoals onverklaarbare vertragingen en ongebruikelijke verbindingen met mijn router.

Kan/moet ik hieruit opmaken dat ze doorgedrongen waren tot de LAN zijde van je netwerk, of stonden ze op een DDoS achtige manier je WAN te flooden?

De Zyxel router is een consumenten router, waarbij DDoS afwikkeling best wel een opgave kan zijn.

Sta ook zeker achter je advies, om externe toegang uit te zetten. Maar waar ik de meeste zorgen over heb is, dat netwerk onkundige mensen poorten open zetten als warme broodjes voor hun IoT devices uit China.

En dan laten ze poorten dicht staan, wat een begin is, maar zitten ze met allerlei IoT devices in hun privé LAN … wat mij er dan ook niet geruster op maakt.

Hier hangt al tijden geen Zyxel meer aan de WAN, omdat ik controle wil over mijn netwerk en ik segmenteren van groepen devices nodig heb.

I.i.g. bedankt voor het delen van deze waarneming

Net als @Pieter_B onderschrijf ik je aanbeveling. Ik gebruik wel een Zyxel (iedere router kan security issues hebben) maar wel voor/achter (afhankelijk van waar je kijkt) een pfsense firewall. Mag ik je vragen om wat meer detaills?

• welke router heb je precies?
• Wat voor verbindingen zie je binnen je netwerk? Als je verbindingen ziet VANAF je interne systemen, zou het misschien kunnen dat je interne systemen gehacked zijn, en niet de Zyxel….
• Ik heb even de hack zoals in https://www.rapid7.com/blog/post/2022/05/12/cve-2022-30525-fixed-zyxel-firewall-unauthenticated-remote-command-injection/  geprobeerd, maar die werken niet. Nu kan het goed zijn dat de command syntax voor de customer cpe’s voor ztp anders zijn dan die voor de prof firewalls en VPN devices, maar de foutmelding die krijg “Invalid Username or Password” suggereert dat we niet eens aan het parsen van het commando toekomen en voor die tijd gestopt worden

Ik kan er naast zitten (ben zeker geen security expert) maar ik vemoed dat er iets anders aan de hand is.

Ik wil graag wat verduidelijking bieden met betrekking tot de recente meldingen over Zyxel-router kwetsbaarheden en inbraakpogingen. In tegenstelling tot wat eerder vermeld werd, maak ik geen gebruik van een Zyxel-router, maar van een zelfgemaakte pfSense-router in mijn netwerkconfiguratie.

Het is belangrijk op te merken dat ik een bewuste keuze heb gemaakt om alle poorten gesloten te houden op mijn pfSense-router. Dit betekent dat er geen externe toegang tot mijn netwerk mogelijk is, tenzij specifiek geautoriseerd en geconfigureerd door mijzelf. Hierdoor zijn mijn systemen inherent beschermd tegen externe inbraakpogingen, inclusief die welke gericht zijn op de Zyxel kwetsbaarheden zoals eerder genoemd.

Als een community willen we niet alleen de kwetsbaarheden van specifieke apparaten bespreken, maar ook verschillende strategieën en benaderingen voor netwerkbeveiliging verkennen. Het gebruik van op maat gemaakte oplossingen zoals pfSense stelt ons in staat om een meer gecontroleerde en veilige netwerkomgeving te creëren.

Voor degenen die geïnteresseerd zijn in het verbeteren van hun netwerkbeveiliging, raad ik aan om te overwegen welke maatregelen het beste aansluiten bij hun specifieke situatie, inclusief het gebruik van firewalls, VPN's, sterke authenticatie en regelmatige patching van software en firmware.

Ik wil ook graag de aandacht vestigen op een nieuwe dreiging die ik regelmatig tegenkom in mijn netwerkmonitoring: SERVER-OTHER Sentinel License Manager buffer overflow pogingen. Het lijkt erop dat kwaadwillende actoren deze kwetsbaarheid proberen uit te buiten om ongeautoriseerde toegang tot systemen te verkrijgen.

De Sentinel License Manager is een veelgebruikte toepassing voor softwarelicentiebeheer. Helaas kan een buffer overflow kwetsbaarheid in dit systeem misbruikt worden door aanvallers om kwaadaardige code uit te voeren en controle over een doelsysteem te krijgen.

Om onze systemen te beschermen tegen deze dreiging, zijn er enkele stappen die we kunnen nemen:

1. Patchen en updaten: Zorg ervoor dat alle systemen die de Sentinel License Manager gebruiken up-to-date zijn met de nieuwste beveiligingspatches en updates. Leveranciers bieden vaak patches aan om bekende kwetsbaarheden te verhelpen.

2. Netwerkmonitoring: Blijf actief controleren op verdachte activiteit binnen het netwerk, met bijzondere aandacht voor pogingen om de Sentinel License Manager kwetsbaarheid uit te buiten.

3. Firewall-instellingen: Configureer firewalls om ongeautoriseerd verkeer naar de Sentinel License Manager-poorten te blokkeren, tenzij specifiek geautoriseerd.

4. Beperk toegang: Beperk toegang tot de Sentinel License Manager tot alleen geautoriseerde gebruikers en apparaten. Implementeer indien mogelijk multi-factor authenticatie om de beveiliging verder te versterken.

Door proactief te zijn en deze maatregelen te implementeren, kunnen we de risico's van de SERVER-OTHER Sentinel License Manager buffer overflow pogingen minimaliseren en de integriteit van onze systemen beschermen.

@louisL 

Ik kan er naast zitten (ben zeker geen security expert) maar ik vemoed dat er iets anders aan de hand is.

Ik vermoed dat iemand met vrij weinig kennis van zaken zijn netwerk heeft zitten monitoren en nu met veel gevoel voor dramatiek van een mug een olifant maakt.

Het internet loopt over van de botnets die 24/7 op zoek zijn naar kwetsbare systemen. Dat is geen nieuws, mensen.

Maar goed, meer aandacht voor veiligheid is op zich nooit verkeerd. De algemene tips die gegeven zijn, zijn toch wel de moeite van het overwegen waard.

Als ik dit zie vermoed ik dat je een of ander intusion detection systeem hebt draaien op je pfsense en geen sentinel license server? Het nadeel van een IDS is dat het alle intrusion attemps die binnenkomen logt. En daar zullen er veel van binnenkomen op je publieke IP-adres. Veel script kiddies zullen dat sort attempts op alle IPv4 adressen loslaten in de hoop ergens een kwetsbare server tegen te komen. Daar hoef jij je niet druk over te maken TENZIJ je zo’n server aan het internet hebt gekoppeld. Die Zyxel attempts zijn ook niet voor de Zyxel consumenten routers (gelukkig) maar voor enterprise firewalls en VPN servers. Deze attempts waren voor unauthorized access, maar worden op de Zyxel routers al gestopt (als unauthorized) voordat het commando wordt gestart. Je IDS zet je op het verkeerde been.

Welk IDS heb je aanstaan op pfsense? Snort of surricata neem ik aan?

@louisL 

Welk IDS heb je aanstaan op pfsense? Snort of surricata neem ik aan?

ik gebruik Snort

Conclusie: er is niets aan de hand hier. Je hebt SNORT zo te zien geactiveerd op je WAN interface. Dat geeft allerlei false positives. Zet snort alleen aan op de LAN interface(s). Zie bijv. https://forum.netgate.com/topic/141743/best-rules-to-best-protection-in-wan-and-lan-interface.  De meeste attacks van buiten komen binnen op poorten die dicht staan (er luistert toch niets op die poorten). Jij hebt alles naar binnen dicht staan. Prima! Maar dan doen alle attack pogingen vanuit de wilde buitenwereld je toch niets. Je wilt alleen zien wat er binnen je netwerk gebeurt. Ik weet het, het is contra intuitief, maar SNORT op de WAN is redelijk zinloos en geeft eigenlijk alleen maar false positives

@louisL

Ja, dat zat ik dus ook te denken .. die zit SNORT op de WAN connectie draaien .. hier draait het alleen maar op de interne netten.

Op je ‘buitendeur’ kloppen altijd foute gasten aan, die misbruik maken of willen maken van un-patched systemen. Daar is het, wat @cker ook al aangeeft, je systeem up to date te houden.

Dan nu maar even wat info over wat is SNORT .. nee, niet een verkouden biggetje

En dan is Dave, mijn oude Microsoft Windows programmeur, ook een serie begonnen over het beschermen van je LAN

@louisL 
Heb Snort nu op Lan staan en van Wan gestopt. Bedankt voor de info (newbie in pfsense)