MySQL-maker wil database beter gaan beveiligen

Door Martin Sturm, zaterdag 29 januari 2005 12:16, 30 reacties • Feedback
Bron: WebWereld

Na de recente uitbraak van de nieuwste 'worm' die MySQL-servers aanvalt, heeft de vice-president van het bedrijf MySQL aangekondigd dat het bedrijf van plan is de standaard beveiliging van het DBMS te gaan verbeteren. Momenteel is het nog zo dat een standaard MySQL-installatie wordt voorzien van een root-account zonder password en standaard verbindingen van buitenaf worden toegestaan.

MySQL logo nieuwe stijl Zack Urlocker, de vice-president van MySQL, zegt dat het bedrijf altijd als doel heeft gehad de installatie van MySQL zo eenvoudig mogelijk te houden en ervoor te zorgen dat een gebruiker van de database binnen 15 minuten MySQL werkend moet kunnen hebben op zijn systeem. Het bedrijf overweegt om deze laatste 'feature' nu te laten varen teneinde de veiligheid van het systeem te verbeteren. MySQL werkt daarnaast ook aan een systeem wat automatisch updates installeert.

C|Net meldt overigens dat de verspreiding van de nieuwste MySQL 'worm' grotendeels is gestopt. De MySQL bot worm (ook wel aangeduid met de naam SpoolCLL) maakt gebruik van IRC-servers om zichzelf te verspreiden. De verspreiding is nu stopgezet door de betrokken IRC-servers niet meer toegankelijk te maken. Sinds gisteren zijn nieuwe infecties daarom nu een stuk minder volgens Oliver Friedrichs van Symantec.

Reacties (30)

0 Weezer-DC
29 januari 2005 12:23

Ze moeten gewoon standaard alle connecties blocken behalve die vanaf loclhost.
Als je een aparte sql server en bijv. een webserver hebt dan ben al best professioneel bezig en dan moet je dus een ander ip (lokaal wel te verstaan) in de allow lijst zetten van de mysql server
En in de setup zou je een root wachtwoord moeten opgeven die ook is gecheckt wordt op op een paar punten (kleine en grote letters en cijfers)

+1 Shatter
@Weezer-DC • 29 januari 2005 12:38

Dat soort dingen regel je normaal in de firewall configuratie van je productie-omgeving, niet in je database.

MySQL heeft dezelfde fout gemaakt als Microsoft en al die andere bedrijven, men gaat ervan uit dat een beheerder ook echt de installatiehandleiding leest voordat het in productie wordt geplaatst. In plaats dat beheerders hun werk eens gaan doen moet MySQL hun hoofd gaan breken over hoe ze hun wizard wat veiligere configuraties kunnen laten maken.

Ik vind het op zich niet verkeerd dat standaard de beveiliging niet zo strak is, als je gewoon even een paar uur wilt kijken hoe MySQL werkt dan wil je niet eerst een paar dagen zitten pielen met de security. Het zou een optie kunnen zijn in de configuratie (veilig of alles open), maar drie keer raden welke optie de bovengenoemde beheerders dan gaan kiezen...

0 KayJay
@Shatter • 30 januari 2005 22:26

Dat soort dingen regel je normaal in de firewall configuratie van je productie-omgeving, niet in je database.

Nee dit soort dingen regel je met een firewall EN in je database

Alex

@Shatter • 29 januari 2005 13:25

MySQL heeft dezelfde fout gemaakt als Microsoft en al die andere bedrijven, men gaat ervan uit dat een beheerder ook echt de installatiehandleiding leest voordat het in productie wordt geplaatst. In plaats dat beheerders hun werk eens gaan doen moet MySQL hun hoofd gaan breken over hoe ze hun wizard wat veiligere configuraties kunnen laten maken.

En wie zegt dit? Wat een grote onzin. Beheerders hebben 99% van de tijd hun zaakjes wel op orde hoor. Weet je hoe dit soort wormen verspreiden? Thuisnetwerkjes, wat gepruts en geklooi van beginnede developertjes, etc, etc.
Ik ben zelf een developer én beheer daranaast ook nog een aantal server waaronder een MySQL-server. Geconfigureerd op basis van uitvinden lokaal, manual, fora, boeken, etc.
Al met al zijn dat zovele bronnen dat je niet altijd zomaar het kaf van het koren kunt scheiden. Sterker nog, het kan goed zijn dat ik wel 20 keer de server open heb gezet voor heel de wereld. Zoiets overkwam me met MS-SQL ook.

Shit happends, maar om daarom de beheerders de schuld te geven gaat me wat te ver.

Dat soort dingen regel je normaal in de firewall configuratie van je productie-omgeving, niet in je database.

Hier ben ik het tot zover me je eens dat ik wel denk dat een vorm van security in je je datalagen zal moeten hebben. Uitgaan van het enkel nodig, en niet ervan utigaan dat de firewall wel alels tegen houdt...

Het zou een optie kunnen zijn in de configuratie (veilig of alles open), maar drie keer raden welke optie de bovengenoemde beheerders dan gaan kiezen...

Hiermee doe je dus afbraak ana je hele reactie... jammer.

@Weezer-DC

En in de setup zou je een root wachtwoord moeten opgeven die ook is gecheckt wordt op op een paar punten (kleine en grote letters en cijfers)

Ja, het is een business standaard, nee inprinciepe zou blank al voldoende moeten zijn als je er maar voor zorgt dat er extern niet geconnect kan worden.

eamelink
@Alex • 29 januari 2005 22:06

Alex -> Dus het is niet de schuld van MySQL, en ook niet de schuld van de beheerder?

"Shit happens" ?

Maar goed dat ik niet bij jou host

. Natúúrlijk is het wel de schuld van de beheerder! Beheren betekent ook verantwoordelijkheid nemen.

Het is niet altijd érg als het misgaat. Het is niet zo erg als een thuisservertje plat gaat door een slechte beheerder. Het is wel erg als een productieserver plat gaat door een beheerder.

En als de beheerder denkt dat hij de server niet veilig genoeg kan maken zonder wizards enzo, moet hij een andere databaseserver zoeken, of een collega inhuren om het te doen, of het zelf leren. Maar niet "shit happens"

Bij mij gaat er ook weleens wat fout, maar dat is vrij zorgvuldig afgewogen; hoeveel risico's wil ik lopen bij bepaalde dingen.

Alex

@Alex • 30 januari 2005 14:56

Tuurlijk heeft een beheerder zijn verantwoordelijkheden, Maar ik doelde erop dat het niet zwart-wit is. Zo simpel is het nou eenmaal niet. Daarbij wilde ik erop wijzen dat deze wormen echt niet voornamelijk verspreid zijn via ISP's.
Shatter zou eens moeten kijken hoe hard er bij hte overgrote deel van de ISP's wordt gewerkt aan security.

Dat je er altijd een paar tussne hebt zitten die niet weten wat ze doen... tsja... prutsers houdt je altijd. Maar Shatter, scheer ze niet over 1 kam. Dat doe je ze;f ook niet met de Informatica studenten bijv.

PowerSp00n
@Weezer-DC • 29 januari 2005 12:29

Ze moeten gewoon standaard alle connecties blocken behalve die vanaf loclhost.
Als je dus een aparte sql server hebt dan ben al best professioneel bezig en dan moet je dus een ander ip (lokaal wel te verstaan) ook een de allow lijst zetten

Op dit moment is dat het geval ook al wel, maar dan niet direct of hoe je het ook mag noemen maar pas op database/user niveau zegmaar. Standaard kun je alleen maar connecten vanaf localhost of je eigen ip.

En in de setup zou je een root wachtwoord moeten opgeven die ook is gecheckt wordt op op een paar punten (kleine en grote letters en cijfers)

Liever dat ze zich daar niet mee gaan bemoeien maargoed...

0 mxcreep
@Weezer-DC • 29 januari 2005 21:15

Tiz en blijft een kwestie van fatsoenlijk nadenken voor je iets installeert...wat wil je ermee doen en hoe doe je dat zo veilig mogelijk...
Ik zet op shared webservers altijd de tcp-ip connecties uit dmv het starten met als argument --skip-networking....nooit connecties mogelijk dus vanaf een andere host dan localhost...connecten over een unix socket levert nog een behoorlijke performance winst op ook t.o.v. tcp-ip connecties.
root password instellen en elke nieuwe db krijgt een eigen nieuwe user die alleen op die db rechten heeft. Kind kan de was doen, zo moeilijk is mysql beheer niet...en anders zijn er altijd nog tools als webmin waarmee je dit kunt doen.
Verder is het gewoon zaak om in je firewall alleen die poorten open te zetten die strict noodzakelijk zijn.
In het geval van een mysql server los van de applicatie server, kwestie van op beiden servers een lokaal netwerk opzetten over de tweede ethernet interface, netjes configgen in je firewall en ook de rechten van users netjes instellen vanaf die remote hosts en je hebt nooit problemen...

Persoonlijk zie ik meer heil in een snelle en duidelijke howto waarin uitgelegd wordt op welke punten je moet letten dan een standaard config die misschien veiliger is, maar nog steeds niet door niet wetenden wordt bekeken en wordt aangepast waar nodig.

Rhapsody

29 januari 2005 12:20

Eerlijk gezegd vind ik het niet echt verstandig van MySQL zelf om standaard geen paswoord in te stellen voor de root-account.

Ook die standaard verbindingen van buitenaf is natuurlijk vragen om problemen.

Natuurlijk is het zo dat als je met MySQL aan de slag gaat, je moet weten waar je mee bezig bent, en dat je het zelf dus goed beveiligt.

+1 daapah
@Rhapsody • 29 januari 2005 12:25

na de installatie een root-wachtwoord laten genereren en tegen de user zeggen: dit is je PW.

RuuddieBoy
@daapah • 29 januari 2005 12:42

Gewoon tijdens de installatie om een pass laten vragen.

+1 Olaf van der Spek
@RuuddieBoy • 29 januari 2005 13:45

Gewoon tijdens de installatie om een pass laten vragen.

Zodat de gebruiker alsnog 12345678 kan invullen?
Nee, de app een password laten genereren is veel veiliger.

Splash
@RuuddieBoy • 29 januari 2005 15:02

Het feit wil dat ik laatst voor het eerst een mysql installatie heb gedaan, en daar werd zeker wel om een password gevraagd, alleen het vinkje voor "alleen connecties vanaf localhost toestaan" stond standaard uit.
Verder viel het me ook op dat dat deze gebruiker inderdaad zonder verdere vragen "root" heette.

Die 15 minuten deadline hoeven ze volgens mij dus helemaal niet te veranderen, alleen een kwestie van ook om een gebruikersnaam vragen, en zorgen dat dat vinkje standaard aan staat ipv uit.

0 Olaf van der Spek
@RuuddieBoy • 29 januari 2005 16:12

Verder viel het me ook op dat dat deze gebruiker inderdaad zonder verdere vragen "root" heette.

De installer zit er pas sinds 4.1 bij.
En de veiligheid moet van het wachtwoord komen, niet van de gebruikersnaam.

0 opagrover
@RuuddieBoy • 29 januari 2005 16:46

De meeste users hebben maar 1 wachtwoord, wat overal gebruikt wordt -> dus ook daar.

Ik heb er 2: 1 extra geheim (mail, telebankieren) & 1 standaard (die ook voor mijn MySQL root account geld... en voor mijn windows login, en voor eigenlijk alles)

0 Olaf van der Spek
@RuuddieBoy • 29 januari 2005 17:51

1 extra geheim (mail, telebankieren)

Dat wachtwoord vliegt dus elke dag onbeveiligd over de lijn?

MySQL wachtwoorden hoef je IMO niet te onthouden. Die zet je gewoon in een bestand en daarvoor gebruik je geen wachtwoord dat je ook voor andere zaken gebruikt.

Wolfboy
@RuuddieBoy • 29 januari 2005 18:26

@Olaf van der Spek
Waarop baseer je dat het onbeveiligd gaat?
In het geval van POP3 kan je ook gewoon SSL gebruiken en hetzelfde geld voor IMAP en webmail.

Buiten dat is het idd simpelweg stom om voor telebankieren hetzelfde wachtwoord te gebruiken als voor je mail, ik ga er iig van uit dat je niet zelf je mailserver beheerd en dus vind ik het al erg onveilig.
En dan nog zou ik het apart houden al is het alleen al om het net een beetje moeilijker te houden, ik heb zelfs voor ongeveer elk systeem waar ik op werk een ander wachtwoord, paranoia? misschien, maar wel veilig.

0 Olaf van der Spek
@RuuddieBoy • 29 januari 2005 19:31

Waarop baseer je dat het onbeveiligd gaat?

Omdat SSL/TLS (jammer genoeg) toch redelijk zeldzaam is.

0 Ron.IT
@RuuddieBoy • 30 januari 2005 08:36

@Olaf

APOP (Authenticated Post Office Protocol) is echter een tussenvorm, waarbij het POP3 wachtwoord versleuteld wordt (via MD5) en vele mailservers ondersteunen dit. Outlook, Outlook Express en vele andere email client software ondersteunen tevens APOP, danwel via opties, of volledig automatisch.

Outlook en Outlook Express sturen eerst het wachtwoord met APOP door, als de mailserver dan een -ERR (error) code terugstuurt, dan wordt het alsnog geprobeert zonder versleuteling.

+1 Ramoonus
29 januari 2005 12:21

ja het is wel zo
maar het is: als het kalf verdronken is dempt men de put
beetje laat

+1 Olaf van der Spek
@Ramoonus • 29 januari 2005 13:48

beetje laat

Maar beter dan de put open laten.

0 Bloody NO!
29 januari 2005 12:32

Nu is het natuurlijk heel leuk dat MySQL-team hun database beter willen gaan beveiligen, maar de worm is toch echt de schuld van slecht systeembeheer. Nu kan je een product standaard zo veilig maken als je wilt, maar als een prutser het toch installeert en wat dingen verandert, is het zo onveilig te maken.
* 786562 Bloody

0 Olaf van der Spek
@Bloody NO! • 29 januari 2005 13:50

Nu kan je een product standaard zo veilig maken als je wilt, maar als een prutser het toch installeert en wat dingen verandert, is het zo onveilig te maken.

Dat is toch nog geen reden om de standaardinstallatie ook onveilig te maken?

Ik heb aan de Apache en MySQL developers bijvoorbeeld ook al eens gevraagd om de service niet als System maar als LocalService uit te voeren.
Willen ze ook niet (verantwoordelijkheid van de beheerder).

+1 wouter veltmaat
29 januari 2005 12:37

Met dit soort dingen kun je zelf als admin ook die poort 3306 voor buitenaf dichtgooien mocht er ooit een bug in mySQL optreden als die ip check niet werkt.
Het lijkt paranoide om van bugs uit te gaan maar wel zo veilig.

-W0kk3L-
29 januari 2005 12:39

Gewoon net zo doen als dat vele anderen doen... een bepaalde routine/regel inbouwen die je moet uitschakelen/verwijderen om het programma werkend te krijgen... Een soort van 'die' commando inbouwen. Dan ben je verplicht omdat eerst uit te schakelen/verwijderen voordat het werkt.

0 aOk
29 januari 2005 12:41

Als je als server maar een goed password bedenkt zou het redelijk veilig moeten zijn tegen brute force hacking .. gebruik een andere poort dan de standaard poort .. en weet niet of mysql ook timeouts en dergelijke heeft .. maar dan zou het behoorlijk veilig zijn.

en .. geen standaard user "root" voor "%" vanaf welk netwerk dan ook aanmaken (misschien ben ik zelf wel zo dom geweest om dit te doen ipv mysql

, maar hij staat hier iig wel)

swampy

29 januari 2005 13:23

mmm dus de situatie is een beetje zoals genoeg wireless routers... je moet via een wizard ( installatie van mysql ) alles instellen BEHALVE de beveiliging!

0 El_Muerte_[TDS]541
29 januari 2005 13:45

Simpel weg een tar-pit toevoegen voor foutieve authenticaties. Dat scheelt al een heel stuk.

PipoDeClown
29 januari 2005 19:36

De enige manier om applicaties veilig te laten draaien is om de werking te beperken, zoals maximale geheugengebruik, rechten (of juist geen) op files en folders, applicatie onder apart "account" laten draaien, etc etc.

Die automatische update vind ik nou juist weer het tegenovergestelde van security.

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

MySQL-maker wil database beter gaan beveiligen

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (30)