[MySQL SRV] Handshake randomizen of encrypten

Pagina: 1
Acties:

  • remco_k
  • Registratie: April 2002
  • Laatst online: 19:32

remco_k

een cassettebandje was genoeg

Topicstarter
Ik heb een MySQL server draaien en die moet voor thuiswerkers beschikbaar zijn.
Naast alle andere beveiligingsmaatregelen die ik reeds genomen heb wil ik er nog 1 nemen, het randomizen/encrypten van de handshake en misschien de hele tcp/ip communicatie tussen server en clients ecnrypten. (of iets wat ervoor doorgaat).
Niet dat ik bang ben om 'afgeluisterd' te worden maar omdat ik niet wil dat de handhake prompt van de MySQL server verraad welke versie van de MySQL server achter het openstaande poortje hangt.

Als ik nu bijv. in cmd prompt dit doe:
code:
1
telnet 86.86.XXX.XX 5678

(5678 = poort waarop ik de server naar de buitenwereld open heb staan)
Dan komt er als antwoord een handshake te staan, ziet er ongeveer zo uit:
7
4.1.15-ntmRNoc.....<knip>
Dit is de handshake die de MySQL server terug geeft.
En uit die 2e regel kan de hele f*ckin' wereld opmaken wat voor server erachter hangt en daar hou ik niet van. Om dus potentiele inbraak pogingen te voorkomen wil ik dat deze regel niet of anders word weergegeven.
Met 'anders' doel ik dan op encryptie (zoals bij een DSM plugin van UltraVNC) of een 'bedachte' (randomize ?) versie van MySQL, zodat de bezoeker om de tuin word geleid. (zoals volgens mij ook bij Apache webservers kan worden gedaan).
Ik ben me ervan bewust dat de clients er wellicht voor aangepast moeten worden, dat is geen probleem. De software is in eigen huis geschreven.

Voordat ik allerlei andere handige tips krijg op het gebied van beveiliging:
Alle users die toegang tot deze server hebben zijn beperkt op het inloggen vanaf vooraf ingestelde IP nummers.
root kan alleen op localhost inloggen.
De router heeft de poort via NAT openstaan naar buiten toe en ondersteund NIET dat deze poort alleen voor bepaalde IP nummers toegankelijk zijn, hij staat dus open voor de hele wereld.
Maar ik vind dit niet veilig genoeg, ik haat het als iedereen maar kan zien wat er achter een luisterend poortje schuilgaat. In mijn geval en 4.1.14 MySQL servertje.

Effe de specs voor het geval dat nodig is:
MySQL Server 4.1.14 op een W2K pro machine met voldoende geheugen en diskspace.

Iemand een tip die mij de goede richting uitstuurd?

Alles kan stuk.


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Compileer de source zelf opnieuw, dan kan je elk versienr invullen wat je wilt ( bedenk wel dat sommige mysql-clients hier een check op doen )

  • remco_k
  • Registratie: April 2002
  • Laatst online: 19:32

remco_k

een cassettebandje was genoeg

Topicstarter
Gomez12 schreef op maandag 29 mei 2006 @ 19:30:
Compileer de source zelf opnieuw, dan kan je elk versienr invullen wat je wilt ( bedenk wel dat sommige mysql-clients hier een check op doen )
Mja, op zich wel een goeie suggestie maar volgens mij is die wel erg... uh, hoe zeg je dat ... ´luguber´ ? Ik houd 'm in gedachten.
De clients zijn het probleem niet, die heb ik zelf gemaakt.

Alles kan stuk.


  • DJ Buzzz
  • Registratie: December 2000
  • Laatst online: 20:12
Even iets anders, heb je MySQL al wel via een SSL verbinding draaien? Dan is alles gelijk ook geencrypt :)

http://dev.mysql.com/doc/refman/4.1/en/secure-basics.html

  • remco_k
  • Registratie: April 2002
  • Laatst online: 19:32

remco_k

een cassettebandje was genoeg

Topicstarter
djbuzzz schreef op maandag 29 mei 2006 @ 22:49:
Even iets anders, heb je MySQL al wel via een SSL verbinding draaien? Dan is alles gelijk ook geencrypt :)

http://dev.mysql.com/doc/refman/4.1/en/secure-basics.html
Goeie tip, handig stukje documententatie. Ik hoopte eigenlijk op een oplossing die wat makkelijker te implementeren is / niet al te veel tijd kost. Als ik dit zo zie dan gaat me dit een paar avonden klooien kosten, wetende dat ik m'n MySQL server op W2K pro heb draaien, is dat volgens mij meteen al een probleem. Maar als ik tijd over heb, ga ik hier mee spelen.

Edit:
Eigenlijk vergeet ik de belangrijkste vraag te stellen: Is die handshake dan 'onleesbaar' geworden?

[ Voor 9% gewijzigd door remco_k op 29-05-2006 23:30 ]

Alles kan stuk.


  • Guru Evi
  • Registratie: Januari 2003
  • Laatst online: 23-12-2025
Een SSL (of TLS) verbinding maakt gebruik van een public/private key en is dus zolang de private key van beide zijden niet publiek is, heel erg veilig. De "handshake" zoals jij het noemt moet je dan ook niet beveiligen want je bent in principe niets met een public key zonder de private key. Waar jij aan denkt is een encryptie met een enkele key of algoritme (zoals UUEncode, ROT13) zodat alle data met dezelfde key wordt geencrypteerd en gedecrypteerd wordt. Dat is zeker niet veilig (en ik denk niet dat dit kan geimplementeerd worden in de moderne systemen) dus moet je niet aan beginnen.

Een handshake zomaar eenzijdig randomizen zal denk ik niet gaan, omdat de andere kant moet weten wat eraan komt en hoe het te behandelen anders zou het geen "handshake" zijn. Meer informatie over handshakes, encryptie, public/private keys en andere kan ik wel iewat uitleggen maar is puur theorie en vind je terug op Wikipedia of Google.

Documentatie is blijkbaar hierboven al gelinkt en meer te vinden op Google weliswaar of bij problemen is er ook GoT.

Wat je ook kunt doen als alternatief of bovenop het vorige voorbeeld is een soort van tunnel of virtueel netwerk te maken via een SSH tunnel of een VPN verbinding. Het probleem is dat het allemaal niet zo heel eenvoudig is (tov. geen encryptie) maar het toch wel de moeite waard is zeker eenmaal je SQL verkeer buiten je beveiligd netwerk gaat.

[ Voor 39% gewijzigd door Guru Evi op 30-05-2006 00:47 ]

Pandora FMS - Open Source Monitoring - pandorafms.org

Pagina: 1