FTP op bedrijfsnetwerk

[Thaimaster]

Hoe denken jullie over het volgende verzoek:

Voor onze website wil de leverancier via (S)FTP naar een map op een server in het LAN.
Hij wil dit via een vast extern ip adres kunnen benaderen.
Nu kan ik wel onze firewall gaan aanpassen dit gaan inregelen maar ik vraag me af wil ik dit wel?
Denk ik te moeilijk of creëer ik hiermee wel zeker een gevaarlijk gat in onze omgeving.
Hoor graag jullie meningen/suggesties.
We hebben IIS op de server draaien dus dat zouden we kunnen gebruiken voor FTP.

[Kraz]

Als je in de firewall alles goed configureert dan zie ik geen probleem?
Uiteraard je betreffende FTP wel in een DMZ plaatsen.

Voor de FTP software raad ik Filezilla oid aan. Vind ik iets gemakkelijker werken dan IIS.

[DukeBox]

Zet je FTP server in je DMZ en doe synchronisatie tussen je FTP server naar je fileserver (met een ander protocol) naar de betreffende directory. Zo houdt je het zoveel mogelijk gescheiden.

[ Voor 7% gewijzigd door DukeBox op 24-10-2014 13:27 ]

[borft]

Gebruik hoe dan ook geen plain FTP. Eventueel kan je FTPS (FTP over ssl) overwegen. sftp is weer compleet iets anders, dat is een extentie op ssh.

[Thaimaster]

kraz247 schreef op vrijdag 24 oktober 2014 @ 13:24:
Als je in de firewall alles goed configureert dan zie ik geen probleem?
Uiteraard je betreffende FTP wel in een DMZ plaatsen.

Voor de FTP software raad ik Filezilla oid aan. Vind ik iets gemakkelijker werken dan IIS.

Ja in een DMZ zie ik geen probleem maar de server waar het op moet komen te draaien staat in het LAN en moet daar ook in blijven.
Ik geef natuurlijk wel 1 extern ip adres maar toegang dus dat zou het redelijk veilig maken lijkt me als diegene een degelijk beveiligd netwerk heeft.

[RedShift]

VPN geen optie?

[Freee!!]

Laat de leverancier het op een aparte server zetten waar je het zelf weer vanaf haalt.

[ijdod]

Als de leverancier zelf ook van een vast ip gebruik maakt, is dat in basis niet een enorm issue. Dat wil niet zeggen dat dit dan de beste cq veligste oplossing is. Eea hangt uiteraard ook af van het formaat van het netwerk de de vertrouwelijkheid van de informatie.

[CAPSLOCK2000]

Allereerst wil ik me even aansluiten bij het SFTP/FTPS kamp, kale FTP moet je niet meer aan beginnen.
Zelf geef ik de voorkeur aan SFTP met ssh-keys. Dan weet ik tenminste zeker dat ze geen flut-wachtwoorden instellen. Ik heb alleen geen idee of dat ook onder Windows werkt.

Het is goed mogelijk om het allemaal veilig in te richten, maar dat ligt vooral aan jou als beheerder. Hoe ver je moet gaan en hoe groot het risico is ligt nogal aan de omstandigheden. Wat vragen om over na te denken: Is de data waar het om gaat gevoelig of zelfs geheim. Moet de leverancier lezen of schrijven? Staan er andere dingen op de server die gevoelig of geheim zijn? Hoe groot is de schade als er toch iets mis gaat? Vertrouw je de leverancier?

Misschien zijn die vragen wat overdreven maar ik ken de omstandigheden niet.

[Brahiewahiewa]

CAPSLOCK2000 schreef op zaterdag 25 oktober 2014 @ 16:36:
Allereerst wil ik me even aansluiten bij het SFTP/FTPS kamp, kale FTP moet je niet meer aan beginnen.
Zelf geef ik de voorkeur aan SFTP met ssh-keys. Dan weet ik tenminste zeker dat ze geen flut-wachtwoorden instellen. Ik heb alleen geen idee of dat ook onder Windows werkt...

Yup. Niet native weliswaar, maar d'r zijn 3^rd-party SFTP clients (WinSCP bevobbeld)

[DukeBox]

Omdat helaas veel mensen en mkb e.d. geen kennis (/eigen ict afdeling) hebben en daardoor FTP vaak (volgens hen) de enige optie is zou je ook met sessie wachtwoorden kunnen werken.
Zo hebben wij een HTTPS internet pagina waar de gebruiker zijn wachtwoord ingeeft en dan een wachtwoord terugkrijgt wat alleen voor de eerst volgende sessie (en binnen x aantal uur) geldig is.
Op deze manier kan misbruik van de FTP server vrijwel voorkomen worden.
Dit uiteraard alleen wanneer het voor de data zelf geen probleem is om deze unencrypted te verzenden.

Maar indien mogelijk zou ik er toch voor kiezen om SFTP of via bijv. google drive te werken. Let er wel op dat bij veel andere file transfer sites er issues zijn met vrijwaring van rechten e.d.

[Croga]

DukeBox schreef op zaterdag 25 oktober 2014 @ 20:05:
via bijv. google drive

We proberen het te beveiligen en jij adviseert om het hele spul maar meteen de wijde wereld in te gooien?! Waarom zou je de volledige controle over de beveiliging willen geven aan een derde partij die al bewezen heeft dit niet, én niet veilig te kunnen, laat staan zelf de inhoud van die bestanden gebruikt.

Waar ik me nog wel serieus zorgen over maak is dat de server waar we het over hebben in het LAN móet blijven staan. Ben ik de enige die daar een serieus probleem ziet? Voor de website zie ik geen enkele reden om de server in het LAN te laten staan.

[DukeBox]

Croga schreef op zaterdag 25 oktober 2014 @ 20:13:
[...]
We proberen het te beveiligen en jij adviseert om het hele spul maar meteen de wijde wereld in te gooien?! Waarom zou je de volledige controle over de beveiliging willen geven aan een derde partij die al bewezen heeft dit niet, én niet veilig te kunnen, laat staan zelf de inhoud van die bestanden gebruikt.

Daar zou ik graag de bron van krijgen. Bij mijn 2 vorige werkgevers en ook mijn huidige gebruiken we al jaren google apps voor onze onderneming en dat zijn geen kleintjes. Geen van de jouw aangegeven punten ben ik ooit tegengekomen. Ook was het anders nooit door enige audit gekomen.. sterker nog PWC die naast de financiele ook de ICT (security) audits doen gebruiken het ook.
Je laatste punt is al helemaal een mythe, dat geld alleen voor gmail (waar overigens een opt out voor is en een opt in voor google apps).

[Rolfie]

Croga schreef op zaterdag 25 oktober 2014 @ 20:13:
[...]

We proberen het te beveiligen en jij adviseert om het hele spul maar meteen de wijde wereld in te gooien?! Waarom zou je de volledige controle over de beveiliging willen geven aan een derde partij die al bewezen heeft dit niet, én niet veilig te kunnen, laat staan zelf de inhoud van die bestanden gebruikt.

Op basis waarvan kom je nu weer met deze argumenten?
Ik denk dat Google zijn ICT een stuk beter voor elkaar heeft dan menig ander bedrijf.

Waar ik me nog wel serieus zorgen over maak is dat de server waar we het over hebben in het LAN móet blijven staan. Ben ik de enige die daar een serieus probleem ziet? Voor de website zie ik geen enkele reden om de server in het LAN te laten staan.

We weten niet precies om wat voor een data het gaat. Met SFTP met een firewall allow rule, al dan niet icm met VPN heb je al een hele goede oplossing. Hangt er ook een beetje vanaf van voor een relatie het bedrijf met de leverancier heeft. Daarbij als het de core applicatie van het bedrijf is, bijvoorbeeld CRM, financiële administratie, dan heeft bedrijf al de meeste informatie van het bedrijf.
Daarbij een server in een DMZ, dan hangt er er ook weer vanaf wat voor een webserver is het. Als die bv verbinding heeft met diverse databases, dan is het ook weer niet echt een oplossing.

SFTP is afhankelijk van de omstandigheden misschien wel meer dan voldoende.

[The Eagle]

Als ik de topicstart goedinterpreteer heeft TS de webserver van zijn bedrijf in hun eigen LAN staan, en is er een leverancier die die website beheert en vermoedelijk daarom het LAN in wil. Correct?

Persoonlijk zou ik dan altijd een aparte webserver in de DMZ zetten, of het ding extern laten hosten. Mag die leverancier het ook beheren en up2date houden.
Dikke kans dat dat een stuk goedkoper is dan er zelf tijd in steken om het te hosten, beheren en te onderhouden. Heck, de tijd er in steken om het te laten werken kan al meer kosten dan een VPS voor een jaar.

[Thaimaster]

Om het verhaal iets duidelijker te maken:

- Onze website krijgt een webshop die een koppeling heeft met ons CRM pakket.
- Vanwege relatie/voorraad beheer moet er een synchronisatiemap zijn op een machine in het LAN waar de client software op geinstalleerd is.


Wat heb ik gedaan:

- CoreFTP server geinstalleerd op de server die in het LAN staat en hierop een user aangemaakt met schijfrechten en gekoppeld aan de juiste map.
- In onze firewall een regel aangemaakt die poort 21 en 22 toestaat vanaf het ip adres van de leverancier en via NAT redirect naar de machine die in het LAN staat.
- Verbinding komt tot stand via SSH, gewoon FTP is uitgeschakeld in de software.

Ik denk dat ik op deze manier het beste gedaan hebt.
Bedankt voor het meedenken

[mbaltus]

Als er gebruik gemaakt wordt van SFTP (dus via SSH) waarom staat poort 21 op je firewall dan nog open? Die kun je dan beter sluiten.

[Breezers]

Freee!! schreef op vrijdag 24 oktober 2014 @ 14:46:
Laat de leverancier het op een aparte server zetten waar je het zelf weer vanaf haalt.

Lijkt mij de meest eenvoudige oplossing ?

Een cronjob/polling naar die map en klaar

[ Voor 8% gewijzigd door Breezers op 27-10-2014 17:19 ]

[Croga]

Rolfie schreef op zaterdag 25 oktober 2014 @ 22:03:
Op basis waarvan kom je nu weer met deze argumenten?
Ik denk dat Google zijn ICT een stuk beter voor elkaar heeft dan menig ander bedrijf.

Op basis van algemene publieke kennis....

Google gebruikt data die opgeslagen is op zijn servers voor profiling en wie weet voor wat voor andere doeleinden nog meer. Door je data bij Google te stallen heb je de data expliciet aan hun gegeven.
Daarnaast doet Google zaken in de VS en is alle data dus beschikbaar voor alle bevoegde instanties in de VS. En dat zijn er best veel. Het argument "Ja maar de servers zelf staan niet in de VS" is ondertussen al bewezen zinloos; zie geval MS Ierland.

Je data stallen bij dit soort instanties staat gelijk aan het weg geven van je data. Wellicht op dit moment niet aan iedereen maar dat geeft niet; de instanties maken backups en die verdwijnen niet meer. Ergo: Als de VS zijn wetten uitbreid zodat VS bedrijven ook toegang hebben dan houdt je je bedrijfsgeheimen nooit meer weg van hen.

[DukeBox]

Croga schreef op dinsdag 28 oktober 2014 @ 06:34:
Op basis van algemene publieke kennis....

Op basis van jou verkeerde perceptie van google bedoel je.

[CAPSLOCK2000]

Het één sluit het ander niet uit. Google kan zowel technisch superieur zijn als juridisch inferieur. Dat is IMHO meer iets voor juristen en managers dan voor technici en raakt wel erg ver van de oorspronkelijke vraag. Misschien hier een draadje over starten in BV (als dat er nog niet is)?