Hoofdcategorieën
Device Settings

'Half miljoen databaseservers heeft geen firewall'

Door Olaf van Miltenburg, woensdag 14 november 2007 15:42, views: 15.694

Bijna een half miljoen databaseservers wordt niet beschermd door een firewall, claimt beveiligingsonderzoeker David Litchfield na onderzoek. Twee jaar geleden waren dat er nog 350.000.

Dit blijkt uit het Database Exposure Survey dat Litchfield maandag op Databasesecurity.com gaat publiceren, maar waar Infoworld.com al inzage in kreeg. Litchfield nam meer dan een miljoen willekeurig gekozen ip-adressen en controleerde of hij ze kon benaderen via de poorten die Microsofts SQL Server en Oracle's databaseservers gebruiken. Hij vond op deze manier 157 SQL-servers en 53 Oracle-servers. Op basis van schattingen over het aantal met internet verbonden systemen, komt de beveiligingsonderzoeker tot de conclusie dat er ongeveer 368.000 Microsoft SQL Servers en 124.000 Oracle-databaseservers direct te benaderen zijn.

De onderzoeker is verbaasd over de toename. ' We rennen allemaal rond als kippen zonder kop na berichten over het lekken van bedrijfsgegevens. Organisaties interesseert het echter niets. Waarom zijn al die sites daar zonder bescherming van een firewall?' Het aantal Oracle-systemen is overigens opvallend genoeg gedaald ten opzichte van het onderzoek uit 2005, van 210.000 naar 140.000 stuks.

Uit het Database Exposure Survey 2007 blijkt ook dat een groot aantal servers nog niet over de laatste patches beschikt. Zo bleek 4 procent van de SQL Servers nog steeds kwetsbaar voor het lek waarvan de Slammer-worm in 2003 misbruik maakte. Litchfield schreef de proof of concept-code die later door virusschrijvers gebruikt werd om slammer te ontwikkelen. Van de SQL Servers draaide 82 procent oudere SQL Server 2000-software en minder dan de helft daarvan had de laatste Service Pack geïnstalleerd.

Firewall
Volgende 16:35 Tulip wil Commodore toch niet overnemen
Vorige 15:14 @Home verhoogt snelheid duurste abonnement naar 20Mbps
Advertentie

Reacties

«  1  2  »

Dit onderzoek slaat op niets, als ik thuis die poort heb openstaan, omdat ik ze zogezegd willekeurig heb genomen, kom ik ook bij de cijfers...

Als ik het artikel zo lees hebben ze meer gedaan dan alleen gekeken of de poort open staat of niet - er staan ook gegevens over versies en patches bij - ik denk dus dat ze niet alleen gekeken hebben of de poort open staat maar ook hoe de machine zichzelf identificeerd.

Maar ook dat is niet betrouwbaar gezien de opmars van o.a. honeypots etc

Mja, toch denk ik dat de verhouding honeypots vs domme mensen die hun server niet beveiligen/updaten heel sterk naar die laatste neigt.

behalve als hij ook kijkt of er daadwerkelijk een database achter draait. Hij heeft immers ook gekeken naar de versie van de software en evt (niet) geïnstalleerde service packs. Hij heeft dus echt niet alleen zomaar poorten lopen scannen.

bij een portscan kun je ook service-discovery inschakelen, die kijkt niet alleen of de poort openstaat maar ook welk programma er antwoord op die poort, als dit MSSQL of OperaSB is bijvoorbeeld, dan kun je er weer eentje bij optellen, daarnaast is er een internationale lijst met porten die worden gebruikt door programma's dus een ander programma zal niet standaard antwoorden op die 2 gezochte poorten, en daartegen is de kans dat van die 138 mensen ook maar eentje toevallig die poort heeft opengezet via een programma erg klein

de gegevens zijn dus wel degelijk correct!

En hoeveel daarvan heeft nog een default password als sa of admin? :)


bij mijn vorige werkgever was het password ook sa ;)
en stond ook de SQL mooi open naar buiten, was makkelijk voor verkopers onderweg die demo moesten geven :P

157 en 52 servers uit 1 miljoen. Lijkt me een beetje erg klein % om dit soort uitspraken te doen.

deze 157 sql servers zouden dan x 2343 = 368.000 ms servers zijn
53 x 2343 = 124.000 servers zijn.

Bij een afwijking van 5 servers krijg je al een aantal van 112.000 oracle server of 356.000 ms servers.

Er is gewoon te weinig data om dit soort uitspraken te kunnen doen.

[Reactie gewijzigd door bbob1970 op woensdag 14 november 2007 15:51]


Je kan wel uitspraken overdoen, hoe het berekend wordt is ook netjes vermeld. Dat een een grote delta ontstaat door de vermenigvuldiging wordt ook niet ontkend.

Alle data wordt gegeven, de conclusie kan je ook trekken, dus ik zie niet in wat er mis is.

Met ~200 onderzochte servers heb je ~7% nauwkeurigheid ( 100/wortel(N) )
Niet echt nauwkeurig, maar je kunt er best een paar uitspraken op baseren.

Hij heeft meer dan 1 miljoen servers onderzocht en heeft toen die waarden gevonden. De nauwkeurigheid zal dus wel iets hoger liggen.
Bij statistieken is de nauwkeurigheid groter naarmate het aantal onderzochte specimen groter is. 1 miljoen is een heel groot aantal, meer dan de gemiddelde opiniepeilers anschrijven. En die worden vaak nog beter/eerder geloofd.

En het aantal named SQL Server instances, op de niet default poort 1433? Daar wordt niet eens rekening mee gehouden.

[Reactie gewijzigd door Robtimus op woensdag 14 november 2007 15:50]


En dat de server draait wil niet zeggen dat deze niet secure is;

Het klinkt als een schande, maar extrapoleren is ook een vak.
210 servers op 1 miljoen checks is 0,021% van de gecontroleerde IP-adressen herbergt een database-server. In veel situaties zou dit als nihil worden beschouwd.

Ik kan me voorstellen dat organisaties juist willen dat een database toegankelijk is.

Over het algemeen wil je de database afgeschermd hebben, en een middle-tier software (zoals een webapplicatie) naar buiten open hebben staan als buffer...

Een DB rechtstreeks op het net is vragen om diefstal van je gegevens. Dan kun je beter gelijk al je bedrijfsgeheimen op wikipedia publiceren. Dan hoef je zelf geen servers te kopen/leasen/huren/beheren... ;)

Over het algemeen wil je de database afgeschermd hebben, en een middle-tier software (zoals een webapplicatie) naar buiten open hebben staan als buffer...
En bij de meeste enterprise apps zelfs dat meestal niet. Over het algemeen zet je alleen poort 80 open op je webserver en die zorgt ervoor dat het verkeer bij de appserver en je webapp terecht komt. Ook de appserver staat potdicht, op de benodigde poorten na.

[Reactie gewijzigd door NLxAROSA op donderdag 15 november 2007 07:26]


idd, echter begrijp ik niet wat een firewall hier mee te doen heeft. Die database server moet helemaal niet te benaderen zijn vanuit het WAN, alleen vanuit het LAN.
dit zijn waarschijnlijk allemaal dbservertjes van massahosters of hobbyisten die toch geen boeiende info bevatten, beetje paniek om niks

Zo blijkt maar weer dat de zwakste schakel de gebruiker is die de software beheerd.

Echter ook al heeft SQL een naam die meer voor bedrijfstoepassingen lijkt te zijn, zijn er talloze software pakketten die een SQL Lite, SQL Express of andere vorm installeren op een desktop, zoals bijvoorbeeld Exact software.

Of beginnende tweaker die WAMP of LAMP installeert op zijn thuis computer, en geen benul van beveiliging heeft.

Of beginnende tweaker die WAMP of LAMP installeert op zijn thuis computer, en geen benul van beveiliging heeft.
Of het geen zier interesseert.Mijn bak is ook niet echt beveiligt, de reden is simpel, het ding is een testbakkie waar ik overal bij wil en alles mee wil proberen. Belangrijke dingen staan er niet op, dus ga ik niet echt een beveiliging erop zetten. En ikd enk dat er zo nog wel veel meer machines wel bereikbaar zijn, maar verder niets bevatten aan data oid.

Met die gedachte had ik mambo op mijn bak geinstalleerd, even mee gespeeld en niet meer naar gekeken. Half jaar later via de morpheus scanner had ik wel een phishing site draaien waarna mijn isp (terecht) de stekker eruit trok. Met als gevolg dat ik 3 dagen zonder internet zat.

Dus naast mijn afkickverschijnselen waren er ook nog eens talloze mensen benadeeld alleen omdat ik even onzorgvuldig was geweest. Ondanks mijn firewall en patchmanagement en anti-virus.

Zo blijkt maar weer dat de zwakste schakel de gebruiker is die de software beheerd.
Een gebruiker heeft ook niks te maken met het beheren van een server, daar zijn beheerders voor (en daar worden ze ook voor betaald).

Databaseservers horen gewoon in een apart vlan, achter op zijn minst twee of drie firewalls te staan. Middleware maakt verbinding met de database, en heel misschien mag die middleware open staan voor het internet.

Zo bleek 4 procent van de SQL Servers nog steeds kwetsbaar voor het lek waarvan de Slammer-worm in 2003 misbruik maakte. Litchfield schreef de proof of concept-code die later door virusschrijvers gebruikt werd om slammer te ontwikkelen.
Mogen we nu het vorige onderzoek van die Litchfield als oorzaak van de Slammer worm epidemie beschouwen ?
In dat geval zou ik als ik die kerel was een boel goede advocaten zoeken, in de VS wordt je voor minder aangeklaagd, en feit lijkt me dat die kerel in zekere mate mede verantwoordelijk is voor de Slammer worm.

Er is een verschil tussen oorzaak en aanleiding. De oorzaak is het lek. Zonder lek geen worm. De toevallige aanleiding is het onderzoek van Lichtfield. Als onderzoeker kan je niet verantwoordelijk worden gehouden voor de fouten in software die door andere mensen is gemaakt. Laat staan dat je schuld hebt.

Zou wel gek worden anders. Dan wordt de pers straks aangeklaagd voor de daden van een moordenaar die al die aandacht wel leuk vindt.

Ja maar je bent wel verantwoordelijk voor de verspreiding van een Worm.
Als iemand tegen een inbreker zegt hoe hij jouw huis het makkelijkst en ongemerkt kan binnenkomen, en het is bekend dat dit verteld is dan ben je wel schuldig aan aanleiding geven tot inbraak.

Een gestolen brommer kopen is ook heling als je weet dat die gestolen is. Zelfs als je dat niet weet wordt je als verdachte aangemerkt (eigen ervaring).

Dat lijkt me heel sterk. Zeker als jij slechts zegt dat slot type X van merk Y veel gebruikt wordt, en uitlegt hoe je die openmaakt zonder sleutel, dan kunnen ze je niet aanklagen voor de 10miljoen inbraken die gedurende de komende jaren worden gepleegd omdat mensen hun sloten niet vervangen. Een willekeurige persoon heeft niet de verantwoordelijkheid om mensen te beschermen tegen inbrekers.

Als PostgreSQL een security-fix uitbrengt, dan staat dat gewoon beschreven in de mailinglist. Je kan ook makkelijk een diff op de code uitvoeren om te kijken wat er veranderd is. Zijn zij dan ook verantwoordelijk voor de daden van hackers die ongepatchte systemen gaan binnenvallen?

Wat heling ermee te maken heeft snap ik niet.

Die dure dba's zijn echt niet nodig...

Zouden ze ook rekening hebben gehouden met honingpotten?

Ik heb even snel het oude onderzoek gelezen en ze hebben het over "unprotected" sqlservers... Nergens kan ik lezen hoevel van deze er met opzet open stonden. Dat de poort open staan houd IMHO niet in dat ze unprotected zijn. Sterker nog vaak is er opzet om die poort open te zetten.

Tevens waren van de 80000 ip adressen er 30 sql servers; 18 oracle; en 847 MySQL...
Moet ik het nog uitleggen of zijn we het er mee eens dat dit een kansloos onderzoek is?

[Reactie gewijzigd door seal74 op woensdag 14 november 2007 16:03]



Hoeveel MySQL servers staan er niet bewust open door tweakers of websites? Ik denk een hele boel.. Niets wijst er op dat hier bedrijfsgevoelige informatie opstaat... Sterker nog niets zegt mij dus hoeveel bedrijven er achter deze ip adressen stonden... Het zou net zo goed zo kunnen zijn dat alle databaseservers die gevonden zijn thuis pc waren van tweakers... Tevens kan ik nergens lezen welke geen password beveiliging hadden...

Jij onderschat het aantal "bedrijven" die MySQL als "databaseserver" gebruiken...

Ik twijfel aan de betrouwbaarheid van dit onderzoek. Zonder fatsoenlijke beveiliging op een server toegankelijk vanaf internet, word je binnen een week -zo niet binnen enkele minuten al- keihard op de feiten gewezen. Als je ziet wat een hoop rotzooi je binnenkrijgt, alleen al op m'n linux hobby servertje krijg ik per dag gemiddeld 5 pogingen tot brute-force aanvallen via SSH. (maar na 10 foute wachtwoorden gooit ie het IP gewoon in de ban)

Een standaard (kale) installatie van windows -zonder je muis of toetsenbord ook maar aan te raken- direct op internet aangesloten zit binnen een kwartier vol met spyware en andere zooi. _/-\o_

Zonder beveiliging kun je tegenwoordig gewoon niet meer gebruik maken van internet. :X

Of dat nou met een firewall, iptables of iets anders.

De getallen uit het artikel zijn dan ook gewoon uit de lucht gegrepen
Litchfield nam meer dan een miljoen willekeurig gekozen ip-adressen en controleerde of hij ze kon benaderen via de poorten die Microsofts SQL Server en Oracle's databaseservers gebruiken
Ten eerste, er zijn bepaalde ipranges die bedoelt zijn voor overheid, scholen en bedrijven waardoor het beeld vertekend word. Het aandeel servers op privé adressen zal lager liggen.

Ten tweede wil je die poorten misschien JUIST doorlaten zodat je het extern kan benaderen. Goed beveiligd met wachtwoord, versleuteling en 'brute-force honeypots'.
Litchfield schreef de proof of concept-code die later door virusschrijvers gebruikt werd om slammer te ontwikkelen.
Misschien dat die code wel werkt, maar als je er echt misbruik van wilt maken niet. Of dat het wederom een honeypot is waarna er een abuse mailtje richting de provider van de aanvaller gaat ;)

Een standaard (kale) installatie van windows -zonder je muis of toetsenbord ook maar aan te raken- direct op internet aangesloten zit binnen een kwartier vol met spyware en andere zooi.
Sinds SP2 staat de firewall toch standaard aan?
Of dat nou met een firewall, iptables of iets anders.
Onder Windows misschien wel, maar onder Linux is het niet zo'n probleem als je sterk wachtwoorden gebruikt.

[Reactie gewijzigd door Olaf van der Spek op woensdag 14 november 2007 16:45]


Linux of Windows is daarin niet het grote risico. Als Oracle zelf lek is ben je gewoon het haasje. Via een buffer overflow root rechten pakken is ook op Unix en Linux zo oud als de weg naar Rome, maar ook als het lek beperkt blijft tot de database server zelf is dat een probleem. Als je hele database is leeggeplukt is het een schrale troost dat de rest van het OS veilig bleef.

Linux of Windows is daarin niet het grote risico. Als Oracle zelf lek is ben je gewoon het haasje.
Jawel, onder Linux stel je de daemon gewoon zo in dat die alleen op localhost te bereiken is als je dat wilt. Onder Windows doe je zoiets dan meestal via een firewall.

De juiste manier is natuurlijk en-en, localhost-only + firewall. Maar als die luie/onwetende beheerders waar het hier om gaat al geen firewall aanzetten, dan zetten ze waarschijnlijk ook die localhost-only optie niet aan.

[Reactie gewijzigd door Dreamvoid op donderdag 15 november 2007 11:15]


Waarom is localhost only de juiste methode...heb hier meerdere MySQL clusters draaien die toch echt vanaf andere hosts benaderbaar moeten zijn. Wij gebruiken hiervoor normaliter een intern netwerk wat via vlans afgeschermd wordt van de andere machines. Daarnaast de boel uiteraard lokaal firewallen en alleen de hosts die toegang moeten hebben die toekennen. Moet een en ander over internet (wan) heen dan kan dat via vpn of via een ssl verbinding vanuit MySQL zelf...eerste heeft de voorkeur aangezien de server zelf dan niet de encryptie hoeft te doen.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 16:35 Tulip wil Commodore toch niet overnemen
Vorige 15:14 @Home verhoogt snelheid duurste abonnement naar 20Mbps
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011