XS4ALL wijst kritiek HIT2000 op beveiliging van de hand

XS4ALL vindt de kritiek van HIT2000 op de beveiliging van de hostingactiviteiten onterecht. De provider is het vooral oneens met het advies van de beveiligingsgroep dat e-commercesites beter geen gebruik kunnen maken van de 'security faciliteiten' van XS4ALL. De constatering van HIT2000 dat het mogelijk was in 'alle directories te kijken' is volgens de provider weliswaar terecht, maar niet specifiek voor het platform van XS4ALL. Men vindt dat het aan de bouwers van de site is om zelf de content van de website te beveiligen:

"Het heeft niets te maken met het platform van XS4ALL. De fout, voor zover het al een fout te noemen is, doet zich ook voor bij andere providers als Vuurwerk of UUNet. Bovendien is het probleem bij ons al anderhalf jaar bekend." Volgens Pelleboer verschijnt binnen een paar maanden nieuwe software die een 'fundamentele oplossing' voor het probleem levert.

[...] "Een site is in hoge mate te beveiligen, maar de bouwer van de site moet dat zelf doen. Dat maakt een site echter wel duurder, en mogelijk dat sommigen het daarom niet doen. Een gerenommeerde sitebouwer zal een klant echter wijzen op de problemen en adviseren de boel dicht te zetten", zo zegt Pelleboer.

Fiets even langs WebWereld voor het volledige artikel.

Reacties (22)

[Tjark]

Groot gelijk op dit punt. Als je op een colocationsysteem zit (dus met meerdere mensen op 1 server o.a. met virtual servers) en iemand is zo dom om z'n rechten op 777 te zetten dan is het niet de fout van het systeem of XS4All dat derden zo'n site kunnen verkloten/hacken.

[Aaargh!]

Wel als die rechten default op 777 staan.

[Verwijderd]

755 ligt meer voor de hand dan kun je alle directory's lezen enzo.
7= lezen , schrijven en uitvoeren
5 is lezen en uitvoeren
755 staat voor dat owner alles mag en zijn groep en de rest er alleen in mag lezen en dat lijkt me het meest logische.


(typo's verbeteren)

[NightBird]

En dat was nou precies datgene wat is gebeurd.

Gewoon weer de gerbruikelijke grootpraat van HIT2000. Veel geloei maar weinig zegmaar

[Jaymz]

Tot die tijd is het aan de bouwers van de site zelf om de content van de website te beveiligen, aldus Pelleboer. XS4ALL claimt klanten te wijzen op te nemen maatregelen en ook de benodigde middelen ter beschikking te stellen. "Wij geven allerlei sleutels. Maar als iemand die sleutels onder de mat voor de deur legt, houdt het op", aldus Pelleboer.

(quote vanaf WebWereld)

Ik vind dit een hele goede vergelijking.

XS4ALL bied een gevangenis aan, maar de bewaarders (degene die een site laten hosten) moeten zelf de deuren op slot zetten).

Als er ergens een gaatje in een site zit, ligt het aan de huurder. XS4ALL heeft mijn inziens wel de verpliching om de klant te helpen bij het beveiligen.

Ik denk zelfs dat XS4ALL er slim aan doet om de klant te adviseren, is namelijk erg goed voor je naam.

[edit: Typo]

[Verwijderd]

gerrie ik doe alles om op webwereld te komen mansieur is weer bezig.

Deze gozer die achter #hit2000 zit ( niet te verwarren met het irc kanaal #hit2000 ( irc.xs4all.nl). Verklaard slechts onzin of zaken die achterhaald zijn. Dit is bij de insiders (hackers) allang bekend. Echter door vaak webwereld kranten etc. te mailen hoopt i wat winst te maken met zn bedrijfje ( een flop ) #hit2000

Deze jongen is echter een flapuit niet serueus en media geil. Ookal issie opgekouwd en uitgespuugd door de hackwereld hij doed 't keer op keer weer.

even wat reacties van mede hit2000 bewonders op ircnet

[18:17] <sync-> wat een heerlijk gelul weer
[18:17] <sync-> ik schaam me bijna om in dit kanaal te zitten
[18:17] <sync-> ik ben het 100% eens met xs4all
[18:17] *** InZ|gone is now known as InZ-
[18:18] <sync-> de content van je web securen is zaak van degene die hem bouwt
[18:18] <^herman^> tuurlijk
[18:18] <sigmo> idd

</rant mode off>

Ik hoop dat die loozer 't ooit nog is afleerd

vooral omdat hij xs4all hit2000 en providers die goed hun best doen in discrediet brengt ..

groet herm.

[Verwijderd]

Bovendien is het probleem bij ons al anderhalf jaar bekend

Als het probleem zo lang bekend is bij XS4ALL, waarom hebben ze het dan niet gefixed? Als ik dit als klant zou lezen zou ik dat wel HEEL graag willen weten. Goed voor het vertrouwen zo'n uitspraak... not.

Een gerenommeerde sitebouwer zal een klant echter wijzen op de problemen en adviseren de boel dicht te zetten

En dat betekend dat een gerenomeerde host dit mag verzaken? Lekker makkelijk om zo de verantwoordelijkheid weg te schuiven.

Deze argumentatie rammelt aan alle kanten en stinkt naar marketing, meneer Pelleboer. Gelukkig heeft u meer verstand van het weer.

[roelkw]

Als het probleem zo lang bekend is bij XS4ALL, waarom hebben ze het dan niet gefixed? Als ik dit als klant zou lezen zou ik dat wel HEEL graag willen weten. Goed voor het vertrouwen zo'n uitspraak... not.

Maar het ís ook niet echt een probleem vind ik. Ik heb ook een abonnement bij xs4all (ADSL) en ik moet zeggen dat ik heel errug tevreden ben over xs4all. Je kunt idd door de directory's browsen, maar dat is ook gelijk je eigen fout.

Misschien is het iets minder veilig, maar ik moet zeggen dat ik het toch wel errug prezierig vind, aangezien ik gewoon een map heb aangemaakt met downloads. Ik hoef dan dus niet elke keer m'n index.html aan te passen!

[Verwijderd]

uhm, het gaat hier om e-commerce platformen. Daar moet geld aan verdient worden. Voor particulieren is dit verhaal misschien geen struikelpunt. Als bedrijf ligt dat net een beetje [erg] anders.

Zou jij het spul waar jij je geld mee moet verdienen graag onbeveiligd op straat zetten? Om maar te zwijgen van de privegegevens die omgaan tijdens transacties en dergelijke.

[Crazy D]

Zou jij het spul waar jij je geld mee moet verdienen graag onbeveiligd op straat zetten? Om maar te zwijgen van de privegegevens die omgaan tijdens transacties en dergelijke.

Naa, maar dan moet je de deur niet open laten staan. je kan moeilijk de verhuurder de schuld geven als jij de deur niet op slot doet.
Tenzij er helemaal geen slot aanwezig is...
Nu weet ik niet hoe goed beveiligd en zo je zo'n site 'krijgt' als je je siteje gaat bouwen, en hoe makkelijk/moeilijk je met hun tools de site kan beveiligen, dat zou het een en ander kunnen wijzigen in mijn mening, maar anders vind ik dat degene die de site bouwt verantwoordelijk is.
(al zou het natuurlijk een goeie service zijn als XS4ALL af en toe wat checkt en de eigenaars een seintje geeft als het niet veilig is )

[Verwijderd]

Ik denk dat je zo iets kunt vergelijken met een auto verhuurd bedrijf,

de huurder is zelf verantwoordelijk voor zijn parkeer bonnen en snelheids overtredingen die hij maakt met de gehuurde auto en de verhuurder blijft wat dat betreft buiten schot.

[Jaymz]

Totdat blijkt dat het autoverhuurbedrijf z'n auto's slecht onderhoudt.

De vraag is alleen, waar trek je de grens. Wat is de verantwoordelijkheid van XS4ALL, en wat die van de huurder.

Met een beetje pech/geluk (ligt eraan, aan welke kant je staat) kun je hier een leuke rechtszaak van maken, als blijkt dat je site lek is, en de verantwoordelijkheidszaak in het midden ligt.

[edit:Typo]

[KMK]

Bovendien is het probleem bij ons al anderhalf jaar bekend." Volgens Pelleboer verschijnt binnen een paar maanden nieuwe software die een 'fundamentele oplossing' voor het probleem levert.

Dit vind ik een slechte zin. Als je dan al weet dat er dit aan de hand is ga er dan geen software voor ontwikkelen anders vind je het dus wel een probleem. En dat je dit ook al 1,5 jaar weet maakt het alleen maar slechter. Dus zeg dan van: "Zoek het zelf maar uit want het is ons probleem niet, of huur ons in om het op te lossen." dan sta je wel goed

[nielsj]

Het probleem is eigelijk dat wat vroeger common knowledge was. (file premissies en verschil in groepen).

dat is 'tegenwoordig' ls-, of dir- hacking geworden.

[Verwijderd]

Ook al zet je je directories op 750 (aangenomen dat ze eigendom zijn van bijvoorbeeld de groep apache zodat de webserver er wel bij kan) dan nog heb je dat probleem als er geen suexec wordt gebruikt op die server. CGI scripts van anderen draaien dan namelijk onder de groep apache zodat je via cgi scripts alsnog in andermans directories kan kijken.
Op deze wijze is trouwens ook de TMF site ooit gehacked

[Jit]

'alle directories te kijken'

OK, bij mijn weten ging dit om de hostingfaciliteiten, wat over het algemeen inhoud dat ze iets als websites en ftp-sites hosten... waarom klagen ze dan dat die voor iedereen leesbaar zijn?
Je wilt toch over het algemeen dat die sites leesbaar zijn voor iedereen? Als ik m'n www-directory op 700 zou zetten ipv 755 dan krijg ik nooit iemand die commentaar op m'n website wil geven.... niet bepaald wat je zou willen.


* 786562 Jit

Hmm. toch maar ff gauw m'n www op 700 zetten, iets teveel 'under construction'

[Verwijderd]

Ik heb even op die site van hun gekeken ....

alle eerste die opviel is een javascript error die op je scherm springt! ... niet al te best voor iemand die beweert veel te weten over security en "websites" ..

Ten tweede wat een gellul allemaal op die site en ten derde ... wat is die site lelijk

Als dit heen derderangs kut bedrijfje is dan weet ik het ook niet meer

Xs4all for ever !!! (zelfs met hosting)

[Verwijderd]

De meeste mensen reageren zonder dat ze alles weten, hoe wil je iets constructiefs melden als je niet het fijne ervan af weet? (wel knap, ga bij BVD werken die kan mensen gebruiken die helderziend zijn)

Hieronder 2 url's waar wel alle details te vinden zijn, die je op zijn minst nodig hebt om iets zinnigs over deze issue te kunnen melden.

www.netgeneration.nl
http://dmrt.dyndns.org/forum/viewtopic.php?Topi cID=652

Die constatering is volgens de provider weliswaar terecht, maar niet
specifiek voor het platform van XS4ALL. "Dat het redelijk eenvoudig is
leesrechten te krijgen, is inherent aan shared webhosting", zo zegt
Pelleboer.

Dat is onzin, het is zeer goed mogelijk om ook in shared webhosting omgeving
directories afdoende af te schermen, enkele andere ISP's waarvan wij weet
van hebben draaien ook op Unix platform en kunnen kennelijk wel hun systemen
dusdanig configureren dat men niet bij elkaar in de directories kunnen
kijken.
Afgezien hiervan, hebben wij een zogenoemde bindshell gebruikt waarmee je de
rechten krijgt van user nobody, normaliter zou je verwachten dat deze user
niets mag, dan alleen een pagina opvragen waarvoor nobody -iedereen-
leesrechten voor zijn afgegeven.

Ook is het opmerkelijk dat de htpass files van XS4ALL beheer niet over de
juiste permissies beschikte, immers binnen 5 minuten beschikten we over die
passworden, en een dag later was de eerste al gekraakt.