ip conflict voorkomen

[mouk]

Hallo allemaal, eerste post hier.

Wij hebben laatst grote problemen gehad doordat onze router / gateway met IP adress .1 van ons netwerk 'gedrukt' werd door en ander device waar één of andere onverlaat (externe monteur) zonder overleg óók IP .1 op gezet had.

Die twee gingen de strijd met elkaar aan om dat ip adres, met voortdurende, rare en onvoorspelbare resultaten. Duurde lang voordat we door hadden wat er speelde.

De vraag die ik aan jullie heb: heeft iemand hier een idee hoe ik zulke ellende in de toekomst zou kunnen voorkomen? (behalve dan de appliance van de monteur in een apart VLAN zetten, wat inmiddels ook gebeurd is)

Maar ik denk aan iets op onze procurve switches, bv:

- het ip adress .1 alleen toestaan op specifiek aangewezen poorten
of
- het ip .1 alleen toestaan in combinatie met een specifiek mac adres

Iemand met tips of andere ideeen om dit te voorkomen..?

Ik ken arpalert, maar ben eigenlijk op zoek naar iets dat ik op ons procurve chassis (5412zl) zou kunnen doen.

Groet en fijne dagen gewenst!

[Tsurany]

Waarom mag een monteur een apparaat op jullie netwerk aansluiten dat IP adressen uitdeelt dan wel zelf reserveert?

Ik zou hier eerder naar een procedurele dan een technische oplossing kijken.

[ Voor 6% gewijzigd door Tsurany op 28-12-2019 10:15 ]

[unezra]

https://www.dnsstuff.com/ipam-software

Als je nog geen goed helpdesk pakket hebt, zou je kunnen kijken naar TeemIP:
https://www.combodo.com/teemip-194

Dat integreerd mooi als onderdeel van dat prima helpdesk pakket iTop CMDB
https://www.combodo.com/itop-193

Wat @Tsurany zegt, dit is eerder een procedureel dan een technisch ding. Het staat of valt met de juiste procedures én een goede IP administratie / CMDB.

[Vorkie]

Dus.. procedurele oplossing met software voor interne medewerkers waar een externe monteur natuurlijk direct op inlogt?

Kom op, wordt er iets gepost in PNS, zodat je eindelijk iets kan roepen met 802.1x en port-security en een multi-layer netwerk topology, sturen jullie het naar een procedure?

[skelleniels]

Bij ons is de policy dat een externe monteur die een netwerkdevice moet toevoegen met vast IP ALTIJD aan 1 van de netwerkbeheerders een IP adres vraagt die hij mag gebruiken. En dit liefst op voorhand. Werkt eigenlijk altijd goed. Ze hebben je dan toch meestal nog nodig voor eventuele portforwarding.
Een monteur die hele dagen zo'n installaties doet zou toch ook wel moeten weten dat je daar niet "zomaar wat getalletjes" mag in invullen?

Edit: en zelfs al vang je het technisch zodanig op dat een monteur nooit 1 van de al gebruikte IP adressen(al is het static/DHCP), dan nog wil je toch niet dat die monteur zelf willekeurig een IP adres gebruikt? Een beetje de structuur bewaren...(bvb machines in .231-239, camera's 221-229,...)

[ Voor 37% gewijzigd door skelleniels op 28-12-2019 10:53 ]

[unezra]

Vorkie schreef op zaterdag 28 december 2019 @ 10:34:
Dus.. procedurele oplossing met software voor interne medewerkers waar een externe monteur natuurlijk direct op inlogt?

Kom op, wordt er iets gepost in PNS, zodat je eindelijk iets kan roepen met 802.1x en port-security en een multi-layer netwerk topology, sturen jullie het naar een procedure?

Ja.

Want een monteur mag nooit zomaar actieve apparatuur plaatsen en moet ICT informeren over dat in zo'n apparaat bijvoorbeeld een DHCP server actief is en wat het IP adres is van het ding. (Of meer: Moet vragen welk IP adres dat ding mag hebben en wat er wel en niet actief mag zijn op het apparaat. Een rogue DHCP server plaatsen en zomaar een IP adres geven aan zo'n apparaat is een heel dikke NOGO.)

Je procedures zijn de eerste borging, techniek komt hier op de 2e plaats.

[ Voor 13% gewijzigd door unezra op 28-12-2019 10:46 ]

[Vorkie]

unezra schreef op zaterdag 28 december 2019 @ 10:45:
[...]


Ja.

Want een monteur mag nooit zomaar actieve apparatuur plaatsen en moet ICT informeren over dat in zo'n apparaat bijvoorbeeld een DHCP server actief is en wat het IP adres is van het ding. (Of meer: Moet vragen welk IP adres dat ding mag hebben en wat er wel en niet actief mag zijn op het apparaat. Een rogue DHCP server plaatsen en zomaar een IP adres geven aan zo'n apparaat is een heel dikke NOGO.)

Je procedures zijn de eerste borging, techniek komt hier op de 2e plaats.

Ja, klinkt hartstikke mooi, er mag zoveel niet, maar staat het ergens dat ze vragen om een procedurele oplossing? Dat is wel een aanvulling en must op het geheel, maar er wordt hier gevraagd om een technische oplossing om te voorkomen dat een onverlaat het netwerk plat gooit.

Daarbij zou het nu in theorie ook mogelijk zijn voor de gebruikers het IP adres te hi-jacken met hetzelfde probleem tot gevolg, alleen dan nu zonder dat het duidelijk is dat het van de monteur af komt...

@mouk
Hoe is jullie netwerk opgezet? Hebben jullie 1 groot plat netwerk? Of segmenteren jullie?

[MrMonkE]

Tsurany schreef op zaterdag 28 december 2019 @ 10:14:
Waarom mag een monteur een apparaat op jullie netwerk aansluiten dat IP adressen uitdeelt dan wel zelf reserveert?

Ik zou hier eerder naar een procedurele dan een technische oplossing kijken.

Wie zegt dat het mag dan?

Daarnaast hadden wij wel 'procedurele' oplossing door regels te hebben maar het hele gebouw (+-1500 werkplekken) was in rep en roer door een netstorm omdat iemand zelf een router had neergelegd buiten IT om.
Handig zo'n extra poortje op je buro. Hele bedrijf plat. Dus je kunt wel regels hebben maar je moet dan vertrouwen dat mensen die volgen. Dat is een .. laat ik het een optimistische gedachte noemen.
Dus gewoon afdwingen met techniek waar het kan.

[MisteRMeesteR]

Schopje naar NT

[unezra]

MrMonkE schreef op zaterdag 28 december 2019 @ 11:06:
[...]


Wie zegt dat het mag dan?

Daarnaast hadden wij wel 'procedurele' oplossing door regels te hebben maar het hele gebouw (+-1500 werkplekken) was in rep en roer door een netstorm omdat iemand zelf een router had neergelegd buiten IT om.
Handig zo'n extra poortje op je buro. Hele bedrijf plat. Dus je kunt wel regels hebben maar je moet dan vertrouwen dat mensen die volgen. Dat is een .. laat ik het een optimistische gedachte noemen.
Dus gewoon afdwingen met techniek waar het kan.

Hangt van de setup af.
Ik gok dat het in geval van TS niet gaat om een omgeving met 1500+ werkplekken.

Bij ons (gebouw waar we zitten) hebben we ook dat soort zaken actief (dmv Cisco ISE), maar da's een omgeving van 3500 werkplekken. Voor de verhuizing, 40 werkplekken, had ik het niet. Niet nodig. Procedure was voldoende.

Daarom is de basis een procedure en regels, niet een technische oplossing. Technische oplossingen kosten geld en dat is het lang niet altijd waard of nuttig.

[RP6conrad]

White list met mac-adressen ? Mac-adres onbekend = geen toegang en geen IP. Komt natuurlijk een hele boekhouding met mac-adressen bij kijken. Bij draadloos is normaal sowieso beveiligd, heb je een wachtwoord nodig.

[Frogmen]

Dit soort hobby gedrag was normaal voor 2000 maar tegenwoordig moet je zo iemand echt uit je pand verwijderen en zijn werkgever verwittigen dat hij niet meer welkom is. Heb zelf jarenlang een facilitair VLAN beheerd ooit een monteur gehad die even een portscan deed (was bij een bank met goed netwerk beheer die mij op de hoogte brachten) de monteur heel erg duidelijk gemaakt dat het eens maar nooit weer was.
En ja wees inderdaad zo slim om alle facilitaire gebouw beheer meuk zoals toegangs controle camera's klimaat beheer etc in een VLAN te plaatsen. Dat is voor iedereen beter.

[pistole]

Het beste is uiteindelijk een combinatie van beleid en via techniek afgedwongen security. Dus port security op switches is technisch het minste dat je zou moeten doen.

[unezra]

RP6conrad schreef op zaterdag 28 december 2019 @ 11:24:
White list met mac-adressen ? Mac-adres onbekend = geen toegang en geen IP. Komt natuurlijk een hele boekhouding met mac-adressen bij kijken. Bij draadloos is normaal sowieso beveiligd, heb je een wachtwoord nodig.

Dat is dus zoiets als Cisco ISE.

Die boekhouding valt wel mee. Wij konden in principe al onze apparatuur (op een paar laptops na) laten whitelisten met 2 regels. Er is puur een match gezet op het vendor ID. (Dat van Igel voor de thin clients en dat van Mitel voor de telefoons.) Met dat, worden niet alleen die apparaten toegestaan, maar komen ze ook meteen in het juiste vlan terecht.

Alleen een wachtwoord op draadloos is tricky, ik zou dat op zijn minste koppelen aan iemands AD account en een eventueel gasten WiFi regelmatig (1x per maand) wijzigen.

ISE gaat ver, maar ook een simpele Cisco kun je prima mac filtering op doen.
Even snel gegoogled:
https://www.cisco.com/c/e...ence/lsw_book/lsw_m1.html

Bovenstaand lijkt me een goed startpunt.

[Wim-Bart]

MrMonkE schreef op zaterdag 28 december 2019 @ 11:06:
[...]


Wie zegt dat het mag dan?

Daarnaast hadden wij wel 'procedurele' oplossing door regels te hebben maar het hele gebouw (+-1500 werkplekken) was in rep en roer door een netstorm omdat iemand zelf een router had neergelegd buiten IT om.
Handig zo'n extra poortje op je buro. Hele bedrijf plat. Dus je kunt wel regels hebben maar je moet dan vertrouwen dat mensen die volgen. Dat is een .. laat ik het een optimistische gedachte noemen.
Dus gewoon afdwingen met techniek waar het kan.

Geen microsegmentering met multiple Vlans? Dan heeft alleen maar een klein Cluster van gebruikers problemen.

[MrMonkE]

Wim-Bart schreef op zaterdag 28 december 2019 @ 18:54:
[...]

Geen microsegmentering met multiple Vlans? Dan heeft alleen maar een klein Cluster van gebruikers problemen.

Ik weet alleen dat ze als gekken door het gebouw aan het rennen waren met een mobieltje en her en der pachtkasten ontkoppelde om zo uit te vinden waar het probleem zat. Lo-tech. Dit was wel een jaar of 10-12 terug, ik denk dat ze inmiddels de zaken beter op orde hebben. Al was het alleen maar omdat de techniek voortgeschreden is.

microsegment VLANs? Weet ik niet. Conceptueel weet ik wel het een en ander maar de implementatie heb ik geen kaas van gegeten. Ik was developer daar destijds. Wat die netwerk gasten allemaal uitspookten weet ik niet.

Zolang ze de poorten openen voor mijn servers vind ik het allemaal prima.
Nou ja.. tot het hele netwerk plat gaat door een 'roque'-router.

[jimbo123]

unezra schreef op zaterdag 28 december 2019 @ 10:45:
[...]


Ja.

Want een monteur mag nooit zomaar actieve apparatuur plaatsen en moet ICT informeren over dat in zo'n apparaat bijvoorbeeld een DHCP server actief is en wat het IP adres is van het ding. (Of meer: Moet vragen welk IP adres dat ding mag hebben en wat er wel en niet actief mag zijn op het apparaat. Een rogue DHCP server plaatsen en zomaar een IP adres geven aan zo'n apparaat is een heel dikke NOGO.)

Je procedures zijn de eerste borging, techniek komt hier op de 2e plaats.

Maar wat doe je als de receptie medewerkster weer eens vergeet om de monteur te vertellen dat hij zich vooraf bij IT dient te melden? Of als het zo’n domme monteur is die helemaal niet weet wat dhcp is en aangeeft “nee dat doet mijn apparatuur niet”, en het vervolgens wel degelijk zo blijkt te zijn? In de praktijk komt dat echt heel vaak voor.

Ik word vaak enorm kwaad als die dingen gebeuren en wil meteen die monteur het pand uit schoppen. Ik wil hem al weg hebben als hij basis vragen niet kan beantwoorden en ik er geen vertrouwen in heb dat ‘ie niks sloopt. Maar helaas, dat kan niet altijd in de praktijk want “de monteur komt voor iets heel belangrijks”

[unezra]

jimbo123 schreef op zondag 29 december 2019 @ 09:48:
[...]
Maar wat doe je als de receptie medewerkster weer eens vergeet om de monteur te vertellen dat hij zich vooraf bij IT dient te melden? Of als het zo’n domme monteur is die helemaal niet weet wat dhcp is en aangeeft “nee dat doet mijn apparatuur niet”, en het vervolgens wel degelijk zo blijkt te zijn? In de praktijk komt dat echt heel vaak voor.

Ik word vaak enorm kwaad als die dingen gebeuren en wil meteen die monteur het pand uit schoppen. Ik wil hem al weg hebben als hij basis vragen niet kan beantwoorden en ik er geen vertrouwen in heb dat ‘ie niks sloopt. Maar helaas, dat kan niet altijd in de praktijk want “de monteur komt voor iets heel belangrijks”

Hoe komt een monteur in de technische ruimte zonder tussenkomst van ICT?
Receptie hoort helemaal geen sleutel te hebben van die ruimte of kast.

Als beheerder zit je er in de regel ook gewoon naast als zo'n jongen een stuk apparatuur plaatst en als duidelijk is dat meneer of mevrouw de monteur niet weet wat zijn apparatuur doet, heb je alle redenen om 'm die apparatuur niet te laten plaatsen.

[mouk]

Hallo!

Wow wat veel reacties! Geweldig, onder de indruk :-)

Een paar antwoorden: uiteraard hebben we 802.1x security op de 'gewone' poorten van end-user workstations. Dit ging echter om een klimaat beheerings systeem. Zo'n kastje kan je op die manier niet configueren.
Ik heb inmiddels zulke dingen in aparte VLANs, maar vijf jaar geleden nog niet alles. En dit apparaatje zit er al zo lang in, en zat dus nog gewoon op het 'main' vlan.

Dat die monteur daar bij kon, vind ik wel normaal, want het zit gekoppeld aan het klimaat systeem, en zat ook in de techische verwarmingsruimtes. Daar mag zo'n monteur uiteraard bij.

Er stond duidelijk op geschreven welk IP het doosje mocht gebruiken. Dat die monteur toch gewoon iets anders configureerde, en daarna het pand verliet, is natuurlijk heel slecht, en dit wordt ook helemaal niet ontkend.

Wat ik hier vraag is: hoe zou ik dit een volgende keer eerder kunnen ontdekken, of nog liever: onmogelijk kunnen maken.

Voor het "eerder ontdekken" deel heb ik inmiddels arpwatch/arpalert ontdekt. Ga ik na de vakantie implementeren.
Voor het onmogelijk maken heb ik dit specifieke kastje in een ander VLAN gezet, waar ie geen enkele schade meer kan doen.

Maar de laatste dagen hierover doordenked, kwam ik op nog wat wel meer plekken in ons netwerk, waar iets soortgelijks gebeuren kan.

Dus om zoiets in de toekomst te voorkomen de vraag: bestaat er switch config (procurve in ons geval) die ervoor zorgt dat een ip alleen op een bepaalde switch poort geacepteerd wordt? Of alleen in combinatie met een een bepaald MAC adres..?

En nogmaals: super bedankt voor de hoeveelheid interessante discussie hierboven: gewaardeerd :-)

[kosz]

Ja dan moet je denken aan een NAC oplossing, zoals bv. Aruba Clearpass / FortiNAC / Cisco ISE

[mouk]

Hmm. Duidelijk.

Dat is echter misschien overkill, alleen om herhaling hiervan te voorkomen. Ik hoopte op een simple config als:

port-security A1 ip-address 192.168.89.1

en dat hiermee .1 niet meer geaccepteerd zou worden op port A2.

Ik denk dat ik moet accepteren dat wat ik zoek niet op deze manier met een one-liner gedaan kan worden. :-)

Nogmaals heel veel dank voor alle aandacht voor onze vraag.

[Nox]

mouk schreef op zondag 29 december 2019 @ 23:03:
Hallo!

Wow wat veel reacties! Geweldig, onder de indruk :-)

Een paar antwoorden: uiteraard hebben we 802.1x security op de 'gewone' poorten van end-user workstations. Dit ging echter om een klimaat beheerings systeem. Zo'n kastje kan je op die manier niet configueren.
Ik heb inmiddels zulke dingen in aparte VLANs, maar vijf jaar geleden nog niet alles. En dit apparaatje zit er al zo lang in, en zat dus nog gewoon op het 'main' vlan.

Dat die monteur daar bij kon, vind ik wel normaal, want het zit gekoppeld aan het klimaat systeem, en zat ook in de techische verwarmingsruimtes. Daar mag zo'n monteur uiteraard bij.

Er stond duidelijk op geschreven welk IP het doosje mocht gebruiken. Dat die monteur toch gewoon iets anders configureerde, en daarna het pand verliet, is natuurlijk heel slecht, en dit wordt ook helemaal niet ontkend.

Wat ik hier vraag is: hoe zou ik dit een volgende keer eerder kunnen ontdekken, of nog liever: onmogelijk kunnen maken.

Voor het "eerder ontdekken" deel heb ik inmiddels arpwatch/arpalert ontdekt. Ga ik na de vakantie implementeren.
Voor het onmogelijk maken heb ik dit specifieke kastje in een ander VLAN gezet, waar ie geen enkele schade meer kan doen.

Maar de laatste dagen hierover doordenked, kwam ik op nog wat wel meer plekken in ons netwerk, waar iets soortgelijks gebeuren kan.

Dus om zoiets in de toekomst te voorkomen de vraag: bestaat er switch config (procurve in ons geval) die ervoor zorgt dat een ip alleen op een bepaalde switch poort geacepteerd wordt? Of alleen in combinatie met een een bepaald MAC adres..?

En nogmaals: super bedankt voor de hoeveelheid interessante discussie hierboven: gewaardeerd :-)

In Cisco gebruiken we ip arp inspection en ip verify source voor dergelijke gevallen icm een static arp. Geen idee of dat op jullie chassis toepasbaar is en of het helpt tegen static IP's, allicht helpt het je op weg. En ja, aparte vlan's voor je klimaatregelnetwerk e.d. is een goed plan Als iemand dan iets verprutst op zo'n manier dat je als admin alles al hebt gedaan om het te voorkomen hebben ze alleen zichzelf ermee. Wij hebben zelfs voor camera's, klimaat, gbs, parkeersystemen, enz. enz. een eigen vlan. We geven ze het subnet en ip-range mee en verder zoeken ze het uit. Eigen verantwoordelijkheid, je sloopt toch niks van anderen.

Overigens is het voor mij ook algemeen gebruik om ongebruikte poorten af te sluiten, allicht iets met een captive portal te maken als je users wel regelmatig dingen in poorten prikken, ik ken de situatie niet zo goed.

Overigens, als je weet waar non .1x devices zitten kan je die allicht langzaam aan migreren naar een ander vlan (ik zou per type netwerk een vlan opzetten overigens). Lekker een vlan opzetten, testen en dan in een onderhoudswindow die dingen ergens anders heen schoppen. Mits ze dhcp hebben uiteraard

[ Voor 9% gewijzigd door Nox op 30-12-2019 00:04 ]

[mouk]

Hoi @Nox,

Hartelijk dank voor de ip arp inspection en ip verify source suggesties, ik ga eens kijken wat ons procurve chassis op dat gebied in de aanbieding heeft. :-)

En voor de verderse rest: we zijn ongeveer alles wat je aangeeft al gaan doen, over de laatste jaren. Dit klimaat systeem kastje was een overblijfsel van de setup van ruim vijf jaar geleden. Captive Portal doen we op de WiFi (packetfence.org, tevens onze .1x NAC)

Hoe dan ook: dank voor je reactie, ik ga de hp equivalenten van " ip arp inspection en ip verify source" eens uitzoeken.