Netwerkbeheer beheersbaar houden

[Foeijonghaai]

Momenteel werk ik voor een middelgroot bedrijf als systeem- en netwerkbeheerder.

In mijn huidige project nemen we het beheer over van een applicatie welke eerst door development werd beheerd. Daarbij wordt de applicatie verhuisd van het onsite datacenter naar een offsitedatacenter.

De servers en applicatie beheer ik volledig via netinstall, ansible, en git. Dus de changes zijn geborgd, we kunnen historie bekijken en ook wie wat doet. Redenen voor changes documenteren in de commits.

Maar het netwerk: de router/firewall offsite heeft momenteel 700+ firewall regels. Er bestaan addresslist met 100-en entries om bepaalde landen toe te staan en de rest te blokken.
Alleen al voor de nieuwe applicatie heb ik er er zeker 25 regels bij gemaakt.
Dit was mijn eerste kennismaking met het netwerk.

Maar dat doe je direct op de router. Er worden wel geautomatiseerd backups gemaakt van de configuratie, maar niemand bekijkt de changes. Er staan logs in de router, maar van auditing is geen sprake. De firewall is voor mij erg nieuw. Ik ga er vanuit dat ik geen gaten introduceer, maar hoe weet je dat zeker? Voor servers heb je monitoring of diensten beschikbaar zijn. Je gaat niet iedere minuut een pentest afvuren op je netwerk (denk ik?).

Er is een module voor ansible voor onze routersoftware, maar dat bestaat alleen uit het uitvoeren van commando's. Het werkt niet met promises zoals we linux nu beheren.

Wanneer ik zoek op het beheersbaar houden van 100-en regels krijg ik alleen best practices zoals regelmatig auditen, software up to date houden etc. Iedere tutorial gaat uit van 'dit doe je zo, dat doe je zo' maar niets over '600x dit'

Bij ieder ding wat ik doe in de router/firewall kan ik een comment plaatsen. Ik ben begonnen om al mijn regels te prefixen met een afkorting voor het project, maar mijn collega's hebben dat in het verleden niet gedaan en er is natuurlijk geen garantie dat ze dat in de toekomst zullen doen. Ook probeer ik alle regels van hetzelfde project bij elkaar te zetten/houden.

Qua documentatie hebben we Netbox, maar daar kunnen we zonder eigen modules onze firewallregels niet in kwijt. Ook is er geen garantie dat het bijgewerkt word.

Mijn vragen:

• hoe professionaliseer je het beheer van het netwerk?
• wat zijn goede zoektermen voor literatuur
• Is goede tooling alleen beschikbaar voor de grote merken? Op dit moment gebruiken we RouterOS/Mikrotik

[ Voor 1% gewijzigd door Foeijonghaai op 14-05-2025 14:49 . Reden: tags fixen ]

[Duke of Savage]

Wat voor firewall heb je in gebruik? Is dat een Fortigate, Juniper, of anders?

[Foeijonghaai]

We gebruiken Mikrotik/RouterOS

[Sjnieboon]

Goed advies geven is lastig omdat elke omgeving weer anders is. Ik liep tegen dezelfde obstakels aan en daarom zijn we overgegaan op een 'grotere naam' met onze netwerkapparatuur. Het belang van goede documentatie, auditing en automatisering (zoals je zelf ook omschrijft met Ansible en Git) weegt voor ons veel zwaarder dan het prijskaartje.

[Foeijonghaai]

Sjnieboon schreef op woensdag 14 mei 2025 @ 14:51:
Goed advies geven is lastig omdat elke omgeving weer anders is. Ik liep tegen dezelfde obstakels aan en daarom zijn we overgegaan op een 'grotere naam' met onze netwerkapparatuur. Het belang van goede documentatie, auditing en automatisering (zoals je zelf ook omschrijft met Ansible en Git) weegt voor ons veel zwaarder dan het prijskaartje.

Welke voordelen/winst ervaar je?

Beheer je bijv alles vanuit 1 applicatie? Heb je beter overzicht?

[Sjnieboon]

Foeijonghaai schreef op woensdag 14 mei 2025 @ 14:56:
[...]

Welke voordelen/winst ervaar je?

Beheer je bijv alles vanuit 1 applicatie? Heb je beter overzicht?

Je beschrijft in je openingspost eigenlijk mijn huidige werkwijze. Ik gebruik Ansible i.c.m. Git en automatische deployments via Gitlab. Als ik een wijziging wil doorvoeren aan onze infra (servers of networking) maak ik een feature branch, breng mijn wijzigingen aan, maak een merge request (pull request voor de Github gebruikers). Deze moet approved worden door een collega. Als dat is gebeurd start er een pipeline die het uitrolt.

De initiële opzet is wat werk (ook afhankelijk van de grootte van je infra natuurlijk), maar het is wat mij betreft een must als je wat meer dan een handvol servers en switches beheerd.

Edit: de winst zit hem in een sluitend geheel te hebben (belangrijk voor onze audits) en dat alle wijzigingen op dezelfde manier worden doorgevoerd. Ik hoef niet te zoeken in een webinterface naar de juiste submenu's. Ik hoef geen CLI commando's uit mijn hoofd te kennen. De Ansible roles doen dat werk voor me.
Je kunt dit ook weer gebruiken voor bijv. je disaster recovery.

[ Voor 18% gewijzigd door Sjnieboon op 14-05-2025 15:03 ]

[koppie]

En eigenlijk staat hier grotendeels dan je werkwijze. Je gaat de scripts (en rollbacks) in github opnemen.

[Foeijonghaai]

Ik heb ook zitten denken om zaken te compartimenteren.

Bijvoorbeeld dit project zijn eigen router/firewall (paar). Zodat je zeker weet dat alle configuratie op die router alleen voor dat project is.

Behalve extra kosten en dat niet alles meer op dezelfde plek staat zie ik geen nadelen, maar als je misschien tientallen projecten hebt krijg je misschien weer complexiteit om alles aan elkaar te knopen. Helemaal als sommige applicaties misschien onderling moeten communiceren.
Ik begrijp dat het ook wel afhankelijk is van de topologie van de rest van het netwerk.

Wat vinden jullie in zijn algemeenheid van het idee van compartimenteren?

[ Voor 1% gewijzigd door Foeijonghaai op 14-05-2025 15:54 . Reden: spelfouten ]

[Foeijonghaai]

koppie schreef op woensdag 14 mei 2025 @ 15:20:
En eigenlijk staat hier grotendeels dan je werkwijze. Je gaat de scripts (en rollbacks) in github opnemen.

Ik was niet bekend met de history, undo en redo opties. Thanks!

[mash_man02]

Foeijonghaai schreef op woensdag 14 mei 2025 @ 14:49:
We gebruiken Mikrotik/RouterOS

Dat heb ik nog nooit in een enterprise achtige omgeving gezien.

Mijn ervaringen met dit merk zijn wisselt, goed betaalbaar, mooie specs maar soms ook behoorlijk buggy.

Enterprise firewall's kunnen vaak geleverd worden met de tools die jij beschrijft.

Bij Forigate b.v. de Fortimanager, en bij Palo-Alto Panorama. Checkpoint en Cisco hebben ook zo hun management suites waarin je overigens meer dan 1 firewall kunt beheren.

[Sjnieboon]

Foeijonghaai schreef op woensdag 14 mei 2025 @ 15:53:
Ik heb ook zitten denken om zaken te compartimenteren.

Bijvoorbeeld dit project zijn eigen router/firewall (paar). Zodat je zeker weet dat alle configuratie op die router alleen voor dat project is.

Behalve extra kosten en dat niet alles meer op dezelfde plek staat zie ik geen nadelen, maar als je misschien tientallen projecten hebt krijg je misschien weer complexiteit om alles aan elkaar te knopen. Helemaal als sommige applicaties misschien onderling moeten communiceren.
Ik begrijp dat het ook wel afhankelijk is van de topologie van de rest van het netwerk.

Wat vinden jullie in zijn algemeenheid van het idee van compartimenteren?

Je maakt het daarmee denk ik onnodig complex. Als je naar bijvoorbeeld FortiGate kijkt kun je (afhankelijk van het model) meerdere "virtuele firewalls" (VDOM's) aanmaken, als dat gewenst is. Dan heb je dus fysiek 1 apparaat, maar heb je de mogelijkheid om omgevingen op die manier te scheiden.

Je werkt nu met MikroTik, en daar is opzich niks mis mee. Het heeft alleen niet de enterprise features waar je naar op zoek bent (van wat ik uit je verhaal op maak). Je kunt dat nog steeds goed werkbaar maken, maar daar gaat dan extra tijd in zitten. Daarom zit er ook een ander prijskaartje aan vast.

[Qwerty-273]

mash_man02 schreef op woensdag 14 mei 2025 @ 16:06:
Bij Forigate b.v. de Fortimanager, en bij Palo-Alto Panorama. Checkpoint en Cisco hebben ook zo hun management suites waarin je overigens meer dan 1 firewall kunt beheren.

Je hebt ook vendor onafhankelijke oplossingen die jouw netwerk ontwerp kunnen deployen naar de hardware. Bijvoorbeeld Nautobot waarmee je eigenlijk een "source of truth" opstelt die vervolgens in je netwerk hardware wordt ingespoeld. Je maakt veranderingen in Nautobot en die voert ze vervolgens door naar de netwerk hardware. En daarbij kan je ook verifiëren dat de configuratie op de hardware dezelfde is als in Nautobot. En eventuele afwijkingen detecteren en herstellen. Je kan daarmee ook makkelijker (technisch dan ten minste) wisselen van hardware van de ene fabrikant naar de andere.

[Fox3214]

Foeijonghaai schreef op woensdag 14 mei 2025 @ 14:41:
Momenteel werk ik voor een middelgroot bedrijf als systeem- en netwerkbeheerder.

In mijn huidige project nemen we het beheer over van een applicatie welke eerst door development werd beheerd. Daarbij wordt de applicatie verhuisd van het onsite datacenter naar een offsitedatacenter.

De servers en applicatie beheer ik volledig via netinstall, ansible, en git. Dus de changes zijn geborgd, we kunnen historie bekijken en ook wie wat doet. Redenen voor changes documenteren in de commits.

Maar het netwerk: de router/firewall offsite heeft momenteel 700+ firewall regels. Er bestaan addresslist met 100-en entries om bepaalde landen toe te staan en de rest te blokken.
Alleen al voor de nieuwe applicatie heb ik er er zeker 25 regels bij gemaakt.
Dit was mijn eerste kennismaking met het netwerk.

Maar dat doe je direct op de router. Er worden wel geautomatiseerd backups gemaakt van de configuratie, maar niemand bekijkt de changes. Er staan logs in de router, maar van auditing is geen sprake. De firewall is voor mij erg nieuw. Ik ga er vanuit dat ik geen gaten introduceer, maar hoe weet je dat zeker? Voor servers heb je monitoring of diensten beschikbaar zijn. Je gaat niet iedere minuut een pentest afvuren op je netwerk (denk ik?).

Er is een module voor ansible voor onze routersoftware, maar dat bestaat alleen uit het uitvoeren van commando's. Het werkt niet met promises zoals we linux nu beheren.

Wanneer ik zoek op het beheersbaar houden van 100-en regels krijg ik alleen best practices zoals regelmatig auditen, software up to date houden etc. Iedere tutorial gaat uit van 'dit doe je zo, dat doe je zo' maar niets over '600x dit'

Bij ieder ding wat ik doe in de router/firewall kan ik een comment plaatsen. Ik ben begonnen om al mijn regels te prefixen met een afkorting voor het project, maar mijn collega's hebben dat in het verleden niet gedaan en er is natuurlijk geen garantie dat ze dat in de toekomst zullen doen. Ook probeer ik alle regels van hetzelfde project bij elkaar te zetten/houden.

Qua documentatie hebben we Netbox, maar daar kunnen we zonder eigen modules onze firewallregels niet in kwijt. Ook is er geen garantie dat het bijgewerkt word.

Mijn vragen:

• hoe professionaliseer je het beheer van het netwerk?
• wat zijn goede zoektermen voor literatuur
• Is goede tooling alleen beschikbaar voor de grote merken? Op dit moment gebruiken we RouterOS/Mikrotik

1. Normaal gesproken zou ik een fysieke firewall of een appliance voorstellen.
Dit maakt het beheer in theorie schaalbaarder richting de toekomst.
Voor een middelgroot bedrijf met een beperkt budget zou ik persoonlijk kiezen voor een Fortigate-firewall.

2. Je geeft aan dat je een Ansible-module gebruikt voor deze routersoftware.
Je zou ook zelf een Ansible-role of project kunnen schrijven.
Als je de Galaxy-module gebruikt, kun je mogelijk zelfs bijdragen aan een open-source project.

3. Je geeft aan dat je NetBox gebruikt. Je zou een custom plugin kunnen maken om je policies daarin te definiëren.
Als je liever iets kant-en-klaars gebruikt, dan is Nautobot (een fork van NetBox) een interessante optie.
Binnen Nautobot kun je firewallregels definiëren via het “Security > Policy Rules”-model:
https://docs.nautobot.com...irewall-models/en/latest/


Hoe professionaliseer je het beheer van je netwerk?
Dat is een brede vraag, maar dit zijn de stappen die ik zou aanraden:

1. Zorg dat alle netwerkapparatuur in je CMDB staat (bijv. NetBox of Nautobot).
2. Zorg voor geautomatiseerde back-ups van de configuraties.
(Volgens mij heb je dit al.)
3. Sla je back-ups op in een lokale GitLab-repo, zodat je wijzigingen kunt volgen.
4. Gebruik PRTG of Grafana met Prometheus voor monitoring.
Combineer dit met telemetry of SNMP-logging om inzicht te krijgen.
5. Rapporteer uptimes, downtimes en firewall rule hit-counters.
6. Maak plannen voor scenario’s:
6.1 Wat als een uplink uitvalt?
6.2 Wat als er een DDoS-aanval plaatsvindt?
6.3 Wat als een core-device faalt?
7. Audit's zijn ook een breed begrip, wat voor audit's zou je willen hebben?
7.1 Je firewall regels zouden een change nummer moeten hebben?
7.2 Welke verkeer stromen gaan naar binnen en buiten?

[Foeijonghaai]

mash_man02 schreef op woensdag 14 mei 2025 @ 16:06:
[...]

Dat heb ik nog nooit in een enterprise achtige omgeving gezien.

Mijn ervaringen met dit merk zijn wisselt, goed betaalbaar, mooie specs maar soms ook behoorlijk buggy.

Ik heb in het verleden een bug meegemaakt waarbij als je een export van de config deed de CLI vastliep, maar daarna nooit meer. Maar dan hebben we het over 10+ jaar terug.

Ik vind de CLI van RouterOS (met name de auto complete) super consistent en ongeëvenaard, logisch, en scriptbaar. Daar kunnen de grote merken echt nog wat van leren.

Ik heb grotere installaties in datacenters gezien en ook kleine installaties waarbij ze CPEs waren met VPNs.

Aantekening is ook dat ik in een land werk waar de lonen lager liggen en dat daarom er andere afwegingen worden gemaakt bij de aanschaf van hardware en dat zelfbouw vaker een keuze is.

Maar goed, dat terzijde.

[Foeijonghaai]

In meerdere posts wordt Nautobot genoemd. Dat ziet er erg interessant uit. Ik ga er in ieder geval naar kijken. Geen idee of ik dat hier erdoor krijg, na jaren van verwaarlozing en een intensieve periode om alles te documenteren staat nu eindelijk alles in Netbox. Maar wie weet is het uitwisselbaar aangezien het om een fork gaat.

[Foeijonghaai]

Fox3214 schreef op woensdag 14 mei 2025 @ 17:05:
Dat is een brede vraag, maar dit zijn de stappen die ik zou aanraden:

1. Zorg dat alle netwerkapparatuur in je CMDB staat (bijv. NetBox of Nautobot).
2. Zorg voor geautomatiseerde back-ups van de configuraties.
(Volgens mij heb je dit al.)
3. Sla je back-ups op in een lokale GitLab-repo, zodat je wijzigingen kunt volgen.
4. Gebruik PRTG of Grafana met Prometheus voor monitoring.
Combineer dit met telemetry of SNMP-logging om inzicht te krijgen.
5. Rapporteer uptimes, downtimes en firewall rule hit-counters.
6. Maak plannen voor scenario’s:
6.1 Wat als een uplink uitvalt?
6.2 Wat als er een DDoS-aanval plaatsvindt?
6.3 Wat als een core-device faalt?
7. Audit's zijn ook een breed begrip, wat voor audit's zou je willen hebben?
7.1 Je firewall regels zouden een change nummer moeten hebben?
7.2 Welke verkeer stromen gaan naar binnen en buiten?

Bedankt voor je stappenplan.

Ik mis nog (niet in je verhaal maar op het werk) hoe je met meerdere beheerders hetzelfde idee of visie houdt (zoals bij programmeren er coding standards zijn), bijv. qua naamgeving, omschrijvingen in het commentaar.

Maar ik denk dat dat alleen afgedwongen kan worden wanneer je reviews van changes doet en vereist dat er reviews gedaan worden voordat er wijzigingen gepushed worden.

een CMDB die ook diagrammen zou kunnen genereren zou super zijn want ik vind een tekening soms toch sneller te snappen dan dat ik eerst de tekening in mijn hoofd moet opbouwen vanuit de CMDB

[Fox3214]

Foeijonghaai schreef op zondag 18 mei 2025 @ 12:41:
[...]

Bedankt voor je stappenplan.

Ik mis nog (niet in je verhaal maar op het werk) hoe je met meerdere beheerders hetzelfde idee of visie houdt (zoals bij programmeren er coding standards zijn), bijv. qua naamgeving, omschrijvingen in het commentaar.

Maar ik denk dat dat alleen afgedwongen kan worden wanneer je reviews van changes doet en vereist dat er reviews gedaan worden voordat er wijzigingen gepushed worden.

een CMDB die ook diagrammen zou kunnen genereren zou super zijn want ik vind een tekening soms toch sneller te snappen dan dat ik eerst de tekening in mijn hoofd moet opbouwen vanuit de CMDB

No worries!

Voor de visie zijn een aantal dingen belangrijk als het gaat om Infra As Code (IaC).

1. Leg je IaC codes vast in git repositories
2. Voor productie code repositories, laat een senior code reviews doen bij commits
3. Introduceer linting en andere code validatie software
4. Introduceer tests
5. Introduceer CI/CD pipelines

Voor naam conventies zou je bijvoorbeeld een yaml file kunnen gebruiken, en deze forceren in je code.

Hiermee pak je al een hoop tegenstrijdig uniform gedrag aan, en gaan mensen sneller templates of bestaande code repo's gebruiken om zo hun code goed gekeurd te krijgen.

Volgens mij heeft Netbox een diagram plugin waarmee je dat kan bereiken:
https://github.com/netbox-community/netbox-topology-views

[ Voor 3% gewijzigd door Fox3214 op 19-05-2025 09:14 ]

[MasterL]

Ik zou persoonlijk eens naar de werkwijze kijken, zoveel firewall rules (handmatig) beheren is vragen om gezeur vroeg of laat. Is het niet een idee om VPN te gaan gebruiken?
Persoonlijk zou ik de vraag omdraaien waarom beheer ik een omgeving die 700 rules nodig heeft en kan ik dit niet versimpelen?

[Foeijonghaai]

MasterL schreef op maandag 19 mei 2025 @ 10:00:
Ik zou persoonlijk eens naar de werkwijze kijken, zoveel firewall rules (handmatig) beheren is vragen om gezeur vroeg of laat. Is het niet een idee om VPN te gaan gebruiken?
Persoonlijk zou ik de vraag omdraaien waarom beheer ik een omgeving die 700 rules nodig heeft en kan ik dit niet versimpelen?

Het kan zeker versimpeld worden. Ik weet zeker dat er een hoop regels dubbel zijn omdat iedereen maar wat doet en er steeds weer een regeltje bij plakt en niet altijd het juiste perspectief heeft/had.

Zo heeft zowat ieder losse server en/of subnet een regel: 'er mag SSH naar toe plaatsvinden'. Terwijl het samen te vatten is met: 'het vlan van de beheerders mag overal naar toe SSH-en'. 20/30 regels vs 1 regel.
Als je met zones werkt hoef je ook niet ieder server individueel dicht te timmeren etc.

En toch is er een setup. Die (wonderwel) werkt en werkbaar gehouden moet worden. En die langzaamaan weer beheersbaar gemaakt moet worden.

De werkwijze moet echt aangepakt worden, maar het zal van mij moeten komen. De andere beheerders zitten er al jaren, hebben dit veroorzaakt/laten gebeuren, zitten al 10 en 5 jaar op hun plek. Een netwerktekening maken en het onderscheid tussen layer 1,2,3 lijken geavanceerde concepten. Het is niet alleen een kwestie van de juiste apparatuur en tools, maar ook van werkwijze, mindset. En misschien wel basics.

[FredvZ]

Foeijonghaai schreef op woensdag 21 mei 2025 @ 09:32:
De werkwijze moet echt aangepakt worden, maar het zal van mij moeten komen. De andere beheerders zitten er al jaren, hebben dit veroorzaakt/laten gebeuren, zitten al 10 en 5 jaar op hun plek. Een netwerktekening maken en het onderscheid tussen layer 1,2,3 lijken geavanceerde concepten. Het is niet alleen een kwestie van de juiste apparatuur en tools, maar ook van werkwijze, mindset. En misschien wel basics.

In je OP staat:

Foeijonghaai schreef op woensdag 14 mei 2025 @ 14:41:
Momenteel werk ik voor een middelgroot bedrijf als systeem- en netwerkbeheerder.

[...]

Dit was mijn eerste kennismaking met het netwerk.

En verderop zeg je:

Foeijonghaai schreef op zondag 18 mei 2025 @ 12:33:
Aantekening is ook dat ik in een land werk waar de lonen lager liggen en dat daarom er andere afwegingen worden gemaakt bij de aanschaf van hardware en dat zelfbouw vaker een keuze is.

Dan zou ik niet al te veel medewerking verwachten:
- Netwerkbeheerders die 5-10 jaar op een bepaalde manier werken gaan niet zomaar luisteren naar een nieuwkomer die voor het eerst iets met het netwerk doet.
- Je wil efficienter gaan werken, daarmee ben je bedreiging voor het voortbestaan van hun banen.

Ik zou in elk geval zorgen dat de manager(s) van de netwerkbeheerders vierkant achter je staat voordat je begint te hakken en te breken in hun huidige werkwijze en netwerk.