Risico's van een publiek IP adres

[kattapult]

Wie kan er eens mee denken;

Mijn vrouw heeft een eigen bedrijfje met een klein aantal medewerkers. Voor dit bedrijfje hebben ze een callcenter ingehuurd om klanten te woord te staan. Omdat klantgegevens tot een beperkte hoogte ingezien moeten worden, heeft dit call center toegang tot de bedrijfsapplicatie. Toegang is normaliter afgesloten, maar op basis van het werken met IP restricties/permissies heeft het call center toegang .

Nu wil het zo dat dit callcenter gaat verhuizen naar zo'n business park; zeg maar een flex-kantoor waar meerdere bedrijven in zitten. Nu veranderd het IP adres dus naar het IP adres van dat flex-kantoor (waar dus meerdere bedrijven opzitten).

Mijn vrouw is geen ICT'er, maar hield deze situatie toch eens tegen mij aan.. ik vroeg mij nu af, in hoeverre zijn er nu echt risico's gebonden aan het toegang geven van zo'n IP adres van een 'publieke locatie' tot de bedrijfsapplicatie. In hoeverre kunnen andere bedrijven hier nu bijvoorbeeld misbruik van maken?

Ik vind het lastig hier nu een vinger achter te krijgen.. ik was benieuwd hoe jullie dit zien?

[shure-fan]

Met een goede router aan jou kant, kun je aangeven wat er met een bepaald extern ip adres moet gebeuren,

Dit zijn overigens wel Linux achtige routers, (monowall, pfsense)

[dion_b]

Alleen een IP-adres zegt weinig over beveiliging. Hoe wordt die verbinding opgezet en beveiligd?

[luxan]

Het risico hangt af van de beveiliging op de bedrijfsapplicatie zelf. Indien er geen login gegevens nodig zijn om klantgegevens in te zien, kan iedereen die op het flexkantoor werkt deze gegevens zonder problemen inzien. Ik zou dit een onacceptabel risico vinden en ik vermoed dat het in strijd is met de wet op bescherming persoonsgegevens.

Indien er ingelogd dient te worden om klantgegevens in te zien of als de applicatie alleen bereikt kan worden via een VPN tunnel, is het risico minder groot.

[kattapult]

dion_b schreef op vrijdag 02 oktober 2015 @ 11:41:
Alleen een IP-adres zegt weinig over beveiliging. Hoe wordt die verbinding opgezet en beveiligd?

Betreft een webapplicatie.. gehost bij een externe service partij.. HTTPS verbinding waarbij eindgebruiker met username + ww moet inloggen

[enterz]

Als de enige vorm van veiligheid is de afscherming op IP adres dan is dit alles behalve veilig.
Je weet nooit wie er meekijken op het publieke netwerk (geautomatiseerd dan wel via een raam in 't kantoor.)

Ligt ook een beetje aan wat voor gegevens het zijn, maar dit kan best fraudegevoelig zijn. Dat wil je als bedrijf niet op je hals halen lijkt me als daar iets mee gebeurd!

Met andere woorden, zorg voor betere security. Het toevoegen van een password bijvoorbeeld is al een stap in de juiste richting!

[begintmeta]

Ik zou de ip-adres-restrictie gewoon even buiten beschouwing laten, dan gaat het er dus om of de webapplicatie voldoende beveiligd is. Als dat zo is (je geeft aan gebruikersnaam+wachtwoord over https, in hoevere is de webapp ontwikkeld met het oog op veiligheid?), kan je vervolgens kijken naar wat een ip-adres-restrictie toevoegt. In mijn ogen is dat niet enorm veel.

[ Voor 25% gewijzigd door begintmeta op 02-10-2015 11:47 ]

[FreakNL]

Het zal heus niet alleen beveiliging zijn middels IP. Dat is namelijk makkelijk te spoofen, dus daarmee loop je in de huidige situatie ook al een enorm risico, ook al zijn er nu geen andere bedrijven die via dat IP binnenkomen.

Ik lees dat er ook een inlog is via HTTPS met username/pass, dat maakt het al een stuk veiliger.

Als ze de veiligheid echt 100% willen garanderen moet je een Site-2-Site gaan leggen tussen beide bedrijven of het callcentre remote access geven middels tokens/rdp/citrix whatever..

Maar ik zie hier niet zo heel veel security issues, die toegang middels IP was sowieso al een wassen neus.

Wat je ook nog kan doen is een token of sms authenticatie toevoegen aan de standaard inlog...

BTW,
Zonder een sneer te willen geven, maar je bent (volgens je post historie) IT Compliance & Security Officer met een salaris om trots op te zijn. Dan hoef je voor een simpele case als dit toch geen advies te vragen? Een beetje security officer zou daar toch zeker zelf wel 99 over moeten kunnen roepen?

[ Voor 17% gewijzigd door FreakNL op 02-10-2015 11:50 ]

[Atomsk]

FreakNL schreef op vrijdag 02 oktober 2015 @ 11:47:
Het zal heus niet alleen beveiliging zijn middels IP. Dat is namelijk makkelijk te spoofen, dus daarmee loop je in de huidige situatie ook al een enorm risico, ook al zijn er nu geen andere bedrijven die via dat IP binnenkomen.

Je overschat IMO nogal de mogelijkheden van IP spoofing. Wanneer je standaard geen toegang hebt tot een server op een bepaald IP adres (vanwege de IP beveiliging) en weet je niet hoe het interface van die server eruit ziet, dan kun jet met IP spoofing weinig tot niets. Je kunt namelijk wel verkeer naar die server sturen uit naam van het vervalste adres, maar het retourverkeer krijg je nooit te zien.

Enfin, inlog zou op zich voldoende moeten zijn, zolang het wachtwoord voldoende sterk is en een aanvaller niet brute force te keer kan gaan.

[NoepZor]

Als het een webapplicatie is en je weet de URL, dan kun je natuurlijk wel gewoon connecten met een spoofed IP. Als het een API of server interface is die een specifieke taal spreekt, dan moet je de boel helemaal uitpluizen/reverse engineeren.

[luxan]

NoepZor schreef op vrijdag 02 oktober 2015 @ 12:30:
Als het een webapplicatie is en je weet de URL, dan kun je natuurlijk wel gewoon connecten met een spoofed IP.

Dat punt heeft Atomsk net gemaakt. Als je verder leest zie je dat je het retourverkeer niet te zien krijgt waardoor het spoofen van het IP adres een nutteloze actie is.

NoepZor schreef op vrijdag 02 oktober 2015 @ 12:30:
Als het een API of server interface is die een specifieke taal spreekt, dan moet je de boel helemaal uitpluizen/reverse engineeren.

En waarom zou je met een API of server interface geen IP spoofing kunnen toepassen?

Punt is dat IP spoofing er alleen maar voor zorgt dat je kunt zenden. Om het antwoord te kunnen ontvangen zul iets meer moeten doen (lees de juiste router hacken). Anders gaat het echt niet werken. Ook niet als je alle URL's van de web applicatie uit je hoofd leert.

[leuk_he]

Als er meer dan poort 443 open staat dan is uiteraard de hele server publiek. Als daar meer services op draaien zijn deze opeens semi publiek.

(naast uiteraard de punten: screen je je call center medewerkers, is toegang tot de call center ruimtes beperkt, of redelijk semi publiek. Wat voor garanties geeft je call-centrum als er fouten gemaakt worden daar., maar goed, dat was niet de vraag)