Linux kan beslist als veilig worden aangemerkt -- of veiliger -- dan besturingssystemen van andere verkopers. Toegegeven, gezien Linux steeds populairder wordt, wordt het een zeer aantrekkelijk doelwit voor crackers om hun inbreekpogingen op te concentreren. Er zijn uitbuitingen die van tijd tot tijd worden ontdekt, de open natuur van Linux betekent echter gewoonlijk dat dergelijke uitbuitingen snel worden gepatcht, en aankondigingen met betrekking tot de beveiliging met óf tijdelijke oplossingen of verwijzingen naar bijgewerkte software worden wijd verspreid.
Ik zal me niet voordoen als een expert in zaken aangaande beveiliging, alhoewel ik me hiervan op z'n minst bewust ben, waarvan ik geloof dat ze een groot deel van de strijd uitmaken om systemen zo veilig mogelijk te maken. Alhoewel bewustzijn en ijver in het bijhouden van updates aangaande de beveiliging op geen enkele wijze garanderen dat iemand de beveiligingsmaatregelen op het systeem te slim af is, is de waarschijnlijkheid van een inbraak enorm afgenomen.
Alhoewel er beveilingsexploitaties in externe services zijn gevonden die door crackers zouden kunnen hebben worden gebruikt om op het systeem in te breken (bijvoorbeeld de IMAP daemon exploitatie), geloof ik dat het veel waarschijnlijker is dat een vastbesloten cracker het systeem van binnenuit zal binnendringen. Vergeleken met een handjevol services die met de buitenwereld communiceren, zijn er duizenden commando's en utilities beschikbaar vanuit de shell, één of meer die mogelijk bugs bevatten die die kunnen worden uitgebuit door de beveiliging binnen te dringen (met dat te hebben gezegd, moet ik toegeven dat ik ontdekte dat één van de servers die ik onderhoud, gecompromitteerd was geweest via een externe service).
Om deze reden, raad ik je aan te vermijden shell-accounts aan gebruikers uit te geven, tenzij dit absoluut noodzakelijk is. Zelfs als je in aanmerking neemt dat je gebruikers volledig te vertrouwen zijn en geen angstig voorgevoel hebt bij het ze toegang geven tot de shell, is slechts één van deze gebruikers met een zwak wachtwoord voldoende. Een cracker die van buitenaf zijn weg op je systeem vindt door dit zwakke wachtwoord te exploiteren zal dan op zijn gemak in staat zijn intern als hem of haar te werk te gaan, op zoek naar verdere zwakheden.
Er zijn gelukkig een aantal zaken die je kunt doen om de beveiliging van je Linux-systeem enorm te verbeteren. Aangezien een gedetailleerde bespreking van beveiligingszaken buiten het kader van dit document valt, geeft de volgende checklist je het belangrijkste wat je zou moeten doen om de beveiliging uit te breiden:
Upgrade systeemtools, applicaties, en kernel: Verreweg de meest algemene oorzaak van het inbreken op een systeem is door geen toewijding uit te oefenen in het behouden van een up-tot-date server. Het regelmatig uitvoeren van upgrades van de systeemkernel, tools en utilities zal er voor zorgen dat je systeem niet met oudere items is opgevuld waarvan bekend is dat exploitaties beschikbaar zijn. Zie voor details over het bijhouden van een up-to-date server the section called Downloaden en Installeren van Red Hat Updates in Chapter 4, als ook the section called Strategiën voor het Bijhouden van een Up-to-date Systeem in Chapter 10.
Shadow passwords: Je zou beslist gebruik moeten maken van Shadow passwords; het is eenvoudig om naar dit wachtwoord-formaat over te schakelen. Zie the section called Linux Password & Shadow Bestandsformaten in Chapter 6 voor de details.
Slim wachtwoord-beheer: Zorg er voor dat wachtwoorden, vooral voor gebruikers waaraan je toegang tot een shell hebt toegekend, sterk zijn en vaak worden gewijzigd. Bied bij het gebruik van meerdere servers bovendien weerstand tegen de verleiding voor alle servers hetzelfde wachtwoord te gebruiken (anders kan een cracker die op één server met het ontdekte wachtwoord inbreekt, op al deze servers inbreken).
Gebruik secure shell (ssh): Schakel over naar het gebruik van ``ssh'' in plaats van ``telnet''. Telnet is om twee redenen niet veilig: Ten eerste, worden sessies niet versleuteld, wat betekent dat alles, inclusief de naam en het wachtwoord van de gebruiker als gewone tekst worden overgeseind. Ten tweede is een open telnetpoort één van de eerste plaatsen waar een cracker een verbinding mee zal proberen te maken.
Ssh voorziet in versleutelde en gecomprimeerde verbindingen en levert wezenlijk meer beveiliging dan telnetverbindingen. Je kunt onder Linux een ssh-server draaien (waarmee veilige inkomende verbindingen mogelijk zijn) als ook als een client (voor veilige uitgaande verbindingen). Binaire RPM-packages zijn te vinden op ftp://ftp.replay.com/pub/replay/redhat/i386/. Je hebt hiervoor de volgende bestanden nodig (tegen de tijd dat je dit leest kan het zijn dat er nieuwere versies beschikbaar zijn):
ssh-1.2.27-5i.i386.rpm Het basispakket.
ssh-clients-1.2.27-5i.i386.rpm Clients voor uitgaande connecties.
ssh-extras-1.2.27-5i.i386.rpm Een aantal handige op perl gebaseerde scripts.
ssh-server-1.2.27-5i.i386.rpm Server voor inkomende connecties.
![]() | Noot: De hierboven genoemde SSH RPM-bestanden zijn de internationale versies. Als je in de U.S. of Canada verblijft, kun je ervoor kiezen de U.S. packages te downloaden (die mogelijk sterkere encryptie algoritmen hebben); deze packages hebben achter het versienummer een achtervoegsel ``us'' in plaats van ``i''. Het is volgens de U.S. wet verboden sterk cryptografische producten buiten de U.S. of Canada te exporteren. Hopelijk zullen de imbecielen in de U.S. Department of Justice uiteindelijk op een dag het licht zien, en deze domme beperking verwijderen (Red Hat neemt vanwege deze reden SSH niet op in hun distributie, en we leiden hier allemaal onder). |
Mochten je Windows-gebruikers protesteren over het feit dat ze niet langer een verbinding met je systeem tot stand kunnen brengen, dan zullen ze blij zijn te weten dat er verscheidene vrij-verkrijgbare ssh-clients voor Windows beschikbaar zijn:
![]() | Noot: Als je besluit op ssh over te gaan, zorg er dan voor dat je het op alle servers installeert. Vijf veilige en één onveilige server is een verspilling van tijd, vooral als je zo dwaas bent voor meer dan één server hetzelfde wachtwoord te gebruiken. |
Beperk de toegang tot externe services: Vervolgens zou je het bestand ``/etc/hosts.allow'' als ook het bestand ``/etc/hosts.deny'' moeten wijzigen om de toegang tot services naar externe hosts te beperken. Hier is een voorbeeld van hoe je telnet en ftp-toegang kunt beperken. Als eerste het bestand ``/etc/hosts.allow'':
# hosts.allow in.telnetd: 123.12.41., 126.27.18., .mijndomein.naam, .andere.naam in.ftpd: 123.12.41., 126.27.18., .mijndomein.naam, .andere.naam |
Hiermee zou het iedere host in de IP class C's 123.12.41.* en 126.27.18.*, als ook iedere host binnen de mijndomein.naam en andere.naam domeinen zijn toegestaan telnet- en ftp-connecties tot stand te brengen.
Vervolgens het bestand ``/etc/hosts.deny'':
# hosts.deny in.telnetd: ALL in.ftpd: ALL |
Deactiveer en de-installeer onnodige services: Wijzig het bestand ``/etc/inetd.conf'', en deactiveer (dwz. plaats er een commentaarteken ``#'' voor) alle services die niet nodig zijn (als je ssh gebruikt, zoals ik je hiervoor aanraadde, wil je wellicht de ``telnet'' service deactiveren). Nadat je dit hebt gedaan, typ je als root ``/etc/rc.d/init.d/inet restart'' om de inetd-daemon opnieuw op te starten met de gemaakte wijzigingen.
Installeer een beveiligings-detectiesysteem: Neem het installeren van beveiligingsprogramma's, zoals ``Tripwire'' in overweging (zie http://www.tripwiresecurity.com/), waarmee inbreuk kan worden gedetecteerd en ``Abacus Sentry'' (zie http://www.psionic.com/abacus/) welke van hulp kan zijn bij de voorkoming ervan.
Te danken aan ijver:Door een oogje op je systeem te houden, het uitvoeren van willekeurige beveiligingscontrole's (wat zo simpel kan zijn als het controleren op verdachte velden in de wachtwoordbestanden, het bestuderen van je lijst met processen, en het controleren van je logbestanden op verdachte inhoud) kun je een heel eind komen bij het veilighouden van je systeem. Rapporteer bovendien alle pogingen om in te breken aan de daarvoor van toepassing zijnde authoriteiten -- het kan een gedoe zijn dit te doen, vooral als je systeem verscheidene van deze aanvallen in een gegeven week ziet, maar dergelijke rapporten geven de verzekering dat potentiële crackers worden afgeschrikt door de dreiging van een straf en bovendien verzekert het dat systemen van anderen (die er zelf wellicht ook mee zijn geconfronteerd) veilig blijven.
In de veronderstelling dat je de systeemtools en applicaties met het ``RPM'' utility installeert en upgrade, wil je de integriteit van je geïnstalleerde packages wellicht verifiëren door ze met het volgende commando te controleren:
rpm --verify -a > /tmp/rpm-audit.txt |
Met dit commando zullen alle relevante bestanden met de RPM-database op je systeem worden vergeleken, en zal door het tonen van een '5' worden weergegeven welke zijn gewijzigd. Hier is wat voorbeelduitvoer van een dergelijke controle:
S.5....T /bin/ls S.5....T /usr/bin/du ......G. /dev/tty5 .....U.. /dev/vcs5 .....U.. /dev/vcsa5 S.5....T c /etc/lynx.cfg S.5....T c /etc/sendmail.cf |
In dit voorbeeld is een lijst te zien met zeven bestanden, vier daarvan zijn gewijzigd. Nu zullen er kennelijk verscheidene, misschien vele bestanden zijn die zijn gewijzigd als je je systeem geheel hebt aangepast. Een korte controle van de bestanden /etc/lynx.cfg en /etc/sendmail.cf misschien visueel of misschien vanaf backup, zouden de echte door jou aan het systeem gemaakte wijzigingen aan de configuratie kunnen openbaren.
In het voorbeeld hierboven zijn twee van de gewijzigde bestanden binaire uitvoerbare bestanden? Naar alle waarschijnlijkheid zijn deze twee binaire bestanden , het ``ls'' commando als ook het ``du'' commando, in feite trojan binaries die een systeemcracker met schandelijke doeleinden heeft geïnstalleerd (een ``diff'' commando toegepast op enige gewijzigde binaire bestanden met die teruggezet vanaf een backup of RPM zou andere verschillen ten toon kunnen spreiden; verdere aanwijzigingen van trojans).
(Voor meer informatie over ``RPM'', zie de the section called Het gebruik van de Red Hat Package Manager (RPM) in Chapter 10.)
Voor meer informatie over aan beveiliging gerelateerde onderwerpen bestaat een uitstekende bron, met de titel “Securing RedHat 5.x”. Dit document is beschikbaar op http://redhat-security.ens.utulsa.edu/. Een uitstekende bron voor Linux crypto en daaraan gerelateerde software is te vinden op http://replay.com/redhat/.