Bedrijfskritische data op een Linux VPS?

[geerttttt]

Momenteel zijn wij bezig onderzoek te plegen naar VPS oplossingen icm linux. we willen graag een server centraal gehost hebben. Zo hebben wij bijvoorbeeld bij TransIP een prima oplossing gevonden wat ons wel wat lijkt.

Op deze server willen we graag apache plaatsen met een servicedesk achtige tool welke op apache/ruby on rails draait.

Op deze server gaat echter op den duur best veel kritische informatie over onze producten en gevoelige gegevens van klanten op staan. Dit moet dus veilig genoeg zijn dat niet zomaar iemand deze gegevens in handen kan krijgen.

Ik begrijp dat alles in principe hackbaar is natuurlijk, maar hoe groot is dit risico nu eigenlijk, en wat kan ik er tegen doen? Ik snap dat ik de linux bak goed moet dichttimmeren. Onnodige services en processen uitzetten, updaten, firewallen, software proberen veilig te houden en goede passwords kiezen, maar verder?

In principe kan iemand bij transip zomaar de image van deze VPS opentrekken en de data uitlezen toch? En wat als iemand op een of andere manier een van de dagelijkse backups in handen krijgt. Zijn de bestanden dan ook niet zomaar uit te lezen? Ik neem aan dat een linux FS niet standaard encrypted is?

Ik heb wel rondgezocht, maar ervaringsdeskundige tips zouden erg van pas komen

[Achilles]

Nou, dat in principe alles hackbaar is bevestig ik graag. Encryptie pas ik zelf eigenlijk altijd toe als 'vreemden' fysiek toegang hebben alhoewel je er wel vanuit mag gaan dat ze niet zomaar je kastje opentrekken en bekijken

-Het is aan te raden om bijv. de database, webserver en het interne systeem te scheiden (d.w.z: apart te virtualiseren)
-Daarnaast alles en iedereen zo weinig mogelijk rechten geven, dit geld speciaal voor mensen die verder niets met de ict te maken hebben: deze mogen niet instaat zijn iets in de code te kunnen wijzigen. Social Engineering is momenteel nog steeds t grootste gevaar.
-Ook binnen de database alles opsplitsen, eigenlijk mag geen enkel proces onnodig rechten hebben.
Qua firewall natuurlijk elke (onnodige) port blokkeren.

Verder vraag ik natuurlijk om meer informatie Wat voor een os wil je draaien? Welk filesysteem kies je? Ext4?

[Thapous]

Naast updaten, rechten en firewall is het misschien handig om na te gaan denken over hoe je de gevoelige data van klanten/je bedrijf gaat opslaan. Je zou dit ook encrypted kunnen opslaan ipv bang te zijn dat er een medewerker van een hostingbedrijf jouw VPS gaat inzien zonder toestemming. Je zou dit ook kunnen navragen bij de provider natuurlijk, hoe zij hier mee omgaan.

Je kunt beter kijken hoe je met de data op de VPS omgaat, hoe worden die back-ups gemaakt, hoe krijg je ze vanaf de VPS op een andere locatie.

[GlowMouse]

Je hebt niets aan encryptie als decryptie op dezelfde VPS plaatsvindt. RAM kan ook zo uitgelezen worden.

[mjax]

Ik denk dat die "servicedesk achtige tool" je grootste security risico zal zijn. SQL injection, XSS, CRF zijn allemaal (theoretisch) denkbaar met dit soort producten. Vanuit daar zou een "hacker" toegang kunnen krijgen tot je hele VPS.

[deadinspace]

geerttttt schreef op zaterdag 18 mei 2013 @ 01:01:
Ik begrijp dat alles in principe hackbaar is natuurlijk, maar hoe groot is dit risico nu eigenlijk, en wat kan ik er tegen doen? Ik snap dat ik de linux bak goed moet dichttimmeren. Onnodige services en processen uitzetten, updaten, firewallen, software proberen veilig te houden en goede passwords kiezen, maar verder?

Als je goed weet wat je doet kun je dat risico heel klein maken. Echt goed beveiligen is natuurlijk een vak op zich en niet in een paar zinnetjes samen te vatten, maar een beginnetje is in ieder geval:

• Zorg dat echt alleen de hoognodige poorten open staan (voor jullie volstaat wellicht 80 en 22) en configureer de services hierachter goed. Deze services zijn namelijk de wegen waarlangs een indringer binnen kan komen.
• Voor ssh: controleer goed welke accounts "inlogbaar" zijn en voorzie die van een goed wachtwoord. Ga niet laks om met host public key verification. Overweeg public key authentication.
• Zoals mjax terecht opmerkt is die webapplicatie waarschijnlijk het grootste risico qua kwetsbaarheden. Zorg dat die ontwikkeld wordt door iemand die bekend is met de risico's van webapplicaties.
• Hou security updates goed bij.
• Logcheck is ook een aanrader.

In principe kan iemand bij transip zomaar de image van deze VPS opentrekken en de data uitlezen toch? En wat als iemand op een of andere manier een van de dagelijkse backups in handen krijgt. Zijn de bestanden dan ook niet zomaar uit te lezen? Ik neem aan dat een linux FS niet standaard encrypted is?

Ja, dat kan. Maar dat kan met een fysieke server in principe ook (al is het bij een VPS iets makkelijker). Lang verhaal kort: je zult je hoster moeten vertrouwen, want in principe kunnen die altijd bij je data. Ik heb een redelijk positief beeld van TransIP, dus die zou ik wel vertrouwen. Zelf zit ik voor mijn VPSen overigens bij Tilaa, een jong opensource-vriendelijk bedrijfje waar ik erg tevreden over ben

Encryptie kan maar is nutteloos tegen kwaadwillendheid van je hoster. Je moet de encryption key namelijk o de VPS zelf opslaan, dus je hoster kan daar ook gewoon bij. Of je moet de key elke keer aanleveren als je VPS (her)start, maar dat is voor de beschikbaarheid niet ideaal en zelfs dan kan de hoster de key natuurlijk onderscheppen. En in elk geval is het geheugen van je VPS (met daarin eventuele keys) uit te lezen.

Ikzelf heb het wel overwogen maar ervoor gekozen het niet te doen. Het idee spreekt me wel aan, maar ik vond de daadwerkelijk behaalde extra veiligheid wat klein voor de beschikbaarheidsrisico's die bij een degelijke oplossing (dwz: de key extern opslaan) horen.

[Rainmaker]

geerttttt schreef op zaterdag 18 mei 2013 @ 01:01:
Op deze server willen we graag apache plaatsen met een servicedesk achtige tool welke op apache/ruby on rails draait.

Prima

[b][message=40259334,noline]Op deze server gaat echter op den duur best veel kritische informatie over onze producten en gevoelige gegevens van klanten op staan. Dit moet dus veilig genoeg zijn dat niet zomaar iemand deze gegevens in handen kan krijgen.Ik begrijp dat alles in principe hackbaar is natuurlijk, maar hoe groot is dit risico nu eigenlijk, en wat kan ik er tegen doen? Ik snap dat ik de linux bak goed moet dichttimmeren. Onnodige services en processen uitzetten, updaten, firewallen, software proberen veilig te houden en goede passwords kiezen, maar verder?

Precies. Firewall aanzetten, zowel inkomend als uitgaand. Wellicht de database op een aparte server hosten, die niet direct aan het internet hangt (en niet passwordless SSH toelaat vanaf de andere bak).
Een andere mooie oplossing is SELinux, waarmee je de toegang tot de database tot op syscall niveau kunt dichttimmeren.
Console access wil je waarschijnlijk dicht hebben, omdat iemand zo een monitor aan je server kan hangen. In combinatie met full-disk encryptie niet zo erg, maar waarschijnlijk wil je het dicht hebben.

In principe kan iemand bij transip zomaar de image van deze VPS opentrekken en de data uitlezen toch? En wat als iemand op een of andere manier een van de dagelijkse backups in handen krijgt. Zijn de bestanden dan ook niet zomaar uit te lezen? Ik neem aan dat een linux FS niet standaard encrypted is?

Ligt eraan hoe je het installeert. De meeste Linux distro´s geven tijdens de setup de vraag "wil je encryptie?". Het kan binnen Linux vrij transperant worden ingericht (bij het booten is een extra wachtwoord vereist, verder is het een "gewoon" FS).
Als je de vergelijking wil trekken: wat BitLocker doet in Windows, doet LUKS in Linux.

Qua backups: ja, de beheerder van je backup data kan alles uitlezen. Is een beetje de essentie van een backup. Eventueel (mocht je dit echt willen) zijn er oplossingen voor. Bijvoorbeeld een netwerk appliance die de data encrypt voordat het naar de backup server gaat. Een directe tape aan de server hangen kan ook. Of; je laat je backup admin alleen de directory /backup backuppen, waar je dan een GPG encrypted mysqldump o.i.d. ingooit. Maar; je backup daemon draait als root, en kan dus potentieel alles.

Al met al; het is hetzelfde als bij Windows (met uitzondering van het SELinux deel dan); zorg ervoor dat er niet meer draait dan nodig, en niets meer permissies heeft dan nodig. Combineer dat met een goede firewall, en je bent klaar.

Ik heb wel rondgezocht, maar ervaringsdeskundige tips zouden erg van pas komen

Sowieso is het waarschijnlijk handig om iemand met "ervaringskennis" in te huren bij de deployement. Als dit systeem echt zo bedrijfskritisch is als je doet vermoeden, wil je waarschijnlijk ook meer over dingen weten als clustering / high availability / load balancers etc.

Zelf gaan hobbyen en er een half jaar later achterkomen dat iemand de gegevens stilletjes doorsluist naar de concurrent, omdat jij vergat /etc/securetty te configureren, is een stuk ernstiger.

[DAzN]

Volgens mij gaat de vraag voornamelijk over of een VPS anders is wat beveiliging betreft dan een dedicated machine.

Het antwoord moet volgens mij zijn: ja, een VPS is standaard onveiliger dan een dedicated machine / colocatie om de simpele reden dat je bij die laatste twee ook volledige controle hebt over de hardware. Echter, of het een probleem is voor jouw doeleinde, hangt af hoe graag je zaken wilt dichtzetten. Ja, je mag ervan uitgaan dat de provider op een of andere manier bij jouw data kan, al is het maar omdat zij backups maken. De data kun je versleutelen etc.

[The Eagle]

Willen en kunnen zijn twee dingen. Hoe waardevol is je data, en hoeveel mag die bescherming kosten? Wie neemt het risico? Allemaal managementbeslissingen, en bepalend voro je budget en de uiteindelijke oplossing.

Dat jij het als IT afdeling graag wilt, betekent niet dat het ook automatisch kan

[Meulugar]

Wat ik eigenlijk vooral mis in het bovenstaande plaatje:

Wie moeten er tickets kunnen aanmaken? gebeurd dit alleen door je eigen servicedesk?
hang deze pc's in een apart vlan welke je toegang geeft via de firewall vpn/ssh achtige verbinding tot de vps en zorg dat de vps verder niet via het internet te benaderen is. dit in combinatie met bovenstaande adviezen moet je een redelijk veilige omgeving opleveren.

Verder heb ik zelf 5 jaar lang 3 domeinen gehad bij TransIP. super service, proactief wat betreft informatievoorzieningen (zoals laatst met de ddos aanvallen) en eigenlijk geen tot amper downtime gehad. goede tarieven en uberrelaxed beheerconsole( qua domeinen dan). Verder is het denk ik van belang te informeren waar je VPS staat. Als zij bijvoorbeeld de vps weer resellen (amazon) dan zou het voor mij een overweging zijn dit niet te doen.

Hoelang moet de data bewaard blijven? Ben je van plan de databases te backuppen naar een eigen backupserver of wil je de backups ook op een vps bewaren?

Verder wil ik het advies geven om de gebruikte config goed te documenteren, de wachtwoorden uit te printen en in een kluis te bewaren ipv digitaal ergens op het netwerk. Stel dat je eigen netwerk door social enginering of een hackpoging word gecomprimised dan kunnen ze in elk geval niet bij de config / gegevens komen van de vps.

[tc982]

Wij raden meestal aan om er een SSL-Box tussen te zetten. Dat geeft een extra laag aan security voor je applicatie, aangezien deze niet "rechtstreeks" meer te bereiken is. Hierdoor kan je een applicatie bereiken die meerdere poorten gebruikt allemaal over 443. Je hebt ook Virtual Appliances hiervan.

Ik raad je zeker de Juniper SA Virtual Appliance aan!

[CremersDH]

Ik vraag me af of je over een (grote) hoster als TransIP nu echt zorgen zal moeten/willen maken of zij bij je data kunnen komen of niet. Als een bedrijf van dat caliber daar bewust of onbewust misbruik van zal maken, denk ik dat het voorbestaan van zo'n bedrijf ter discussie komt. Klanten zullen dat nooit accepteren. Dat is los van kunnen, natuurlijk... Maar dat blijft een stuk vertrouwen natuurlijk. En dit bedrijf staat en valt bij het vertrouwen dat hun klanten hebben.

Maar technisch is het natuurlijk geen enkel probleem om op een VPS je partitie te encrypten. Met Linux kan je dan denken aan bijvoorbeeld LUKS. Je filesysteem komt dan op een encrypted partitie te staan.
Nadeel is dan wel dat als je server herstart wordt je de encryptie sleutel moet intikken. Automatisch/scheduled rebooten is er dan niet meer bij

[begintmeta]

Alsje je eht zorgen maakt over externe partijen moet je de gegevens intern versleutelen voordat je ze naar extern laat gaan.

[Freezerator]

Vinden je klanten het überhaupt ok dat je de data buiten de deur host? Ik zou als klant hier niet zondermeer mee akkoord gaan

[Joseph]

In dit soort gevallen zouden die servers desnoods in mijn huis staan, achter slot en grendel. Als het echt belangrijke informatie betreft zelfs met camerabewaking in die ruimte..

Mocht er een aanval komen of desondanks alles de server 'compromised' worden, dan kan je meteen de stroomstekker eruit trekken. Liever even down dan je data op straat, want dat kan langslepende gevolgen hebben. En uiteraard ook een goed monitor systeem waardoor je bij voorkeur een SMS krijgt als er iets loos is. Hier zijn heel veel Open Source pakketten voor te vinden.

Ik zou mijn kritische data nooit in de cloud zetten. Gewoon thuis of op de bedrijfslocatie de servers huisvesten. Een Web Application Firewall is trouwens een wassen neus.

[CyBeR]

Joseph schreef op zondag 19 mei 2013 @ 11:17:
In dit soort gevallen zouden die servers desnoods in mijn huis staan, achter slot en grendel. Als het echt belangrijke informatie betreft zelfs met camerabewaking in die ruimte..

Mocht er een aanval komen of desondanks alles de server 'compromised' worden, dan kan je meteen de stroomstekker eruit trekken. Liever even down dan je data op straat, want dat kan langslepende gevolgen hebben. En uiteraard ook een goed monitor systeem waardoor je bij voorkeur een SMS krijgt als er iets loos is. Hier zijn heel veel Open Source pakketten voor te vinden.

Ehm. Ik heb mijn servers in een datacentrum staan op ongeveer zes kilometer afstand tegenwoordig en:
• Daar is camerabewaking in elk gangpad
• Daar zit 24 uur per dag een beveiliger voor de deur die je niet door laat als je niet naar binnen mag
• Daar is per deur een pasjessysteem
• Daar zit een eigen sleutel op mijn rack
• Daar kan ik de stekker van servers er on-demand uitrekken en weer in stoppen. Met ietsje meer moeite kan ikdat zelfs op een schema laten gebeuren, zonder m'n huis te hoeven verlaten
• Daar blijft alles draaien als de stroom in heel Amsterdam uitvalt
• Daar heb ik twee gigabit aan internet terwijl ik thuis blijf steken op een upload van 10 megabit (en dat is als ik meer betaal dan ik nu doe.)

Nee, doe mij maar een DC voor dit soort zaken. Thuis draaien heeft teveel nadelen of enorm hogere kosten.

[Verwijderd]

Joseph schreef op zondag 19 mei 2013 @ 11:17:
Gewoon thuis of op de bedrijfslocatie ...

Thuis en op de gemiddelde bedrijfslocatie heb je geen beveiliging die in de buurt komt van een goed datacenter. Daarnaast heb je doorgaans geen redundant uitgevoerde internetverbinding of stroomvoorziening. En als je die wel hebt zijn ze vrijwel nooit beter dan die van een datacenter.

Bedrijfskritisch betekent dat je er zo goed als altijd bij moet kunnen. Dat moet je niet volledig zelf willen oplossen. De voorzieningen, inclusief fysieke beveiliging, koop je in.

Dus colo in een shared rack met goede voorzieningen om bij te houden of niemand een toetsenbord aansluit, of gewoon een afsluitbaar rack (of half of kwart rack). Server beveiligen met full disk encryption, firewall, remote logging, intrusion detection, en dan het liefst op 2 locaties en met remote backup (encrypted).

Indien het te gevoelige gegevens zijn moet je die niet op apparatuur willen hebben waarop anderen zouden kunnen komen. Virtualisatie op een 3rd party oplossing is dan uit den boze.

[jb044]

Beetje vreemde discussie dit, OP heeft het over een Linux VPS bij een budget hoster en "een ticket systeem dat op apache en ruby draait". Ik denk dan gelijk aan redmine. Kortom het mag allemaal niks kosten.

Zal allemaal heel 'Mission critical' zijn, maar zaken als het helemaal zelf opbouwen van een zeer restrictieve SELinux policy en camera monitoring van de server zijn dan niet de eerste zaken die bij mij opkomen