'Half miljoen databaseservers heeft geen firewall'

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.

Reacties (49)

[bbob]

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 bbob op 25 juli 2024 17:54]

[Tukk]

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.

[BlackIce]

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

[TheCapK]

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.

[seal74]

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 25 juli 2024 17:54]

[seal74]

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...

[Ajunne]

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

[Verwijderd]

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...

[Twilight Burn]

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.

[Bor]

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

[Twilight Burn]

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

[wizzkizz]

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.

[Verwijderd]

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!

[Robtimus]

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 25 juli 2024 17:54]

[Verwijderd]

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.

[LcNessie]

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...

[NLxAROSA]

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 25 juli 2024 17:54]

[demonite]

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

[Roland684]

Dat is nog niets. Ik ga straks een onderzoek doen en verwacht dat ik massa's httpservers zal vinden op de defaultpoort 80 zonder (of door) firewall.
En als ik daarmee het nieuws haal, ga ik nog een onderzoek doen op poort 21 om te kijken hoeveel ssh servers er zonder firewall benaderbaar zijn.
En misschien doe ik ook nog wel een onderzoekje naar hoeveel telefoons er aan het telefoonnet hangen zonder firewall.
)

Die gast heeft vast aandelen in een firewallbedrijf, dit is gewoon bangmakerij.

[blender]

HTTP en FTP zijn bedoeld om aan internet blootgesteld te zijn. Dat geldt niet voor database servers. Die zijn meestal de 3e tier vanaf internet gezien en zouden dus achter minimaal 1 maar soms zelfs achter 2 firewalls moeten zitten.

Ga er vanuit dat JIJ een grapje maakt, maar beheerders die een database direct aan internet hangen denken waarschijnlijk net als jij maar dan zonder een grapje te maken.

[zalazar]

Ter info: SSH is poort 22, FTP poort 21 (en ook 20)

[mxcreep]

Wij hebben ssh ook soms openstaan op bepaalde systemen...ook dat kun je op nog meer manieren dicht timmeren, zoals geen directe root logins toestaan en gebruik van rsa keys ipv passwords.

[Falcon10]

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.

[Verwijderd]

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.

[Soldaatje]

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).

[Verwijderd]

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.

[Verwijderd]

Ik snap niet dat mensen hier zeggen:
"Ja maar er is geen rekening gehouden met systemen waarbij het expres open staat"

Wat een onzin.. noem mij 1 reden waarom 0.0.0.0 of te wel: Iedereen!! in de wereld de mogelijkheid moet krijgen om op een SQL commandline de mogelijkheid te krijgen om INSERT INTO VALUES ('blaat','mekker'); in te kunnen typen.

daar zijn (web)applicaties voor: zelfs voor sales mensen, of voor mij part voor iedereen.
Geen enkele reden is ervoor..besides honeypots, als je van wel vind...heb je RDBMS'ses gewoon niet goed begrepen en zit je op de verkeerde school (als het een studieopdracht is)

[IEF]

er is meer dan alleen een open poort. Authenticatie voordat je blaat en mekker gaat INSERTen ?

Als je default passwords gebruikt, ok. Maar dan heb je denk ik OF niet veel te verbergen , of je denkt dat je invulnerable bent (of gewoon plain stupidity).

Natuurlijk blijven er altijd exploits. Maar in sommige dev situaties bijvoorbeeld (als het toch alleen maar een testdb is) zal het mij persoonlijk niet interesseren of iemand daar blaat en mekker in loopt te gooien.

Is natuurlijk ook nogal afhankelijk waar die test dbms dan staat en of de rest van het systeem wel critical is. Ik kan er persoonlijk niet van wakker liggen als ze m'n testvm rooten.

Er is nog meer op de wereld dan mission-critical applicaties. Beetje inlevingsvermogen mag ook wel.

[Reactie gewijzigd door IEF op 25 juli 2024 17:54]

[Verwijderd]

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.

[TERW_DAN]

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.

[it0]

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.

[Ajunne]

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.

[napel25]

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

Zouden ze ook rekening hebben gehouden met honingpotten?

[Larsie]

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.

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

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

[Olaf van der Spek]

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 25 juli 2024 17:54]

[Dreamvoid]

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.

[Olaf van der Spek]

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.

[Dreamvoid]

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 25 juli 2024 17:54]

[mxcreep]

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.