Wat is veiliger: SSH of DMZ?

[Verwijderd]

Ik ben zelf geen netwerkspecialist, maar vooral bezig met websites en koppelingen met back office systemen. Omdat veiligheid heel belangrijk is vraag ik mij af wat jullie vinden. Ik wil hiermee dus eigenlijk een discussie starten.

We hebben situaties A en B in de praktijk draaien, mijn vermoeden is dat situatie B veiliger is.

Stel: je wilt een website koppelen met een back office systeem. Gegeven is dat er een server (Windows) in het netwerk is van het back office systeem en een website op een webserver (Linux) ergens anders in Nederland. Ontwikkelaars van het back office systeem stellen als eis dat er een speciale, aparte koppelserver (Windows) in het netwerk opgenomen wordt met een drive mapping naar de server. De webserver koppelt via HTTP met de koppelserver.

Situatie A: de firewall wordt zo geconfigureerd dat de koppelserver in een DMZ komt. De webserver maakt via HTTP verbinding met de koppelserver en de koppelserver met behulp van de drive mapping met de server (niet in de DMZ, maar in het netwerk). Als extra beveiliging wordt alleen toegang tot de koppelserver gegeven via een beperkte set IP-adressen en een beperkte set poorten.

Situatie B: een extra server (Linux) wordt gebruikt met een SSH-server geïnstalleerd. De firewall laat alleen verkeer voor een SSH-poort door en alleeen naar de extra server. Wanneer ingelogd op de extra server kan via port forwarding de koppelserver bereikt worden, de koppelserver is binnen het netwerk geplaatst en de koppelserver maakt met behulp van de drive mapping verbinding met de server.

Situatie B alternatief: situatie B maar in plaats van een extra server wordt een SSH-server op de koppelserver geïnstalleerd (bijv. met Cygwin).

[RedRose]

1) Waarom een aparte koppelserver? Wordt er ontwikkeld op de back-office server? Dan is dat een development server en is je 'koppelserver' je back-office server?

2) Welke services draaien er op de back-office server die de HTTP-server nodig heeft?

3) Zware loads en netwerktraffic?

[Verwijderd]

1/2) Koppelserver is een eis van de makers van het back office systeem. Even snel gezegd draait op de back office server een Pervasive database. Binnen het netwerk zijn clients op de diverse werkstations die de Pervasive database gebruiken. Op de koppelserver is een speciale client (DCOM) die dezelfde database gebruikt. Ze willen niet die speciale client op de server draaien omdat ze daar problemen mee hebben ervaren.

Wij hebben vervolgens op de koppelserver IIS en .NET Framework geactiveerd en met C# een web service geschreven die het DCOM-object aanroept. De webserver consumeert de web service.

3) zware loads en netwerktraffic vallen beiden wel mee, wat wil je precies weten?

[RedRose]

Ok, ik snap het. Vraag 3) was meer bedoeld als algemene vraag. Laatste vraag: waarom SSH? Je kan ook SSL gebruiken tussen de HTTP-server en de koppelserver op poort 443.

.edit:

Ik zou dus wel de koppelserver (Windows) in het netwerk zetten, in een DMZ en dan alleen COM+ verkeer en SMB-verkeer toestaan vanaf het interne netwerk. Naar buiten toe alleen requests van je webserver toelaten, op poort 443 via SSL. Eventueel kan je ook een IPSEC-tunnel gebruiken tussen de HTTP-server en de koppelserver. Dat lijkt mij veilig genoeg.

[ Voor 53% gewijzigd door RedRose op 06-10-2004 11:42 ]

[Verwijderd]

SSH zodat er een extra stap is, namelijk inloggen met gebruikersnaam/wachtwoord.

Maar ik ben vooral geïnteresseerd of de twee verschillende situaties nou veilig zijn, even veilig of dat er een verschil tussen zit.

[Verwijderd]

Zoals Redrose zegt, tussen de twee firewalls een ipsec tunnel en op de backoffice server alleen verkeer van die linux accepteren, is het overigens niet handiger om
met ftp gegevens over te dragen dan met remote shares ?

[Verwijderd]

Met FTP!? Het is een realtime koppeling. De drive mapping heeft het back office systeem nodig voor communicatie met de database.

Maar okay, de DMZ-opstelling is veilig, wat nu over de SSH-opstelling? Is die net zo veilig of veiliger?

[RedRose]

Ik begrijp nog steeds niet wat SSH doet in het verhaal, in de veronderstelling zijnde dat het om permanent aanstaande verbindingen gaat waarbij software op een veilige manier met elkaar moet communiceren.....

Het is allebei net zo veilig, eventuele brakke password-policies, monitoring en lekken in software daargelaten.

[SSH]

Ik heb me laten vertellen dat SSH het veiligste(een van de) stukje communicatie software is. Met een goed password is dat zo goed als onmogelijk te cracken/hacken.

Ik poort ook alles door SSH en vind het prima werken

[Verwijderd]

Nog niet de discussie die ik gehoopt had. Misschien zijn, zoals RedRose zegt, allebei de opstellingen even veilig en is het gevaar alleen in de mensen die het gebruiken...

[leuk_he]

In situatie A zit 1 onveiligheid:

Stel de server Naast de pubblieke webserver wordt gekraakt . Men gaat daar sniffen op "opvallende" verkeer. Dan ziet men dat de publieke webserver http verkeer heeft met de DMZ server. aangezien dit dit niet geencrypt is (http) is dit leesbaar, en kan dus nagedaan worden. Als je pech hebt valt het ip van de gekraakte server in de toegestande range en is met dus binnen op de DMZ.

[Verwijderd]

leuk_he schreef op 19 oktober 2004 @ 11:46:
In situatie A zit 1 onveiligheid:

Stel de server Naast de pubblieke webserver wordt gekraakt . Men gaat daar sniffen op "opvallende" verkeer. Dan ziet men dat de publieke webserver http verkeer heeft met de DMZ server. aangezien dit dit niet geencrypt is (http) is dit leesbaar, en kan dus nagedaan worden. Als je pech hebt valt het ip van de gekraakte server in de toegestande range en is met dus binnen op de DMZ.

helemaal niet... dan moet je dus nog de "koppelserver" kraken.

het snif argument is niet boeiend want ssh verkeer kan je ook lezen (niet de data maar da's niet boeiend in dit geval!), maar zelfs als dat nog een echt argument is, is sniffer installen op een webserver (via http) en sniffer aanzetten en uitlezen allemaal zoveel werk dat je daar niet bang voor hoeft te zijn, tenzij het om echte cracks kan gaan... (way to advanced voor de gemiddelde scriptkiddie)

[Jazzy]

Het voordeel van een DMZ is dat je de veiligheid van je interne netwerk kunt vergroten en waarborgen. Je configureert je firewalls zo dat er nooit verkeer rechtstreeks van extern naar intern kan. Zo zou je bijvoorbeeld een webserver in de DMZ wel kunnen toestaan om naar intern SQL te praten maar dat er nooit SQL verkeer naar extern mag.

[Equator]

Jazzy schreef op 19 oktober 2004 @ 13:35:
Het voordeel van een DMZ is dat je de veiligheid van je interne netwerk kunt vergroten en waarborgen. Je configureert je firewalls zo dat er nooit verkeer rechtstreeks van extern naar intern kan. Zo zou je bijvoorbeeld een webserver in de DMZ wel kunnen toestaan om naar intern SQL te praten maar dat er nooit SQL verkeer naar extern mag.

Eventueel kan je de webserver in je DMZ alleen maar SQL latten babbelen over een IPsec verbinding of over een secure VPN.
Desnoods, door een ssh tunnel.

Van buiten af, kan men alleen met de http poort naar binnen (DNAT of ACL).

Veel gekker moet je niet maken. security by obscurity

[leuk_he]

Verwijderd schreef op 19 oktober 2004 @ 13:31:
[...]
helemaal niet... dan moet je dus nog de "koppelserver" kraken.

het snif argument is niet boeiend want ssh verkeer kan je ook lezen (niet de data maar da's niet boeiend in dit geval!),

Ik ben het zondermeer met je eens dat de DMZ is script kiddy safe is. Echter het het argument van security is dat je voor de 100% moet gaan. Anders volstaat een personalfirewall ook. Daar komt een scriptkiddy ook niet voorbij.

[Verwijderd]

Jazzy schreef op 19 oktober 2004 @ 13:35:
Het voordeel van een DMZ is dat je de veiligheid van je interne netwerk kunt vergroten en waarborgen. Je configureert je firewalls zo dat er nooit verkeer rechtstreeks van extern naar intern kan. Zo zou je bijvoorbeeld een webserver in de DMZ wel kunnen toestaan om naar intern SQL te praten maar dat er nooit SQL verkeer naar extern mag.

daarom wordt er gebruik gemaakt van de "koppelserver"

sql verkeer over ipsec zou ik ook gebruiken, alhoewel er dikke kans is dat als je de koppelserver kan hacken dat je dan ook de servernaam/ip, inlognaam en pw wel ergens kan vinden in een of ander inc filetje.

De sql server zou echter al de 3de hop zijn en dan ben je toch echt geen scriptkiddie meer

[Verwijderd]

leuk_he schreef op 19 oktober 2004 @ 15:00:
[...]


Ik ben het zondermeer met je eens dat de DMZ is script kiddy safe is. Echter het het argument van security is dat je voor de 100% moet gaan. Anders volstaat een personalfirewall ook. Daar komt een scriptkiddy ook niet voorbij.

100% is natuurlijk alleen mogelijk als je geen inetconnectie hebt en al je input devices van je machine afsloopt.

verder wil je een werkbare situatie creeren en niet ongelovelijke hoeveelheden (valse) security inbouwen.