risico's openzetten van poort 3306

[marty]

Poort 3306 wordt gebruikt voor mysql-verbindingen en binnen mysql kun je rechten zetten. Zo kun je dus bvb opgeven dat users alleen vanaf de localhost mogen connecten of - in sommige gevallen - vanaf een specifiek ip adres.
Als ik er over nadenk lijkt het me geen extra risico opleveren omdat je het zetten van rechten zelf (als beheerder van de server) in handen heb en zolang je geen % gebruikt (=mag vanaf ieder ip adres), zit het volgens mij nog steeds potdicht (maar heb je wel het voordeel dat je in sommige gevallen een specifiek iemand van buitenaf kunt laten connecten).

Ik ben gaan zoeken met google en hier op het forum en af en toe wordt er wel gezegd dat je het beter toch in de firewall dicht kan gooien (en dus helemaal voor verkeer van buitenaf afsluiten), maar dit wordt nooit onderbouwd / uitgelegd waarom.

Aldus mijn vraag: kan iemand mij misschien vertellen of het inderdaad een extra gevaar met zich mee brengt als je in je firewall poort 3306 openzet, gegeven dat je in mysql alleen uitzonderingsgevallen definieert voor een specifiek ip en de rest alleen van localhost laat connecten? Of is dit net zo veilig

[SyS_ErroR]

Ik _denk_ dat een firewall toch een sterkere beveiliging is dan om je rechten goed te zetten in mysql.

Ook heeft het niet echt een toegevoegde waarde, mysql wordt meestal benaderd via een website / gebruikt door een website. En dan volstaat enkel poort 80 , dus waarom zou je dan uberhaupt 3306 open willen zetten?

[MrBarBarian]

In aanvulling op SyS_ErroR:

- IP's zijn te spoofen
- Usernames/passwords zijn te raden (eventueel mbv brute force).

[Creepy]

Ik blijf me erover verbazen....

Als je je IP spooft hoe krijg je dan antwoord terug van MySQL aangezien die het antwoord stuurt naar het echte IP waarvan mysql denkt dat de request afkomt? Dit is alleen een risico als het mogelijk is om zonder reply van MySQL remote een MySQL server compleet te laten crashen.

De beveiliging van MySQL is opzich prima, mits er geen remote bufferoverflows e.d. in MySQL zitten. Die kans bestaat natuurlijk dus is het wel degelijk veilig om de MySQL poort m.b.v. je firewall ook nog eens af te blocken behalve voor de IP's die je in je MySQL DB hebt opgenomen.

Maar zolang je alleen via localhost/sockets connect dan zou ik skip-networking lekker in de my.cnf laten staan. Zoniet, zorg dan dat alleen de juiste IP's toegang hebben via de MySQL authorisatie EN de firewall. Gebruik dus ook nooit % in de hostname!

[ Voor 4% gewijzigd door Creepy op 30-08-2005 12:38 ]

[thegve]

MrBarBarian schreef op dinsdag 30 augustus 2005 @ 12:23:
In aanvulling op SyS_ErroR:

- IP's zijn te spoofen
- Usernames/passwords zijn te raden (eventueel mbv brute force).

Dat lukt ook met FTP. En als je daar toegang toe krijgt en je hebt geluk dat die FTP mappen ook via webserver te benaderen valt (met php), dan kun je ook commando's uitvoeren op het systeem, dus in dat opzicht is dan elke service wel "onveilig". Voor de rest ben ik het wel eens met de TS.

[marty]

SyS_ErroR schreef op dinsdag 30 augustus 2005 @ 12:21:
Ook heeft het niet echt een toegevoegde waarde, mysql wordt meestal benaderd via een website / gebruikt door een website. En dan volstaat enkel poort 80 , dus waarom zou je dan uberhaupt 3306 open willen zetten?

Ik heb respect voor de manier waarop phpmyadmin in elkaar is gezet en wat je er mee kan, maar mijns inziens haalt het niet bij iets als MySQLFront (een desktop tool voor windows). Als je veel met (mysql-)databases werkt dan is het echt geen harde met phpmyadmin.

Creepy schreef op dinsdag 30 augustus 2005 @ 12:37:
Maar zolang je alleen via localhost/sockets connect dan zou ik skip-networking lekker in de my.cnf laten staan. Zoniet, zorg dan dat alleen de juiste IP's toegang hebben via de MySQL authorisatie EN de firewall. Gebruik dus ook nooit % in de hostname!

Da's het probleem De Firewall voorziet er niet in om een poort voor één specifiek ip open te zetten. Het is óf open, óf dicht

[Gerco]

IPTables ondersteund dat wel degelijk... maak een rule die traffic van IP blaat doorlaat en alle andere traffic blokt, klaar.

WAARSCHUWING! TEST DIT LOKAAL VOOR JE SERVER DOOD IS

code:

iptables -A INPUT -s !1.2.3.4 --destination-port 3306 -j DROP

Waarbij 1.2.3.4 jouw eigen IP is natuurlijk. Dan kan alleen jij naar poort 3306 connecten en niemand anders. Meerdere van die regels gaat niet goed waarschijnlijk, dus dan moet je iets anders verzinnen, zoiets misschien:

code:

iptables -A INPUT -s1.2.3.4 --destination-port 3306 -j ACCEPT
iptables -A INPUT -s3.4.5.6 --destination-port 3306 -j ACCEPT
iptables -A INPUT --destination-port 3306 -j DROP

[ Voor 87% gewijzigd door Gerco op 30-08-2005 13:15 ]

[MrBarBarian]

Creepy schreef op dinsdag 30 augustus 2005 @ 12:37:
Ik blijf me erover verbazen....

Als je je IP spooft hoe krijg je dan antwoord terug van MySQL aangezien die het antwoord stuurt naar het echte IP waarvan mysql denkt dat de request afkomt? Dit is alleen een risico als het mogelijk is om zonder reply van MySQL remote een MySQL server compleet te laten crashen.

Dat het antwoord teruggaat naar het echte IP hoeft geen probleem te zijn, daar zijn sniffers voor.

Dat lukt ook met FTP. En als je daar toegang toe krijgt en je hebt geluk dat die FTP mappen ook via webserver te benaderen valt (met php), dan kun je ook commando's uitvoeren op het systeem, dus in dat opzicht is dan elke service wel "onveilig". Voor de rest ben ik het wel eens met de TS.

Klopt, iedere service is in principe een gevaar voor het systeem. Daaruit komt het het principe dat je altijd zo min mogelijk services moet hebben draaien, nooit services met root-privileges moet draaien.. en je services up to date moet houden.

Ik zie niet zoveel reden om en MySQL database direct bereikbaar te maken via het internet omdat het (zoals eerder gezegt) niet zoveel kan zonder frontent. Mocht het wel nuttig zijn, dan zou ik iig een SSH-tunnel aanraden.

[smokalot]

SSH tunnels zijn inderdaad de oplossing voor dit probleem, ook omdat de queries en hun output anders gewoon unencrypted over het netwerk gaan. Je wilt niet dat anderen je password hashes hebben.

[wizl]

Kijk anders een naar Navicat. Daar kun je verschillende servers opgeven die je via door een SSH tunnel grafisch kunt beheren. Werkt fantastisch. Ik gebruik het zelf gewon op de mysql-server van mijn provider

[Creepy]

marty schreef op dinsdag 30 augustus 2005 @ 13:01:
Da's het probleem De Firewall voorziet er niet in om een poort voor één specifiek ip open te zetten. Het is óf open, óf dicht

Eeh.. onder Linux kan je met iptables ook filteren op source IP. Bij de BSD varianten kan het ook en ik kan me haast niet voorstellen dat je dit met een beetje firewall tools niet in kan stellen.

Overigens kan MySQL4 ook zelf encryptie aan (dus geen SSH tunnel nodig). Moet je natuurlijk wel een client hebben die dat ook ondersteunt

[ Voor 15% gewijzigd door Creepy op 30-08-2005 16:29 ]

[Anoniem: 114611]

Ze geven de waarschuwing waarschijnlijk voor mensen die zonder er echt goed over na te denken MySQL bereikbaar maken voor 't internet. Dat wil niet zeggen dat het onveilig is, maar iedere opening is een potentiele ingang voor hackers dus als je het niet nodig hebt moet je hem niet openzetten. Als je 'm wel nodig hebt wel, daar is de optie voor MySQL is een groot en veel gebruikt pakket en in principe zal het risico minimaal zijn (mits je de toegang goed regelt en zeker als je een ssh-tunnel gebruikt zoals hierboven voorgesteld). Alleen als er een exploit ontdekt wordt moet je die ook direct patchen want hackers zijn snel tegenwoordig!

[Wilke]

MrBarBarian schreef op dinsdag 30 augustus 2005 @ 13:32:
Klopt, iedere service is in principe een gevaar voor het systeem. Daaruit komt het het principe dat je altijd zo min mogelijk services moet hebben draaien, nooit services met root-privileges moet draaien.. en je services up to date moet houden.

Je hebt inderdaad volledig gelijk, een verschil is wel dat FTP- en webservers natuurlijk specifiek met dit doel ontworpen zijn. Voor SQL-servers geldt dat in mindere mate, de kans dat daar foutjes in zitten lijkt me daarom groter.

Samba, om maar iets te noemen, ondersteunt een dergelijk principe als MySQL. Hier zijn in het verleden echter wel eens probleempjes mee geweest (okee, niet vaak, maar wel eens) - die je niet zou hebben gehad als de firewall de poorten al had geblokkeerd voor ongewenste bezoekers.

[DiedX]

Volgens mij is de beveiliging van MySQL zelf prima. Brute-forcen is bijna onmogelijk (je krijgt op een gegeven ogenblik een blokkade van MySQL zelf, waarbij je via mysql-root een flush-hosts op moet geven). MAAAAAR. De fuckups zijn de wereld nog niet uit. Terecht wordt opgemerkt dat je NOOIT % als hostname op moet geven. Maar je weet hoe dat gaat. Het werkt niet, en je trapt de boel open met %, en zet de achterdeur wagewijd open.

Dus (mijn idee):

Indien niet nodig: geen poort openen
Indien wel nodig: IPTables

En daarbij nooit % als hostname gebruiken

(En dat MySQL verbindingen kon encrypten wist ik weer niet. Zo leer je nog eens wat. Zoek-zoek)

[StefSybo]

Als je poort 3306 open laat staan kan wel degelijk een probleem opleveren, hoewel dat niet je data in gevaar zal brengen of iets dergelijks.
Ik heb een keer meegemaakt dat iemand gewoon een heleboel connecties opende naar een mysql server. Hij logde niet in, maar de connectie bleef wel open staan. Omdat MySQL een maximum aantal connecties (standaard 100) heeft dat hij accepteert accepteert hij dan dus geen andere connecties meer en is de database dus onbereikbaar totdat de DOS-aanval is gestopt.

Volgens mij moet je hiervoor trouwens wel minstens een user hebben die vanaf alle IP's in mag loggen, anders zegt de server dat dat IP niet mag connecten en sluit hij de connectie.

[ Voor 16% gewijzigd door StefSybo op 31-08-2005 13:37 ]

[DiedX]

Dat hoef je niet alleen met 3306 te kunnen doen hoor En dit is heel makkelijk af te vangen met Linux en IPTables

[igmar]

MrBarBarian schreef op dinsdag 30 augustus 2005 @ 13:32:
[...]

Dat het antwoord teruggaat naar het echte IP hoeft geen probleem te zijn, daar zijn sniffers voor.

Alleen relevant indien men je gateway gehacked heeft, en in z'n geval is MySQL je laatste zorg. IP spoofing op TCP nivo is echt een fabeltje. In een switched netwerk is sniffen zowiezo al een probleem, laat staan dat d'r nog routers van derden tussen zitten waar je zowiezo geen controle over hebt.

Klopt, iedere service is in principe een gevaar voor het systeem. Daaruit komt het het principe dat je altijd zo min mogelijk services moet hebben draaien, nooit services met root-privileges moet draaien.. en je services up to date moet houden.

De meeste services draaien tegenwoordig on een eigen UID, alleen wanneer het echt niet kan wordt daar vanaf geweken. Verder zijn daar zaken als capabilities en jailroots voor uitgevonden.

Ik zie niet zoveel reden om en MySQL database direct bereikbaar te maken via het internet omdat het (zoals eerder gezegt) niet zoveel kan zonder frontent. Mocht het wel nuttig zijn, dan zou ik iig een SSH-tunnel aanraden.

Inderdaad. Alleen smtp, pop3, imap, dns en ssh hebben een 'ik ben benaderbaar' recht als je het mij vraagt.

[DiedX]

igmar schreef op woensdag 31 augustus 2005 @ 15:24:
[...]


Alleen relevant indien men je gateway gehacked heeft, en in z'n geval is MySQL je laatste zorg. IP spoofing op TCP nivo is echt een fabeltje. In een switched netwerk is sniffen zowiezo al een probleem, laat staan dat d'r nog routers van derden tussen zitten waar je zowiezo geen controle over hebt.

Dat switched netwerk is een beetje onzin. Zoek maar eens naar MIM-attacks. Verder heb ik er niets aan toe te voegen

[Anoniem: 13055]

igmar schreef op woensdag 31 augustus 2005 @ 15:24:
[...]
Inderdaad. Alleen smtp, pop3, imap, dns en ssh hebben een 'ik ben benaderbaar' recht als je het mij vraagt.

Mja, die vlieger gaat niet op in een omgeving waar je niet alleen gebruik van maakt. Zoals anderen in dit topic ook al opmerkte, soms zijn frontends reuze handig (doe ik zelf ook gebruiken), en dan is het openzetten van die poort gerechtigt. De afweging zou niet alleen gebaseerd moeten zijn op hoe "veilig" de services zijn, maar ook wat ermee gedaan moet worden. Natuurlijk moet je dan wel encryptie toepassen. Overigens zou ik persoonlijk op z'n minst http/https/ftp willen toevoegen aan dat lijstje

[igmar]

DiedX schreef op woensdag 31 augustus 2005 @ 19:06:
Dat switched netwerk is een beetje onzin. Zoek maar eens naar MIM-attacks. Verder heb ik er niets aan toe te voegen

Een MiM attack vereist of toegang tot het medium (indien je een lokaal switched network wil hacken), en anders controle over een node die een rol speelt. Ook de risico's van een MiM attack vind ik vreselijk overdreven, al zijn sommige protocollen (oa DNS) er wel gevoelig voor.

[igmar]

Anoniem: 13055 schreef op donderdag 01 september 2005 @ 16:37:
Mja, die vlieger gaat niet op in een omgeving waar je niet alleen gebruik van maakt. Zoals anderen in dit topic ook al opmerkte, soms zijn frontends reuze handig (doe ik zelf ook gebruiken), en dan is het openzetten van die poort gerechtigt.

Dat zal ik niet ontkennen. Het vereist dan echter wel een actief patch en security beleid, anders ga je een keer nat.

De afweging zou niet alleen gebaseerd moeten zijn op hoe "veilig" de services zijn, maar ook wat ermee gedaan moet worden. Natuurlijk moet je dan wel encryptie toepassen. Overigens zou ik persoonlijk op z'n minst http/https/ftp willen toevoegen aan dat lijstje

Tuurlijk. En dingen zijn tegenwoordig goed dicht te zetten, zeker met wat extra kernel-features (grsec, selinux, etc).