server veilig?
Als je aan het programmeren bent, moet je er dan vanuit gaan dat alles wat op je server staat veilig is?
Kan ik bijvoorbeeld op het private gedeelte van mijn server open en bloot configuratiebestanden plaatsen waarin ik wachtwoorden van databases zet? Of... moet ik die wachtwoorden bijvoorbeeld encrypten en in de code vervolgens weer decrypten? Of heeft dat totaal geen zin? Hoe doen jullie dat? Gaan jullie er vanuit dat alles wat op de server staat veilig is? Of nemen jullie toch nog extra voorzorgsmaatregelen?
Als jij een stukje ruimte reserveert voor config bestanden moeten ze zeker niet staan waar men bij kan.
Dus bijvoorbeeld in /var/www/ of /home/user/public_html, dus niet in de doc_root.
maar echt totaal daar buiten.
Hoezo encrypten en decripten?
Een config bestand is altijd een leesbaar bestand.
Dus dat heeft naar mijn mening niet veel zin.
Wat wel belangrijk is is dat de verbindingen goed gecontroleerd word.
Dus als iets van 127.1.1 moet komen niet toestaan dat het van een ander ip adres komt.
Stel een bezoeker bezoekt een van mijn websites en er moet info uit de database worden gehaald, kan het dan kwaad om het wachtwoord voor de database gewoon "plain" (oversleuteld) in een configuratiebestandje te plaatsen.
Ik kan in mijn configuratiebestand zetten:
db_pass = broodjefrikandel
Maar ik zou het ook kunnen encrypten zodat er in het configuratiebestand staat:
db_pass = fgHASDF545JE_%$S
En dat ik dan in de code zeg:
$db_pass = decrypt($config['db_pass']);
Stel dat een hacker zou inbreken op mijn server dan heeft hij een versleuteld wachtwoord en kan hij niet inbreken in de database. Maar van de andere kant... hij heeft dan ook toegang tot de code en als hij even gaat zoeken dan weet hij ook hoe hij het moet decrypten.
Dus vandaar mijn vraag. Heeft het zin om extra voorzorgsmaatregelen te treffen voor het geval iemand je server binnendringt, of is het dan sowieso toch al te laat?
Als men in je code kan rommelen dan zit het probleem dus niet in je config maar in je rechten.
Het heeft dan ook totaal geen nut om de/en-cryptie te gebruiken.
Belangrijk is dat je de config bestanden buiten de doc_root staan.
Dus bijvoorbeeld in /root/ daar mag alleen root komen en kan een user nooit bij.
Je zit denk ik nu teveel de focus te leggen op iets wat niet van belang is. ;)
Ook moet je het zo maken dat men per user iets mag gebruiken.
Dus:
user pietje heeft een database bijvoorbeeld pietje met password
user jantje heeft een database ala jantje met password.
Dus niet:
Ozzie met password en deze beheert alle databases.
Of nog erger mag CREATE UPDATE TRUNCATE DROP e.d. uitvoeren.
Alleen die rechten geven LEES: PER USER die ze nodig hebben niets meer of minder.
Ook is het belangrijk dat men niet te gissen wachtwoorden gebruikt.
Dus niet iets van: Ozzie1973 maar Oxv2Za69*
In je php code staan je database gegevens toch ook gewoon text/plain leesbaar.
En is het daar al eens mis mee gegaan?
Gewijzigd op 04/05/2013 23:57:28 door Bart V B
Als men in je code kan rommelen dan zit het probleem dus niet in je config maar in je rechten."
Nee, dat is is niet het geval. Er kan niemand op mijn server. Ik ben de enige die erop kan. Het is meer een soort van "wat als"-situatie. Stel dat een hacker toch zou inbreken op mijn server, en daar staat netjes een config bestand met wachtwoorden van databases. Maar daar is inderdaad niks aan te doen. Als ze inbreken ben je gewoon plat gezegd de lul.
"Je zit denk ik nu teveel de focus te leggen op iets wat niet van belang is. ;)"
ja dat zou goed kunnen :)
"Dus bijvoorbeeld in /root/ daar mag alleen root komen en kan een user nooit komen."
Ik werk maar met 1 user dus dit gaat voor mij niet echt op.
Maar waar het mij dus om gaat is of je zomaar iets unencrypted in je config kan zetten. Maar daar heb je het antwoord al op gegeven. De overige tips zijn duidelijk.
Niet met 1 user werken, maar met meerdere users.
(vooral het stukje database is hier van belang.)
Zoals je weet kan root alles. Database aanmaken, droppen, truncate e.d.
Je wil niet dat 1 user dit allemaal kan. Ze moeten alleen die dingen kunnen doen die ze nodig hebben.
Een nieuwe database aanmaken hoeft een "normale" user niet als men alleen data heen hen weer sleept.
Zo ook op php nivo.
(correct me if i am wrong) Maar je bent toch een soort van cms/webshop systeem aan het maken toch?
In dat geval zal je waarschijnlijk ook wel klanten gaan krijgen of hebben.
Die moeten niet onder 1 user die dingen kunnen doen die jij niet wil.
Daarom is het van belang dat je het per user opzet.
Zo krijg je nooit (jou wat als vraag) dat men dingen doen die jij niet wil.
Laat ik het nog eenvoudiger zeggen:
Ik neem aan dat jij jou email adres toch ook niet deelt met al jou klanten ala IMAP?
Dus waarom zou je dat met andere dingen op je server wel doen?
Vandaar dat ik er zo op hamer dat je echt je systeem moet gaan inrichten per user.
Je krijgt een betere scheiding en als er dan toch nog wat omvalt, dan gaat alleen dat ene om en heeft de rest daar waarschijnlijk niet veel last van.
Gewijzigd op 05/05/2013 00:15:40 door Bart V B
Veel belangrijker is waarschijnlijk de veiligheid van de server. Als deze goed beveiligd is kan er normaal gezien niemand aan de bestanden en zoals gewoonlijk buiten de root plaatsen.
Ja, klopt...
Het "probleem" is dat al mijn domeinen als add-on domains moeten worden ingesteld want anders kan ik onderling geen bestanden delen. Ik heb dus maar 1 FTP account en daar vallen alle domeinen onder. Normaal gesproken is dat niet wenselijk. Echter, de enige die toegang zal hebben tot FTP ben ik zelf. Daarom is het dus geen probleem. Eventuele klanten krijgen geen toegang. Wél wil ik iedere website z'n eigen database geven met eigen login-gegevens. En de databse users krijgen dan beperkte rechten.
Volgens mij doe ik het op die manier goed?
Toevoeging op 05/05/2013 00:20:31:
@Aaron: ja inderdaad.
Quote:
Het "probleem" is dat al mijn domeinen als add-on domains moeten worden ingesteld want anders kan ik onderling geen bestanden delen.
Dus als ik je goed begrijp heb je/ kan je je users niet instellen per domein?
Waarom tackel je dat probleem dan niet?
Wat hebben de domeinen te maken met waar jij je bestanden neerzet?
Als jij een map hebt, noem maar even iets geks /ozzie/framework/
Dan kan je toch nog steeds iets laten verwijzen naar:
/home/user_1/public_html
Even zo uit mijn hoofd zou het zoiets moeten zijn
Code (php)
1
ln -s /ozzie/framework/* /home/user/public_html/
Waar de core bestanden staan is toch niet van belang?
Want als jij een map /ozzie/framework/ shared in de code van die gebruiker dan ben je er toch al?
Ze kunnen jou systeem niet weghalen, maar kunnen wel gebruik maken van jou systeem.
Quote:
Eventuele klanten krijgen geen toegang. Wél wil ik iedere website z'n eigen database geven met eigen login-gegevens. En de databse users krijgen dan beperkte rechten.
Dat is uiteraard goed.
En als de klant zijn eigen plaatjes wil verwerken bijvoorbeeld?
Als dat 1 klant is kan je hem nog wel eens helpen met een ftp actie.
Maar als je 100 klanten hebt dan word dat al een stuk lastiger lijkt me.
Ga je dit allemaal via formuliertjes zitten doen met wat php magic?
Gewijzigd op 05/05/2013 00:47:36 door Bart V B
Een klant krijgt geen ftp-toegang, maar wel toegang tot z'n eigen cms. Uiteindelijk moet hij daar alle relevante dingen kunnen doen.
(Het is overigens wel een hele klus, dus of het ooit allemaal van de grond komt is nog maar afwachten... :-))
Maar wat voor architectuur heb je bedacht dat je per se maar 1 gebruiker wilt op je systeem?
Je kan toch prima je core bestanden in een library zetten die je in het includepath zet en dan per klant een bootstrap neerzetten die alles opstart? En die kan je netjes per user neerzetten met hun rechten bescherming e.d.
Ik wil bijv. dat (in sommige gevallen) websites gebruik kunnen maken van templates of bestanden van andere websites. Hier heb ik dan content mappen voor nodig waar die websites bij kunnen. Daarnaast heb ik 1 bootstrap die alles afvangt en het request naar de juiste locatie stuurt.
Stel dat iedere website z'n eigen user krijgt, dan krijg je op de server zo'n soort structuur:
/pad/naar/website1/public/
/pad/naar/website1/private/
/pad/naar/website2/public/
/pad/naar/website2/private/
enz.
Omdat dat allemaal beveiligd is, kan website1 niet bij website2 komen en vice versa, terwijl dat in sommige gevallen wel nodig is. Vandaar dat ik het op deze manier moet doen.
Gewijzigd op 05/05/2013 14:05:11 door Ozzie PHP