fedora 11
Beveiligings gids
Een gids voor het beveiligen van Fedora Linux
Uitgave 1.0
Bericht
Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0, (the latest version is presently available at http://www.opencontent.org/openpub/).
Fedora and the Fedora Infinity Design logo are trademarks or registered trademarks of Red Hat, Inc., in the U.S. and other countries.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat Inc. in the United States and other countries.
All other trademarks and copyrights referred to are the property of their respective owners.
Documentation, as with software itself, may be subject to export control. Read about Fedora Project export controls at http://fedoraproject.org/wiki/Legal/Export.
Samenvatting
De Linux beveiligings gids is gemaakt om Linux gebruikers te helpen
met het leren van de processen en praktijken voor het beveiligen
van werkstations en servers tegen locale en indringing op aftstand,
uitbuiting en kwaadwillige activiteiten. De Linux beveiligings gids
beschrijft nauwkeurig de planning en de gereedschappen die nodig
zijn voor het maken van een beveiligde computer omgeving voor data
centrum, werkomgeving, en thuisgebruik. Met de juiste
administratieve kennis, oplettendheid, en gereedschappen, kunnen
systemen die Linux draaien zowel volledig functioneel zijn, als
beveiligd zijn tegen de meest voorkomende indringings en
uitbuitings methodes.
- Voorwoord
- 1. Beveiligings overzicht
- 2. Je netwerk beveiligen
- 2.1. Werkstation beveiliging
- 2.2. Server beveiliging
- 2.3. Eenmalig inschrijven (Single sign-on - SSO)
- 2.4. Pluggable Authentication Modules (PAM)
- 2.5. TCP wrappers en xinetd
- 2.6. Kerberos
- 2.6.1. Wat is Kerberos?
- 2.6.2. Kerberos terminologie
- 2.6.3. Hoe werkt Kerberos
- 2.6.4. Kerberos en PAM
- 2.6.5. Het instellen van een Kerberos 5 server
- 2.6.6. Het instellen van een Kerberos 5 client
- 2.6.7. Domein naar gebied afbeelding
- 2.6.8. Instellen van secundaire KDC's
- 2.6.9. Cross gebieds authenticatie instellen
- 2.6.10. Extra hulpbronnen
- 2.7. Virtuele privé netwerken (VPN's)
- 2.8. Firewalls
- 2.9. IPTables
- 3. Versleuteling
- 4. Algemene principes van informatie beveiliging
- 5. Veilige installatie
- 6. Software onderhoud
- 7. Referenties
Voorwoord
1. Document Conventie
Dit handboek hanteert verscheidene conventies om bepaalde woorden of zinsdelen te benadrukken en aandacht te vestigen op specifieke delen van informatie.
In PDF en papieren edities gebruikt dit handboek Liberation Fonts set lettertypen. Het Liberation lettertype wordt ook gebruikt in HTML-edities indien dit lettertype op uw computer geïnstalleerd is. Indien dat niet het geval is, worden alternatieve, gelijkwaardige lettertypen gebruikt. Noot: bij Red Hat Enterprise Linux 5 en later wordt de Liberation Font set standaard meegeleverd.
1.1. Typografische Conventies
Vier typografische conventies worden gebruikt om aandacht te vestigen op specifieke woorden en zinsdelen. Deze conventies -en de omstandigheden waaronder zij gebruikt worden- luiden als volgt:
Mono-spaced Bold
Wordt gebruikt om systeem input, waaronder shell commando's, bestandsnamen en paden aan te geven. Wordt ook gebruikt bij toetsaanduiding of toetsencombinaties. Voorbeeld:
Om de inhoud van het bestandmijn_onwijsgoed_verkopende_boekin uw huidige directory te zien, voert u het commandocat mijn_onwijsgoed_verkopende_boekin bij de shell-prompt en drukt u op Enter om het commando uit te laten voeren.
Bovenstaande bevat een bestandsnaam, een shell-commando en een toetsaanduiding, alle getoond in Mono-spaced Bold en alle te onderscheiden dankzij hun context.
Toetsencombinaties kunnen worden onderscheiden van toetsaanduiding door het plusteken dat elk deel van een toetsencombinatie aan elkaar verbind. Voorbeeld:
Druk op Enter om het commando te laten uitvoeren.Druk op Ctrl+Alt+F1 om naar de eerste virtuele terminal over te schakelen. Druk op Ctrl+Alt+F7 om terug te keren naar uw X-Windows sessie.
De eerste zin benadrukt de bepaalde toets die moet worden ingedrukt. De tweede benadrukt twee reeksen van drie toetsen, waarbij de toetsen van elke reeks tegelijk moet worden ingedrukt.
Indien broncode wordt besproken, worden klassennamen, functies, variabele namen en resultaten die in een paragraaf worden genoemd, weergegeven als hier boven afgedrukt, namelijk in
Mono-spaced Bold. Voorbeeld:
Onder bestandsgerelateerde klassen vallenfilesystemvoor bestandsystemen,filevoor bestanden, endirvoor directories. Elke klasse heeft haar eigen set van permissies.
Proportional Bold
Wordt gebruikt om woorden of zinsdelen op een systeem aan te duiden, waaronder applicatie namen, dialoogtekst-boxen, gelabelde toetsen, checkbox en radiobutton labels, menutitels en submenutitels. Voorbeeld:
Kies uit de hoofdmenubalk om Muis Voorkeuren te openen. In de Knoppen tab, klik de Linkshandige muis checkbox aan en klik om de primaire muisknop van links naar rechts te wisselen (waardoor de muis beter geschikt is geworden voor linkshandig gebruik).Om een speciaal teken in een gedit bestand op te nemen, kiest u uit de hoofdmenubalk. Vervolgens kiest u uit de Tekentabel menubalk, typ de naam van het teken in het Zoek veld en klik . Het teken dat u zoekt zal worden gemarkeerd in de Tekentafel. Dubbel-klik op dit teken om het in de Te kopiëren tekst veld op te nemen en klik dan de knop. Keer terug naar uw document en kies uit de gedit menubalk.
De bovenstaande tekst bevat applicatienamen, systeemwijde menunamen en onderdelen, applicatie specifieke menunamen, en knoppen en tekst van een GUI-interface, alle vertoond in Proportional Bold en alle te onderscheiden dankzij hun context.
Merk het -teken op, gebruikt om aan te geven dat door een menu en sub-menu wordt gelopen. Dit voorkomt het gebruik van de nogal omslachtige 'Selecteer van het sub-menu in het menu uit de hoofdmenubalk'-omschrijvingen.
Mono-spaced Bold Italic of Proportional Bold Italic
Mono-spaced Bold of Proportional Bold behandelt indien cursief gedrukt altijd vervangbare of wisselende teksten. Cursief wijst op niet letterlijke tekst of toont tekst dat wisselt naar omstandigheden. Voorbeeld:
Om verbinding te maken met een andere computer met behulp van ssh, typt usshbij een shell prompt.gebruikersnaam@domein.naamHetmount -o remountcommando mount opnieuw het genoemde bestandsysteem. Om bijvoorbeeld hetfile-system/homebestandsysteem opnieuw te mounten, gebruikt men hetmount -o remount /homecommando.Om de versie van een huidig geïnstalleerd pakket te zien, gebruikt u hetrpm -qcommando. Dit zal het volgende resultaat opleveren:package.package-version-release
Let op de woorden in bold italics in bovenstaande tekst — username, domain.name, file-system, package, version en release. Elk woord is een [plaatshouder], hetzij voor tekst dat u invult indien u een commando typt, hetzij voor tekst die door het systeem wordt getoond.
Buiten het standaard gebruik bij het presenteren van een titel van een werk, wordt cursief ingezet om het eerste gebruik van een nieuwe en belangrijke term te benadrukken. Voorbeeld:
Wanneer de Apache HTTP Server verzoeken accepteert, zet het childprocessen of threads ter afhandeling in. Deze groep van childprocessen of threads staan bekend als een server-pool. Onder Apache HTTP Server 2.0 is de verantwoordelijkheid voor het creëren en onderhouden van deze server-pools toegewezen aan een groep modules genaamd Multi-Processing Modules (MPMs). Anders dan bij de andere modules kan slechts één module van de MPM groep door de Apache HTTP Server geladen zijn.
1.2. Pull-quote Conventies
Twee, normaal gesproken uit meerdere regels bestaande, datatypes worden visueel van de omringende tekst gescheiden.
Tekst gezonden naar een terminal wordt getoond in
Mono-spaced Roman en als volgt gepresenteerd:
books Desktop documentation drafts mss photos stuff svn books_tests Desktop1 downloads images notes scripts svgs
Opsommingen van broncode worden ook vertoond in
Mono-spaced Roman maar worden alsvolgt gepresenteerd en benadrukt:
package org.jboss.book.jca.ex1;
import javax.naming.InitialContext;
public class ExClient
{
public static void main(String args[])
throws Exception
{
InitialContext iniCtx = new InitialContext();
Object ref = iniCtx.lookup("EchoBean");
EchoHome home = (EchoHome) ref;
Echo echo = home.create();
System.out.println("Created Echo");
System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
}
}
1.3. Noten en waarschuwingen
Tenslotte gebruiken we drie visuele stijlen om aandacht te vestigen op informatie die anders misschien over het hoofd zou worden gezien.
Noot
A Note is a tip or shortcut or alternative approach to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
Belangrijk
Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring Important boxes won't cause data loss but may cause irritation and frustration.
Waarschuwing
Een waarschuwing dient niet genegeerd te worden. Waarschuwingen negeren zal ongetwijfeld leiden tot data- en haarverlies.
2. We hebben terugkoppeling nodig!
Meer informatoe over het Linux Security Guide project kan gevonden worden op https://fedorahosted.org/securityguide
Om terugkoppeling te geven over de Beveiligings gids, dien je een foutrapport in op https://bugzilla.redhat.com/enter_bug.cgi?component=security-guide&product=Fedora%20Documentation. Selecteer het juiste onderdeel in het uitklap menu.
Hoofdstuk 1. Beveiligings overzicht
Door het toenemende vertrouwen op krachtige computers in een netwerk om te helpen bedrijven draaiende te houden en contact te houden met onze persoonlijke informatie, zijn complete bedrijven ontstaan rond de praktijk van netwerk en computer beveiliging. Ondernemingen hebben de kennis en vaardigheden van beveiligings deskundigen ingeroepen om systemen correct te controleren en om aangepaste oplossingen te maken voor de werk vereisten van de organisatie. Omdat de meeste organisaties in toenemende mate dynamisch van natuur zijn, met werknemers die de IT hulpbronnen van de onderneming locaal en op afstand benaderen, is de behoefte aan beveiligde computeromgevingen sterk toegenomen.
Helaas zien de meeste organisaties (maar ook individuele gebruikers) beveiling pas op de laatste plaats, een proces dat vergeten wordt door de aandacht voor toenemende rekenkracht, productiviteit, en budgettaire zaken. De juiste beveiligings implementatie wordt vaak postmortem uitgevoerd — nadat een ongeoorloofde indringing heeft plaats gevonden. Beveiligings deskundigen zijn er over eens dat het nemen van de juiste maatregelen voordat een locatie aangesloten wordt op een onbetrouwbaar netwerk, zoals het Internet, een effectieve manier is om de meeste indringings pogingen af te wenden.
1.1. Inleiding tot beveiliging
1.1.1. Wat is computer beveiliging
Computer beveiliging is een algemene term die een breed gebied van computer en informatie verwerking afdekt. Ondernemingen die afhangen van computer systemen en netwerken om hun dagelijkse zakentransacties uit te voeren en toegang hebben tot cruciale informatie, zien hun data als een belangrijk onderdeel van hun totale bezit. Verscheidene uitdrukkingenen en metrieken zijn binnengedrongen in onze zakelijke woordenschat, zoals totale kosten van eigendom (total cost of ownership - TCO), en kwaliteit van diensten (quality of service - QoS). Met gebruik van deze metrieken kunnen ondernemingen aspecten bereken zoals data integriteit en hoge-beschikbaarheid als onderdeel van hun planning en procesbeheerskosten. In sommige industrieën, zoals electronische handel, kan het de beschikbaarheid en betrouwbaarheid van data het vertschil zijn tussen succes en mislukken.
1.1.1.1. Hoe is computer beveiliging ontstaan?
Informatie beveiliging is door de jaren heen gegroeid door het toenemende vertrouwen van publieke netwerken om hun persoonlijke, financielen en andere vertrouwlijke informatie niet te openbaren. Er zijn talrijke voorbeelden zoals de Mitnick [1]en de Vladimir Levin [2] zaken die organisaties in alle industrieën hebben aangezet om de manier waarop ze informatie behandelen te overdenken, maar ook de overbrenging en onthulling van data. De populariteit van het Internet was een van de belangrijkste ontwikkelingen die aanzette tot een toenemende inspanning in data beveiliging.
Een steeds groeiend aantal mensen gebruiken hun persoonlijke computer om toegang te krijgen tot hulpbronnen die het Internet heeft te bieden. Van onderzoeken en vinden van informatie tot electronische mail en commerciele transacties, wordt het Internet gezien als een van de belangrijkste ontwikkelingen van de 20ste eeuw.
Het Internet en zijn eerdere protocollen zijn echter ontwikkeld als een op vertrouwen-gebaseerd systeem. Dat betekent dat het Internet Protocal niet ontworpen is om zelf veilig te zijn. Er zijn geen goedgekeurde beveiligings standaarden ingebouwd in de TCP/IP comminicatie stack, waardoor het open is voor kwaadwillige gebruikers en processen over het netwerk. Moderne ontwikkelingen hebben het Internet veiliger gemaakt, maar er zijn nog steeds verscheidene incidenten die landelijke aandacht krijgen en ons op het feit attenderen dat niets geheel veilig is..
1.1.1.2. Beveiliging in deze tijd
In februari 2000 werd een Distributed Denial of Service (DDoS) aanval uitgevoerd op verscheidene van de meest gebruikte sites op het Internet. De aanval maakte yahoo.com, cnn.com, amazon.com, fbi.gov, en verscheidene andere sites volkomen onbereikbaar voor gewone gebruikers, omdat het de routers urenlang bezig hield met ICMP pakket verkeer, ook wel ping flood genoemd. De aanval werd uitgevoerd door onbekende aanvallers met gebruik van speciaal gemaakte, breed verkrijgbare programma's die kwetsbare netwerkservers opzochten en daarop client toepassingen installeerden (trojans genaamd), waarna de aanvallen van alle geinfecteerde servers de slachtoffer sites overspoelden en ze onbereikbaar maakten. Veel mensen geven de schuld aan fundementele problemen in de manier waarop routers en de gebruikte protocollen zijn ingesteld om alle binnenkomende data te accepteren, onafhankelijk waar heen of voor welk doel de pakketten verzonden worden.
In 2007 resulteerde een data inbreuk, die een algemeen bekende zwakte van het Wired Equivalent Privacy (WEP) draadloze versleutelings protocol misbruikte, in de diefstal van meer dan 45 miljoen creditkaart nummers van een globaal operende financiele instelling.[3]
In een ander voorval werden de rekening gegevens van meer dan 2.2 miljoen patienten, die bewaard werden op een backup tape, gestolen van de voor zitting uit de auto van een koerier.[4]
Er wordt geschat dat op dit moment 1.4 miljard mensen over de gehele wereld het Internet gebruiken of hebben gebruikt.[5] Te gelijkertijd:
- Elke dag worden er ongeveer 225 belangrijke incidenten met betrekking tot beveilingsinbreuken gerapporteerd aan de CERT Coordination Center in Carnegie Mellon.[6]
- In 2003 ging het aantal aan CERT gerapporteerde incidenten naar 137.529 vergeleken met 82.094 in 2002 en 52.658 in 2001.[7]
- De wereldwijde economische impact van de drie gevaarlijkste Internet virussen van de laatste drie jaar wordt geschat op 13.2 miljard $.[8]
Een aantal punten uit een globaal onderzoek van zakelijke en technologische leidinggevers "The Global State of Information Security"[9], uitgevoerd door CIO Magazine, zijn:
- Slechts 43% van de ondervraagden bewaken de naleving van beveiligingsvoorschriften door gebruikers
- Slechts 22% houdt bij welke externe bedrijven hun data gebruiken
- De oorzaak van bijna de helft van de beveiligings incidenten is omschreven als "Onbekend"
- 44% van de ondervraagden is van plan de beveiligingsuitgaven in het volgend jaar te verhogen
- 59% hebben en informatie beveiligings strategie.
Deze resultaten onderstrepen de werkelijkheid dat computerbeveiliging een meetbaar en verdedigbaar onderdeel is van IT budgetten. Organisaties die data integriteit en hoge beschikbaarheid vereisen, gebruiken de vaardigheden van beheerders, ontwikkelaars, en ingenieurs om zeker te zijn van ononderbroken betrouwbaarheid van hun systemen, diensten, en informatie. Het slachtoffer worden van kwaadwillige gebruikers, processen, of gecoördineerde aanvallen is een direkte bedreiging van het succes van de organisatie.
Helaas is systeem en netwerk beveiliging een moeilijk vak, wat een uitgebreide kennis vereist van de manier waarop een organisatie zijn informatie beschouwt, gebruikt, manipuleert en overbrengt. Het begrijpen van de manier waarop de organisatie (en de mensen die de organisatie vormen) zaken doet is van groot belang voor het maken van een juist beveiligingsplan.
1.1.1.3. Het standaardiseren van beveiliging
Bedrijven in elke industrie tak vertrouwen op voorschriften en regels die gemaakt zijn door standaardisatie organisaties zoals de American Medical Association (AMA) of de Institute of Electrical and Electronics Engineers (IEEE). Hetzelfde ideaal geldt voor informatie beveiliging. Veel beveiligings consulenten en bedrijven omarmen het standaard beveiligings model bekend als CIA, of Confidentiality, Integrity, and Availability (Vertrouwlijkheid, Integriteit, en Beschikbaarheid). Dit drie-lagen model is een algemeen geaccepteerd onderdeel om de risico's van gevoelige informatie te onderzoeken en een beveiligings tactiek uit te stippelen.. Het volgende beschrijft het CIA model in meer detail:
- Confidentiality (Vertrouwlijkheid) — Gevoelige informatie moet alleen beschikbaar zijn voor een beperkt, gedefinieerd aantal mensen. Onbevoegde overdracht en gebruik van informatie moet beperkt worden. Bijvoorbeeld, vertrouwlijkheid van informatie verzekert dat de persoonlijke en financiele informatie van een klant niet verkregen kan worden door een onbevoegd persoon voor kwaadwillige doeleinden zoals identiteit diefstal of creditkaart fraude.
- Integrity (Integriteit) — Informatie moet niet veranderd worden op een manier waardoor het incompleet of incorrect wordt. Onbevoegde gebruikers moeten beperkt worden in de mogelijkheden om gevoelige informatie te veranderen of te vernietigen.
- Availability (Beschikbaarheid) — Informatie moet toegankelijk zijn voor bevoegde gebruikers op ieder moment dat dit nodig is. Beschikbaarheid is een garantie dat informatie verkregen kan worden met een afgesproken frequentie en snelheid. Dit wordt vaak gemeten in percentages en wordt formeel afgesproken in Service Level Agreements (SLAs) (Service Niveau Overeenkomsten) gebruikt door netwerk dienst aanbieders en hun zakelijke klanten.
1.1.2. SELinux
Fedora bevat een uitbreiding van de Linux kernel, SELinux genaamd, welke een Mandatory Access Control (MAC) (Verplichte Toegangs Controle) architectuur implementeert die een fijn-korrelig niveau van controle over bestanden, processen, gebruikers, en toepassingen in het systeem biedt.
1.1.3. Beveiligings controles
computer beveiliging wordt vaak verdeeld in drie aparte hoofdgroepen, gewoonlijk aangegeven als controles:
- Fysiek
- Technisch
- Administratief
Deze drie brede categorieën definieren de belangrijkste doelen van een juiste beveiligings implementatie. Binnen deze controles zijn sub-categorieën die de controles verder detaileren en de implementatie aangeven.
1.1.3.1. Fysieke controles
Fysieke controles is de implementatie van beveiligings maatregelen in een gedefinieerde structuur voor het afschrikken of verhinderen van onbevoegde toegang tot gevoelig materiaal. Voorbeelden van fysieke controles zijn:
- Gesloten-circuit bewakings camera's
- Beweigings of thermische alarm systemen
- Bewakers
- Badges met foto
- Afgesloten en vergrendelde stalen deuren
- Biometriek (zoals vingerafdrukken, stem, gezichts, iris, handschrift, en andere automatische methoden gebruikt om individuen te herkennen)
1.1.3.2. Technische controles
Technische controles gebruiken technologie als basis voor het controleren van de toegang tot en het gebruik van gevoelige data door een fysieke structuur en via een netwerk. Technische controles reiken ver en bevatten technologiën als:
- Versleuteling
- Smart cards
- Netwerk authenticatie
- Toegangs controle lijsten (ACL's)
- Bestandsintegriteit onderzoek software
1.1.3.3. Administratieve controles
Administratieve controles definieren de menselijke factoren van beveiliging. Ze omvatten alle niveau's van personeel binnen een organisatie en bepalen welke gebruikers toegang hebben tot welke hulpbronnen en informatie met behulp van middelen als:
- Onderwijs en bewustzijn
- Voorbereid zijn op ongevallen en herstel plannen
- Personeel aanwerven en scheiden strategieën
- Personeelsregistratie en verantwoording
1.1.4. Conclusie
Nu je iets hebt geleerd over de oorsprong, redenen, en aspecten van beveiliging, zul je het gemakkelijker vinden om de juiste actie koers te bepalen met betrekking tot Fedora. Het is belangrijk om te weten welke factoren en condities beveiliging bepalen om een juiste strategie te bedenken en te implementeren. Met deze informatie in gedachte, kan het proces geformaliseerd worden en wordt het pad duidelijker als je dieper in de specifieke aspecten van het beveiligings proces duikt.
1.2. Kwetsbaarheid beoordeling
Met voldoende tijd, hulpbronnen, en motivatie, kan een cracker in bijna elk systeem inbreken. Uiteindelijk kunnen alle beveiligings procedures en technologien die nu beschikbaar zijn, niet garanderen dat elk systeem volledig beveiligd is tegen indringing. Routers helpen de gateways naar het Internet te beveiligen. Firewalls helpen om de randen van het netwerk te beveiligen. Virtual Private Networks geven data veilig door met een versleutelde stroom. Indringings detectie systemen waarschuwen je voor kwaadwillige activiteiten. Het succes van al deze technologien hangt echter af van een aantal variabelen, zoals:
- De deskundigheid van de werknemers die verantwoordlijk zijn voor het instellen, bewaken, en onderhouden van de technologien.
- De mogelijkheid om services en kernels snel en efficient te corrigeren en te vernieuwen.
- De mogelijkheid van de verantwoordelijken om constant waakzaam te zijn over het netwerk.
Door de dynamische toestand van data systemen en technologien, kan het beveiligen van zakelijke hulpbronnen behoorlijk ingewikkeld zijn. Door deze complexiteit is het vaak moeilijk om deskundigen te vinden voor al je systemen. Terwijl het mogelijk is om personeel te hebben die kennis heeft van vele gebieden van informatie beveiliging, is het moeilijk personeel vast te houden die deskundig is in meer dan een paar onderwerpsgebieden. Dit komt voornamelijk door de vereiste van constante aandacht en scherpte voor ieder onderwerpsgebied van informatie beveiliging. Informatie beveiliging staat niet stil.
1.2.1. Denk als de vijand
Veronderstel dat je een zakelijk netwerk beheert. Zo'n netwerk bestaat gewoonlijk uit operating systemen, toepassingen, servers, netwerk bewaking, firewalls, indringings detectie systemen, en meer. Stel je nu voor om te proberen voor ieder van deze actueel te blijven. Gegeven de complexiteit van de huidige software en netwerk omgevingen, zijn uitbuitingen en bugs een zekerheid. Actueel te blijven met correcties en vernieuwingen voor een geheel netwerk zal een intimiderende taak blijken te zijn in een grote organisatie met heterogene systemen.
Combineer de kennis vereisten met de taak om actueel te blijven, en het is duidelijk dat vijandige incidenten zullen optreden, dat systemen verstoord worden, data corrupt raakt, en service onderbroken wordt.
Om de beveiligings technologien te ondersteunen en te helpen met het beschermen van systemen, netwerken, en data, moet je denken als een cracker en de beveiliging van je systemen meten door het zoeken naar zwaktes. Preventief kwestbaarheids onderzoek van je eigen systemen en netwerk hulpbronnen kan potentiele problemen laten zien voordat een cracker deze uit kan buiten.
Een kwetsbaarheidsonderzoek is een intern onderzoek van je netwerk en systeem beveiliging; waarvan de resultaten de vertrouwelijkheid, integriteit, en beschikbaarheid van je systeem aangeven (zoals uitgelegd in Paragraaf 1.1.1.3, “Het standaardiseren van beveiliging”). Gewoonlijk begint een kwetsbaarheidsonderzoek met een verkennings fase, waarin belangrijke gegevens over de doel systemen en hulpbronnen worden verzameld. Deze fase leidt naar de systeem gereedheids fase, waarin het doel voornamelijk bekeken wordt voor alle bekende kwetsbaarheden. De gereedheids fase bereikt zijn hoogtepunt in de rapporteer fase, waarin de bevindingen ingedeeld worden in categorien van hoge, gemiddelde, en lage risico's; en methodes voor het verbeteren van de beveiliging (of het verlichten van het risico van kwetsbaarheid) van het doel worden besproken.
Als je een kwetsbaarheidsonderzoek van je huis zou uitvoeren, zal je waarschijnlijk willen controleren of elke deur naar je huis dicht en afgesloten is. Je zult ook elk venster controleren om er zeker van te zijn dat deze geheel dicht zijn en correct afgesloten. Dit zelfde concept is van toepassing op systemen, netwerken, en electronische data. Kwaadwillige gebruikers zijn de dieven en vandalen van je data. Richt je op hun gereedschappen, mentaliteit, en motivatie, en je kunt dan snel reageren op hun acties.
1.2.2. Het definieren van onderzoeken en testen
Kwetbaarheidsonderzoeken kunnen verdeeld worden in twee types:van buiten naar binnen kijken en van binnen rondkijken.
Als je een van buiten naar binnen kijken kwetsbaarheidsonderzoek uitvoert, probeer je om je systeem van buiten af in gevaar te brengen. Als je buiten je bedrijf bent geeft je dat het gezichtspunt van de cracker. Je ziet wat een cracker ziet — openlijke IP adressen, systemen op je DMZ, externe interfaces van je firewall, enzovoort. DMZ staat voor "demilitarized zone", wat overeenkomt met een computer of een klein subnetwerk dat zich bevindt tussen een vertrouwd intern netwerk, zoals een prive LAN van een bedrijf, en een onvertrouwd extern netwerk, zoals het publieke Internet. Gewoonlijk bevat de DMZ apparaten met toegang tot Internet verkeer, zoals Web (HTTP) servers, FTP servers, SMTP (email) servers, en DNS servers.
Als je een van binnen rondkijken kwetsbaarheidsonderzoek uitvoert, heb je het voordeel dat je intern bent en je status is verhoogd naar vertrouwd. Dit is het gezichtspunt dat jij en je collega's hebben zodra je ingelogd bent op je systeem. Je ziet printservers, bestandsservers, databases en andere hulpbronnen.
Er is een opvallend verschil tussen de twee types van kwetsbaarheidsonderzoeken. Als je intern bij je bedrijf bent heb je meer rechten dan een buitenstaander. Vandaag de dag wordt beveiliging in de meeste organisaties nog steeds ingesteld om indringers buiten te houden. Erg weinig wordt gedaan om het binnenste van de organisatie te beveiligen (zoals afdelingsfirewalls, toegangscontrole op gebruikers niveau, authenticatie procedures voor interne hulpbronnen, enzovoort). Gewoonlijk zijn er veel meer hulpbronnen als je binnen rondkijkt omdat de meeste systemen intern het bedrijf zijn. Zodra je jezelf buiten het bedrijf plaatst, krijg je onmiddelijk een onvertrouwde status. De systemen en hulpbronnen die voor je beschikbaar zijn als je extern bent is gewoonlijk erg beperkt.
Overweeg het verschil tussen kwetsbaarheidsonderzoek en indringings testen. Beschouw een kwetsbaarheidsonderzoek als de eerste stap van een indringingstest. De informatie verkregen van het onderzoek wordt gebruikt voor het testen. Terwijl het onderzoek wordt uitgevoerd om gaten en potentiele kwestbaarheden te onderzoeken, probeert de indringingstest de resultaten echt te gebruiken.
Het onderzoeken van de netwerk infrastructuur is een dynamisch proces. Beveiliging, zowel informatie als fysiek, is dynamisch. Het uitvoeren van een onderzoek geeft een overzicht die verkeerde plussen en verkeerde minnen kan opleveren.
Beveiligingsbeheerders zijn niet beter dan de gereedschappen die ze gebruiken en de kennis die ze hebben. Neem een van de op dit moment beschikbare beveiligingsgereedschappen, en het is zo goed als zeker dat er een paar verkeerde plussen zijn. Of dit komt door een programma fout of een gebruikers fout, het resultaat is hetzelfde. Het gereedschap kan kwestbaarheden vinden die in werkelijkheid niet bestaan (verkeerde plussen); of, nog erger, het gereedschap kan kwetsbaarheden niet vinden die werkelijk bestaan (verkeerde minnen).
Nu het verschil tussen een kwetsbaarheidsonderzoek en een indringingstest is gedefinieerd, nemen we de resultaten van het onderzoek en bekijken we deze zorgvuldig voordat we een indringingstest uitvoeren als onderdeel van je nieuwe beste praktijken aanpak.
Waarschuwing
Het proberen van het uitbuiten van kwetsbaarheden op productie hulpbronnen kan een averechts effect hebben op de productiviteit en efficientie van je systemen en netwerk.
De volgende lijst bekijkt een aantal voordelen van het uitvoeren van kwetsbaarheidsonderzoeken.
- Veroorzaakt een pro-active focus op informatie beveiliging
- Vindt potentiele uitbuitingen voordat crackers deze vinden
- Resulteert in systemen die bij de tijd gehouden worden en gecorrigeerd worden.
- Bevordert groei en helpt in het ontwikkelen van vaardigheden van het personeel
- Vermindert financiele verliesen en negatieve publiciteit
1.2.2.1. Het vaststellen van een methodologie
Om te helpen bij het kiezen van gereedschappen voor een kwetsbaarheidsonderzoek, is het nuttig om een kwetsbaarheidsonderzoek methodologie vast te stellen. Helaas is er op dit moment geen voor-gedefinieerde of door de industrie goedgekeurde methodologie; echter gezond verstand en beste praktijken kunnen als voldoende gids dienen.
Wat is het doel? Kijken we naar een server, of kijken we naar ons gehele netwerk en alles binnen het netwerk? Zijn we extern of intern van het bedrijf? De antwoorden op deze vragen zijn belangrijk omdat ze niet alleen helpen te bepalen welke gereerdschappen we moeten kiezen, maar ook de manier waarop ze gebruikt moeten worden.
Om meer te weten te komen over het vaststellen van een methodologie, refereer je naar de volgende websites:
- http://www.isecom.org/osstmm/ The Open Source Security Testing Methodology Manual (OSSTMM)
- http://www.owasp.org/ The Open Web Application Security Project
1.2.3. Het evalueren van de gereedschappen
Een onderzoek kan beginnen met het gebruik van een informatie verzamel gereedschap. Als het gehele netwerk onderzocht wordt, maak dan eerst een plattegrond om de host te vinden die er in draaien. Zodra die gevonden zijn, bekijk dan iedere host individueel. Concentreren op deze hosts vereist een andere set gereedschappen. Te weten welke gereedschappen gebruikt moeten worden kan de beslissende stap zijn in het vinden van kwetsbaarheden.
Net als in elk onderdeel van het dagelijkse leven, zijn er veel verschillende gereedschappen die dezelfde taak uitvoeren. Dit concept is ook van toepassing op het uitvoeren van kwetbaarheidsonderzoeken. Er zijn gereedschappen specifiek voor operating systemen, toepassingen, en zelfs netwerken (afhankelijk van het gebruikte protocol). Sommige gereedschappen zijn gratis, andere niet. Sommige gereedschappen zijn intuitief en gemakkelijk te gebruiken, terwijl andere cryptisch en slecht gedocumenteerd zijn maar met eigenschappen die andere niet hebben.
Het vinden van de juiste gereedschappen kan een intimiderende taak zijn en op het eind telt ervaring. Indien mogelijk maak je een test omgeving en probeer je zoveel gereedschappen als je kunt, en je noteert van elk de sterktes en zwaktes. Bekijk het README bestand of de manual pagina voor het gereedschap. Kijk bovendien op het Internet voor meer informatie, zoals artikelen, stap-voor-stap gidsen, en zelfs mailing lijsten specifiek voor een gereedschap.
De hier beneden besproken gereedschappen is slechts een klein aantal van de beschikbare gereedschappen.
1.2.3.1. Hosts scannen met Nmap
Nmap is een populair gereedschap dat onderdeel is van Fedora en gebruikt kan worden voor het bepalen van de opbouw van een netwerk. Nmap is al vele jaren beschikbaar en is waarschijnlijk het meest gebruikte gereedschap voor het verzamelen van informatie. Een uitstekende manual pagina is toegevoegd die een gedetaileerde beschrijving van zijn opties en gebruik geeft. Beheerders kunnen Nmap in een netwerk gebruiken om de host systemen te vinden en open poorten op die systemen.
Nmap is een goede eerste stap in een kwetsbaarheidsonderzoek. Je kunt alle hosts in je netwerk in kaart brengen en zelfs een optie meegeven dat Nmap de mogelijkheid geeft om het operatings systeem te bepalen wat op een bepaalde host draait. Nmap is een goede ondergrond voor het vaststellen van een tactiek voor het gebruiken van beveiligde services en het stoppen van ongebruikte services.
1.2.3.1.1. Nmap gebruiken
Nmap kan uitgevoerd worden vanaf een shell prompt door het intypen van het
nmap commando gevolgd door de hostnaam of IP adres van de machine die bekeken moet worden.
nmap foo.example.com
Het resultaat van de scan (die enkele minuten kan duren, afhankelijk van de locatie van de host) moet op het volgende lijken:
Starting Nmap 4.68 ( http://nmap.org ) Interesting ports on foo.example.com: Not shown: 1710 filtered ports PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 70/tcp closed gopher 80/tcp open http 113/tcp closed auth
Nmap test de meest gebruikte netwerk communicatie poorten voor het luisteren naar of wachten op services. Deze kennis kan nuttig zijn voor een beheerder die onnodige of ongebruikte services wil afsluiten.
Voor meer informatie over het gebruik van Nmap rerefereer je naar de officiele Nmap pagina op:
1.2.3.2. Nessus
Nessus is een beveiligings scanner voor alle services. De plug-in architectuur van Nessus staat gebruikers toe het aan te passen voor hun systemen en netwerken. Zoals met elke scanner is Nesses niet beter dan de handtekeningen database waar het op steunt. Gelukkig wordt Nessus regelmatig vernieuwd en biedt het volledige rapportering, en real-time kwetsbaarheid zoeken. Denk er aan dat er verkeerde plussen en verkeerde minnen kunnen zijn, zelfs bij een gereedschap zo krachtig en regelmatie vernieuwd als Nessus.
Opmerking
De Nessus client en server software is onderdeel van Fedora in de repositories maar vereist een abonnement om te gebruiken. Het wordt in dit document genoemd als een referentie voor gebruikers die er interesse in hebben om deze populaire toepassing te gebruiken.
Voor meer informatie over Nessus refereer je naar de officiele web pagina op:
1.2.3.3. Nikto
Nikto een zeer goede common gateway interface (CGI) script scanner. Nikto controleert niet alleen voor CGI kwetsbaarheden maar doet dit op een ontwijkende manier zodat het ontsnapt aan indringings detectie systemen. Het heeft een grondige documentatie die je zorgvuldig moet bekijken voordat je het programma draait. Als je Web servers hebt die CGI scripts aanbieden, kan Nikto een uitstekende hulpbron zijn om de beveiliging van deze servers te controleren.
Meer informatie over Nikto kan gevonden worden op:
1.2.3.4. VLAD de scanner
VLAD is een kwetsbaarheids scanner, ontwikkelt door het RAZOR team van Bindview, Inc., welke controleert voor de SANS Top Tien lijst van algemene beveiligings problemen (SNMP problemen, bestandsdeling problemen, enz.). Hoewel het niet zo volledig is als Nessus, is VLAD de moeite van het bekijken waard.
Opmerking
VLAD is geen onderdeel van Fedora en wordt niet ondersteund. Het wordt in dit document genoemd als een referentie voor gebruikers die er interesse in hebben om deze populaire toepassing te gebruiken.
Meer informatie over VLAD kan gevonden worden op de RAZOR team website op:
1.2.3.5. Anticiperen op je toekomstige behoeftes
Afhankelijk van je doel en hulpmiddelen, zijn er veel gereedschappen beschikbaar. Er zijn gereedschappen voor draadloze netwerken, Novell netwerken, Windows systemen, Linux systemen, een nog veel meer. Een ander essentieel onderdeel van het uitvoeren van onderzoeken kan zijn het bekijken van fysieke beveiliging, personeel doorlichten, of voice/PBX netwerk beoordeling. Nieuwe concepten, zoals war walking, wat het scannen van de omtrek van de fysieke structuur van je onderneming inhoudt voor draadloze netwerk kwetsbaarheden, zijn opkomende concepten die je kunt bekijken en, indien nodig, onderdeel maken van je onderzoek. Verbeelding en blootstelling zijn de enigste beperkingen voor het plannen en uitvoeren van kwetsbaarheidsonderzoeken.
1.3. Aanvallers en kwetsbaarheden
Om een goede beveiligings strategie te plannen en te implementeren, moet je bewust zijn van een paar van de problemen die vastberaden en gemotiveerde hackers uitbuiten om systemen in gevaar te brengen. Voordat we echter in detail gaan over deze problemen, moeten we de terminologie definieren voor het identificeren van een aanvaller.
1.3.1. Een kleine geschiedenis van hackers
De huidige betekenis van de term hacker heeft een oorsprong die teruggaat naar 1960-er jaren en de Massachusetts Institute of Technology (MIT) Tech Model Railroad Club,welke treinstellen ontwierp op een grote schaal en met complexe details. Hacker was de naam die gebruikt werd voor leden van de club die een slimme truc of workaround voor een probleem ontdekten.
Sindsdien beschrijft de term hacker iedereen van computer fanaten tot begaafde programmeurs. Een gemeenschappelijke eigenschap van de meeste hackers is de bereidheid om tot in detail te ontdekken hoe computer systemen en netwerken werken met weinig of geen motivatie van buitenaf. Open source software ontwikkelaars beschouwen zichzelf en hun collega's vaak als hackers, en gebruiken het woord als teken van respect.
Gewoonlijk volgen hackers een vorm van de hacker ethiek die voorschrijft dat de zoektocht naar informatie en expertise essentieel is, en dat het delen van deze kennis met de gemeenschap een plicht is. Gedurende deze zoektocht naar kennis, genieten sommige hackers van de academische uitdaging van het omzeilen van beveiligings maatregelen in computer systemen. Daarom gebruikt de pers vaak de term hacker voor het beschrijven van mensen die ongeoorloofd toegang krijgen tot systemen en netwerken met gewetenlose, kwaadwillige, of criminele voornemens. De meer nauwkeurige term voor dit type computer hacker is cracker — een term die midden 1980-er jaren door hackers is bedacht om het verschil tussen de twee soorten aan te geven.
1.3.1.1. Grijsschalen
Binnen de gemeenschap van individuen die kwetsbaarheden in systemen en netwetwerken vinden en benutten zijn verschillende aparte groepen. Deze groepen worden vaak beschreven door de kleurschakering van de hoed die ze "dragen" als ze hun beveiligingsonderzoek uitvoeren en deze kleurschakering geeft hun bedoeling aan.
De witte hoed hacker is iemand die netwerken en systemen test om hun prestaties te onderzoeken en te bepalen hoe kwetsbaar ze zijn voor indringing. Gewoonlijk kraken witte hoed hackers hun eigen systemen of de systemen van een opdrachtgever die ze specifiek heeft aangenomen om de beveiliging te onderzoeken. Academische onderzoekers en professionele beveiligings consulenten zijn twee voorbeelden van witte hoed hackers.
Een zwarte hoed hacker komt overeen met een cracker. In het algemeen zijn crackers minder gericht op programmeren en de academische kant van het inbreken in systemen. Zij steunen vaak op beschikbare crack programma's en buiten bekende zwakheden in systemen uit om gevoelige informatie te ontdekken voor persoonlijke winst of om schade aan te richten op het doel systeem of netwerk.
De grijze hoed hacker, daarintegen, heeft in de meeste situaties de vaardigheden en bedoeling van een witte hoed hacker, maar gebruikt deze kennis soms voor minder nobele doeleinden. Een grijze hoed hacker kan beschouwd worden als een witte hoed hacker die soms een zwarte hoed draagt om zijn doel te bereiken.
Grijze hoed hackers onderschrijven gewoonlijk een andere vorm van de hackers ethiek, die zegt dat het geoorloofd is om in te breken in systemen zolang de hacker geen diefstal pleegt of vertrouwlijke gegevens schendt. Sommigen zullen echter zeggen dat het inbreken in systemen op zich al niet ethisch is.
Onafhankelijk van de bedoeling van de indringer is het belangrijk om de zwaktes te kennen die een cracker waarschijnlijk zal proberen uit te buiten. De rest van dit hoofdstuk concentreert zich op de zaken.
1.3.2. Bedreigingen voor netwerk beveiliging
Slechte praktijken tijdens het instellen van de volgende aspecten van een netwerk kunnen het risico van een aanval vergroten.
1.3.2.1. Onveilige architecturen
Een verkeerd ingesteld netwerk is de eerste ingang voor niet bevoegde gebruikers. Om een op vertrouwen gebaseerd, open locaal netwerk kwetsbaar te laten voot het in grote mate onveilige Internet is zoiets als de deur op een kier laten in een misdadige omgeving — gedurende een willekeurige tijds periode gebeurt er niets, maar uiteindelijk benut iemand de mogelijkheid.
1.3.2.1.1. Broadcast netwerken
Systeembeheerders realiseren zich vaak niet wat de belangrijkheid is van netwerk hardware in hun beveiligings schema's. Eenvoudige hardware zoals hubs en routers vertrouwen op het broadcast of niet-geschakeld principe; wat betekent dat steeds wanneer een node data over het netwerk stuurt naar een ontvangende node, de hub of router de data pakketten naar alle hosts stuurt totdat de ontvangende node de data ontvangt en verwerkt. Deze methode is de meest kwetsbare voor adres resolutie protocol (arp) of media access control (MAC) adres misleiding voor zowel indringers van buiten als ongeoorloofde gebruikers op locale hosts.
1.3.2.1.2. Gecentraliseerde servers
Een andere potentuele netwerk valkuil is het gebruik van gecentraliseerde computers. Een vaak voorkomende kosten besparing in veel bedrijven is om alle services te bundelen op een krachtige machine. Dit is handig omdat het eenvodiger te beheren is en behoorlijk goedkoper is dan een configuratie met meerdere servers. Een gecentraliseerde server introduceert echter een enkel punt van falen. Als de centrale server in gevaar is gebracht, kan het netwerk compleet nutteloos zijn of erger, vatbaar zijn voor data manipulatie of diefstal. In deze situaties wordt een centrale server een open deur die toegang toestaat tot het gehele netwerk.
1.3.3. Bedreigingen voor server beveiliging
Server beveiliging is even belangrijk als netwerk beveiliging omdat servers vaak een groot deel van de vitale informatie van een organisatie bevatten. Als een server in gevaar is gebracht, komt zijn gehele inhoud misschien beschikbaar voor de cracker die het naar goeddunken kan stelen of manipuleren. De volgende paragrafen bespreken sommige van de hoofdzaken.
1.3.3.1. Ongebruikte services en open poorten
Een volledige installatie van Fedora bevat meer dan 1000 toepassings en bibliotheek pakketten. De meeste serverbeheerders zullen er echter niet voor kiezen om ieder pakket in de distributie te installeren, maar zullen er de voorkeur aangeven om een installatie van basis pakketten uit te voeren, plus een aantal server toepassingen.
Het komt onder systeembeheerders vaak voor om het operating systeem te installeren zonder aandacht te schenken aan welke programma's er in feite geinstalleerd worden. Dit kan een probleem zijn omdat onnodige services geinstalleerd kunnen worden, ingesteld met standaard instellingen, en mogelijk aangezet. Dit veroorzaakt dat onnodige services, zoals Telnet, DHCP, of DNS, op een server of werkstation draaien zonder dat de beheerder zich dit realiseert, wat op zijn beurt kan leiden tot ongewenst verkeer naar de server, of zelfs, een potentiele weg in het systeem voor crackers. Refereer naar Paragraaf 2.2, “Server beveiliging” voor informatie over het sluiten van poorten en het uitzetten van niet gebruikte services.
1.3.3.2. Niet gecorrigeerde services
De meeste server toepassingen die onderdeel zijn van een standaard installatie zijn solide, goed geteste stukken software. Omdat ze al vele jaren in productie omgevingen gebruikt worden, is hun code grondig verbeterd en veel van de fouten zijn gevonden en gerepareerd.
Er is echter niet zo iets als perfecte software en er is altijd ruimte voor verdere verbeteringen. Bovendien is nieuwere software meestal niet zo grondig getest als je zou verwachten, om dat het pas kort in productie omgevingen aanwezig is of omdat het misschien niet zo populair is als andere server software.
Ontwikkelaars en systeembeheerders vinden vaak fouten in server toepassingen die uit te buiten zijn en publiceren de informatie op bug volgen en beveiligings gerelateerde websites zoals de Bugtraq mailing lijst (http://www.securityfocus.com) of de Computer Emergency Response Team (CERT) website (http://www.cert.org). Hoewel deze mechanismes een effectieve manier zijn om de gemeenschap te waarschuwen voor beveiligings kwetsbaarheden, is het de taak van de systeembeheerders om hun systeem snel te corrigeren. Dit is in het bijzonder van belang omdat crackers toegang hebben tot dezelfde kwetsbaarheids volg systemen en zij zullen de informatie gebruiken om niet gecorrigeerde systemen te kraken wanneer ze dat kunnen. Goed systeembeheer vereist oplettendheid, constant bugs volgen, en juiste systeem onderhoud om een veiliger computer omgeving te waarborgen.
Refereer naar Paragraaf 1.5, “Beveiligings vernieuwingen” voor meer informatie over het bij de tijd houden van een systeem.
1.3.3.3. Onoplettend beheer
Beheerders die nalaten hun systemen te corrigeren zijn een van de grootste bedreigingen van server beveiliging. Volgens het SysAdmin, Audit, Network, Security Institute (SANS), is de belangrijkste oorzaak van computer beveiligings kwetsbaarheid "het aanstellen van niet getrainde mensen voor het onderhouden van beveiliging en het niet aanbieden van training noch de tijd om het mogelijk te maken de taak uit te voeren."[10] Dit is zowel van toepassing op onervaren beheerders als voor overmoeige of niet gemotiveerde beheerders.
Sommige beheerders laten na hun servers en werkstations te corrigeren, terwijl anderen nalaten om de log boodschappen van de systeem kernel of het netwerk verkeer te bekijken. Een andere veel voorkomende fout is het onveranderd laten van standaard wachtwoorden of sleutels voor services. Bijvoorbeeld, sommige databases hebben standaard beheerswachtwoorden omdat de database ontwikkelaars aannemen dat de systeembeheerder deze wachtwoorden onmiddelijk na de installatie zal veranderen. Als een database beheerder nalaat om dit wachtwoord te veranderen, kan zelfs een onervaren cracker het algemeen bekende standaard wachtwoord gebruiken om beheersrechten te krijgen voor de database. Dit zijn slechts een paar voorbeelden van het veroorzaken van in gevaar gebrachte servers door onoplettend beheer.
1.3.3.4. Inherent onveilige services
Zelfs de meest waakzame organisatie kan het slachtoffer worden van kwestbaarheden als de netwerk services die ze kiezen inherent onveilig zijn. Bijvoorbeeld, er zijn veel services ontwikkeld met de aanname dat ze gebruikt worden in betrouwbare netwerken; deze aanname vervalt echter zodra de service beschikbaar komt via het Internet — welke zelf inherent onbetrouwbaar is.
Een categorie van onveilige netwerk sevices zijn degene die niet-versleutelde gebruikersnamen en wachtwoorden vereisen voor authenticatie. Telnet en FTP zijn zulke services. Als pakketsnuffel software het verkeer tussen de gebruiker op afstand en zo'n service volgt, kunnen gebruikersnamen en wachtwoorden eenvoudig onderschept worden.
Zulke services kunnen inherent ook gemakkelijker prooi worden voor wat de beveiligings industrie een de-man-in-het-midden aanval noemt. In dit type aanval leidt een cracker het netwerkverkeer om door het misleiden van een gekraakte naamserver op het netwerk om naar zijn machine te wijzen in plaats van de bedoelde server. Zodra iemand een sessie op afstand opent naar de server, gedraagt de machine van de aanvaller zich als een onzichtbaar kanaal en zit rustig tussen de service op afstand en de argeloze gebruiker informatie te verzamelen. Op deze manier kan een cracker beheerswachtwoorden en ruwe data verzamelen zonder dat de server of de gebruiker dit realiseert.
Een andere categorie van niet veilige services zijn netwerk bestandssystemen en informatie services zoals NFS of NIS, die expliciet ontwikkeld zijn voor LAN gebruik, maar helaas zijn uitgebreid om WAN's te omvatten (voor gebruikers op afstand). NFS heeft standaard geen authenticatie of beveiligings mechanismes ingesteld om te voorkomen dat een cracker het NFS deel aankoppelt en alles kan bereiken wat zich daar bevindt. NIS heeft ook vitale informatie die aan iedere computer op het netwerk bekend moet zijn, zoals wachtwoorden en bestandsrechten, dit in een leesbare tekst ASCII of DBM (van ASCII afgeleid) database. Een cracker die toegang krijgt tot deze database heeft dan toegang tot elk gebruikersaccount op een netwerk, inclusief het account van de beheerder.
Standaard wordt Fedora vrijgegeven met al deze services uitgezet. Echter, omdat beheerders vaak gedwongen worden om deze services te gebruiken, is een voorzichtige instelling kritisch. Refereer naar Paragraaf 2.2, “Server beveiliging” voor meer informatie over het instellen van services op een veilige manier.
1.3.4. Bedreigingen voor werkstations en beveiliging van thuis PC's
Werkstations en thuis PC's zijn misschien niet even vatbaar voor een aanval als netwerken of servers, maar omdat ze vaak gevoelige data bevatten, zoals credit kaart informatie, zijn ze het doelwit van systeem crackers. Werkstations kunnen ook besmet zijn zonder dat de gebruiker dat weet en gebruikt door aanvallers als een "slaaf" macine in gecoördineerde aanvallen. Als gebruikers daarom de kwetsbaarheden van een werkstation kennen, kunnen ze zich de moeite besparen om het operating systeem opnieuw te moeten installeren, of erger, te moeten herstellen van data diefstal.
1.3.4.1. Slechte wachtwoorden
Slechte wachtwoorden is een van de eenvoudigste manieren om toegang te krijgen tot een systeem. Voor meer informatie over het vermijden van valkuilen bij het aanmaken van een wachtwoord, refereer je naar Paragraaf 2.1.3, “Wachtwoord beveiliging”.
1.3.4.2. Kwetsbare client toepassingen
Als een beheerder een volledig veilige en gecorrigeerde server heeft, betekent dat niet dat gebruikers op afstand veilig zijn wanneer ze er toegang naar krijgen. Bijvoorbeeld, als de server Telnet of FTP services aanbiedt over een publiek netwerk, kan een aanvaller de leesbare tekst gebruikersnamen en wachtwoorden bemachtigen als ze passeren over het netwerk, en daarna de account informatie gebruiken voor toegang naar het werkstation van de gebruiker op afstand.
Zelfs als veilige protocols gebruikt worden, zoals SSH, kan een gebruiker op afstand kwetsbaar zijn voor bepaalde aanvallen als ze hun client toepassingen niet vernieuwen. Bijvoorbeeld, v.1 SSH clienten zijn kwetsbaar voor een X-doorsturen aanval van kwaadwillige SSH servers. Zodra er verbonden is met de server, kan de aanvaller op zijn gemak alle toetsaanslagen en muisklikken die de gebruiker maakt onderscheppen over het netwerk. Dit probleen is gerepareerd in het v.2 SSH protocol, maar het is de taak van de gebruiker om bij te houden welke toepassingen zulke kwetsbaarheden hebben en ze te vernieuwen zoals vereist.
Paragraaf 2.1, “Werkstation beveiliging” bespreekt in meer detail welke stappen beheerders en thuisgebruikers moeten nemen om de kwetsbaarheid van hun computer werkstations te beperken.
1.4. Veel voorkomende uitbuitingen en aanvallen
Tabel 1.1, “Veel voorkomende uitbuitingen” geeft details van de meest voorkomende uitbuitingen en ingangspunten gebruikt door indringers om toegang te krijgen tot hulpbronnen in het netwerk van een organisatie. De sleutel voor deze veel voorkomende uitbuitingen is de uitleg hoe ze uitgevoerd worden en hoe beheerders hun netwerk kunnen behoeden voor zulke aanvallen.
| Uitbuiting | Beschrijving | Opmerkingen | |||
|---|---|---|---|---|---|
| Lege of standaard wachtwoorden | Het leeg laten van een beheerderswachtwoord of het gebruiken van een standaard wachtwoord ingesteld door de leverancier. Dit is vaak heel gebruikelijk in hardware zoals routers en firewalls, hoewel sommige services die op Linux draaien een standaard beheerderswachtwoord kunnen bevatten (deze bevinden zich niet in Fedora 11). |
| |||
| Standaard gedeelde sleutels | Beveiligde services bevatten soms standaard beveiligingssleutels voor ontwikkelings of evaluatie test doeleinden. Als deze sleutels onveranderd blijven en ze worden in een productie omgeving op het Internet geplaatst, hebben alle gebruikers met dezelfde standaard sleutels toegang tot die gedeelde sleutel hulpbron, en alle gevoelige informatie die het bevat. |
| |||
| IP adres voor de gek houden (spoofing) | Een machine op afstand doet zich voor als een node in jouw locale netwerk, vindt kwetsbaarheden van je servers, en installeert een achterdeur programma of een paard van Troje om controle te krijgen over je netwerk hulpbronnen. |
| |||
| Afluisteren | Het verzamelen van data dat tussen twee actieve nodes op een netwerk uitgewisseld wordt door het afluisteren van de verbinding tussen de twee nodes. |
| |||
| Service kwetsbaarheden | Een aanvaller vindt een zwakte of kijkgat in een service die op het Internet draait; met deze kwetsbaarheid compromitteert de aanvaller het gehele systeem en alle data die het bevat, en kan mogelijk andere systemen in het netwerk in gevaar brengen. |
| |||
| Toepassings kwetsbaarheden | Aanvallers vinden fouten in bureaublad en werkstation toepassingen (zoals email clienten) en voeren willekeurige code uit, brengen paarden van Troje aan voor toekomstig in gevaar brengen, of laten systemen chrashen. Verdere uitbuiting kan plaatsvinden als het in gevaar gebrachte werkstation beheersrechten heeft op de rest van het netwerk. |
| |||
| Service weigerings (Denial of service - DoS) aanvallen | Een aanvaller of een groep van aanvallers coördineren tegen het netwerk of de server hulpbronen van een organisatie door het ongevraagd sturen van pakketten naar de doel host (of server, router, of werkstation). Dit veroorzaakt dat de hulpbronnen niet beschikbaar zijn voor rechtmatige gebruikers. |
|
Tabel 1.1. Veel voorkomende uitbuitingen
1.5. Beveiligings vernieuwingen
Als beveiligings kwetsbaarheden ontdekt worden, moet de betreffende software vernieuwd worden om elk potentieel beveiligings risico te beperken. Als de software onderdeel is van een pakket in de Fedora distributie die op dat moment ondersteund wordt, heeft Fedora zich verplicht om zo spoedig mogelijk vernieuwde pakketten vrij te geven die de kwetsbaarheid repareren. Vaak gaan aankondigingen van een bepaalde beveiligings uitbuiting gepaard met een correctie (of bron code die het probleen repareert). Deze correctie wordt dan toegepast in het Fedora pakket, getest, en vrijgegeven als een errata vernieuwing. Als de aankondiging echter geen correctie bevat, werkt een ontwikkelaar eerst samen met de onderhouder van de software om het probleem op te lossen. Zodra het probleem opgelost is, wordt het pakket getest en vrijgegeven als een errata vernieuwing.
Als een errata vernieuwing wordt vrijgegeven voor software die op je systeem gebruikt wordt, wordt het ten sterkste aanbevolen dat je de betreffende pakketten zo spoeding mogelijk vernieuwt om de tijdsduur dat je systeem potentieel kwetsbaar is te minimaliseren.
1.5.1. Pakketten vernieuwen
Als je pakketten op een systeem vernieuwt, is het belangrijk om de vernieuwing te dowloaden van een vertrouwde bron. Een aanvaller kan een pakket eenvoudig opnieuw bouwen met hetzelfde versie nummer als het pakket dat verondersteld wordt om het probleem op te lossen, maar met een andere beveiligings uitbuiting en dit vrijgeven op het Internet. Als dit gebeurt, wordt de uitbuiting niet ontdekt met veiligheids maatregelen zoals het vergelijken van bestanden met de originele RPM. Het is dus erg belangrijk om RPM's alleen te downloaden van vertrouwde bronnen, zoals van Fedora, en de ondertekening van het pakket te controleren op zijn integriteit.
Opmerking
Fedora bevat een handig paneel icoon dat zichtbare waarschuwingen laat zien als er een vernieuwing is voor een Fedora systeem.
1.5.2. Ondertekende pakketten verifiëren
Alle Fedora pakketten zijn ondertekend met de Fedora GPG sleutel. GPG staat voor GNU Privacy Guard, of GnuPG, een vrij software pakket voor het verzekeren van authenticiteit van verspreide bestanden. Bijvoorbeeld, een privé sleutel (geheime sleutel) sluit het pakket af terwijl een publieke sleutel het pakket opent en verifieert. Als de publieke sleutel die door Fedora geleverd wordt tijdends de RPM verificatie niet past met de geheime sleutel, kan het pakket veranderd zijn en kan daarom niet vertrouwd worden.
Het RPM programma in Fedora probeert automatisch de GPG ondertekening van een RPM pakket te verifiëren voordat het geinstalleerd wordt. Als de Fedora GPG sleutel niet geinstalleerd is, doe dat dan van een veilige, statische locatie, zoals een Fedora installatie CD-ROM of DVD.
Aannemende dat de schijf zich bevindt in
/mnt/cdrom, gebruik je het volgende commando om het te importeren in de sleutelring (een databse van vertrouwde sleutels op het systeem):
rpm --import /mnt/cdrom/RPM-GPG-KEY
Om een lijst te laten zien van alle sleutels die geinstalleerd zijn voor RPM verificatie, voer je het volgende commando uit:
rpm -qa gpg-pubkey*
De output zal op het volgende lijken:
gpg-pubkey-db42a60e-37ea5438
Om details van een specifieke sluetel te laten zien, voer je het
rpm -qi commando uit gevolgd door de output van het vorige commando, zoals in dit voorbeeld:
rpm -qi gpg-pubkey-db42a60e-37ea5438
Het is uiterst belangrijk dat je de ondertekening van de RPM bestanden verifieert voor het installeren om er zeker van te zijn dat ze niet veranderd zijn ten opzichte van de originele bron van de pakketten. Om alle gedownloade pakketten tegelijk te verifiëren voer je het volgende commando uit:
rpm -K /tmp/updates/*.rpm
Het commando geeft voor ieder pakket
gpg OK terug als de GPG sleutel met succes geverifieerd is. Als dat niet het geval is, wees er dan zeker van dat je de juiste Fedora publieke sleutel gebruikt en controleer ook de bron van de inhoud. Pakketten die niet voldoen aan de GPG verificatie moeten niet geinstalleerd worden, omdat ze door derden veranderd kunnen zijn.
Na het verifiëren van de GPG sleutel en het downloaden van alle pakketten die behoren bij het errata rapport, installeer je de pakketten als root op een shell prompt.
1.5.3. Ondertekende pakketten installeren
Het installeren van de meeste pakketten kan veilig gedaan worden (behalve voor kernel pakketten) met het volgende commando:
rpm -Uvh /tmp/updates/*.rpm
Voor kernel pakketten gebruik je het volgende commando:
rpm -ivh /tmp/updates/<kernel-pakket>
Vervang
<kernel-pakket> in het vorige voorbeeld met de naam van de kernel RPM.
Zodra de machine veilig opnieuw opgestart is met de nieuwe kernel, kan de oude kernel verwijderd worden met het volgende commando:
rpm -e <oude-kernel-pakket>
Vervang
<oude-kernel-pakket> in het vorige voorbeeld met de naam van de oude kernel RPM.
Opmerking
Het is niet vereist dat de oude kernel verwijderd wordt. De standaard boot loader, GRUB, staat toe dat meerdere kernels geinstalleerd worden, waarna een gekozen kan worden in een menu tijdens het opstarten.
Belangrijk
Voordat je een beveiligings errata installeert, wees er dan zeker van om de speciale instructies te lezen die zich bevinden in het errata rapport en voer deze dan uit. Refereer naar Paragraaf 1.5.4, “De veranderingen toepassen” voor algemene instructies over het toepassen van de veranderingen gemaakt door een errata vernieuwing.
1.5.4. De veranderingen toepassen
Na het downloaden en installeren van beveiligings errata en vernieuwingen, is het belangrijk om het gebruik van de oudere software te stoppen en te beginnen met het gebruiken van de nieuwe software. Hoe dit gedaan wordt hangt af van het type software dat vernieuwd is. De volgende lijst somt de algemene categoriën van software op en geeft instructies voor het gebruik van de vernieuwde versies na een pakket vernieuwing.
Opmerking
In het algemeen is het systeem opnieuw opstarten de veiligste manier om te verzekeren dat de laatste versie van een software pakket wordt gebruikt; deze optie is echter niet altijd vereist, of beschikbaar voor de systeembeheerder.
- Toepassingen
- Gebruikers-ruimte toepassingen zijn alle programma's die opgestart worden door een systeem gebruiker. Gewoonlijk worden deze toepassingen alleen gebruikt als een gebruiker, een script, of een automatische taak programma ze opstart en ze blijven niet voortduren voor lange tijdsperiodes.Zodra zo'n gebruikers-ruimte toepassing vernieuwd is, stop je alle instances van de toepassing op het systeem en je start het programma opnieuw op om de vernieuwde versie te gebruiken.
- Kernel
- De kernel is het kern software onderdeel van het Fedora operating systeem. Het beheert toegang tot het geheugen, de processor, en randapparaten en het plant alle taken.Door zijn centrale rol, kan de kernel niet opnieuw gestart worden zonder ook de computer te stoppen. Daarom kan een vernieuwde versie van de kernel pas gebruikt worden als het systeem opnieuw opgestart wordt.
- Gedeelde bibliotheken
- Gedeelde bibliotheken zijn stukken code, zoals
glibc, welke gebruikt worden door een aantal toepassingen en services. Toepassingen die een gedeelde bibliotheek gebruiken laden de gedeelde code als de toepassing opgestart wordt, dus alle toepassingen die de vernieuwde bibliotheek gebruiken moeten gestopt en opnieuw opgestart worden.Om te bepalen welke draaiende toepassingen verbonden zijn met een bepaalde bibliotheek, gebruik je hetlsofcommando zoals in het volgende voorbeeld:lsof /lib/libwrap.so*Dit commando geeft een lijst terug van alle draaiende programma's die TCP wrappers gebruiken voor host toegangscontrole. Daarom moet elk programma in de lijst gestopt en opnieuw opgestart worden als hettcp_wrapperspakket vernieuwd wordt. - SysV services
- SysV services zijn blijvende server programma's die opgestart worden tijdens het boot proces. Voorbeelden van SysV services zijn
sshd,vsftpd, enxinetd.Omdat deze programma's gewoonlijk blijvend in het geheugen zijn zolang de computer aanstaat, moet iedere vernieuwde SysV service gestopt en opnieuw opgestart worden nadat het pakket is vernieuwd. Dit kan gedaan worden met het Service Configuratie gereedschap of door in te loggen in een root shell prompt en het/sbin/servicecommando uit te voeren zoals in het volgende voorbeeld:/sbin/service<service-naam>restartIn het vorige voorbeeld vervang je<service-naam>met de naam van de service, zoalssshd. xinetdservices- Services die gecontroleerd worden door de
xinetdsuper service draaien alleen als er een actieve verbinding is. Voorbeelden van services die gecontroleerd worden doorxinetdzijn Telnet, IMAP, en POP3.Omdat nieuwe instances van deze services opgestart worden doorxinetdiedere keer als een nieuw verzoek wordt ontvangen, worden verbindingen die optreden na de vernieuwing afgehandeld door de vernieuwde software. Als er echter active verbindingen zijn op het moment dat de doorxinetdgecontroleerde service vernieuwd wordt, blijven die werken met de oude versie van de software.Om oudere instances van een bepaalde service die doorxinetdgecontroleerd wordt te stoppen, vernieuw je het pakket voor de service en daarna stop je alle processen die op dat moment draaien. Om te bepalen of het proces draait gebruik je hetpscommando en je gebruikt daarna hetkillofkillallcommando om de huidige instances van de service te stoppen.Bijvoorbeeld, als een beveiligings errata voor deimappakketten wordt vrijgegeven, vernieuw je de pakketten, en daarna type je het volgende commando in als root in een shell prompt:ps -aux | grep imapDit commando geeft alle actieve IMAP sessies terug. Individuele sessies kunnen dan gestopt worden met het volgende commando:kill<PID>Als hiermee het stoppen mislukt, gebruik je het volgende commando:kill -9<PID>In de vorige voorbeelden vervang je<PID>met het proces identificatie nummer (dat je vindt in de tweede kolom van de output van hetpscommando) voor een IMAP sessie.Om alle actieve IMAP sessies te stoppen, voer je het volgende commando uit:killall imapd
[1] http://law.jrank.org/pages/3791/Kevin-Mitnick-Case-1999.html
[2] http://www.livinginternet.com/i/ia_hackers_levin.htm
[3] http://www.theregister.co.uk/2007/05/04/txj_nonfeasance/
[4] http://www.healthcareitnews.com/story.cms?id=9408
[5] http://www.internetworldstats.com/stats.htm
[6] http://www.cert.org
[7] http://www.cert.org/stats/fullstats.html
[8] http://www.newsfactor.com/perl/story/16407.html
[9] http://www.csoonline.com/article/454939/The_Global_State_of_Information_Security_
[10] http://www.sans.org/resources/errors.php
Hoofdstuk 2. Je netwerk beveiligen
- 2.1. Werkstation beveiliging
- 2.2. Server beveiliging
- 2.3. Eenmalig inschrijven (Single sign-on - SSO)
- 2.4. Pluggable Authentication Modules (PAM)
- 2.5. TCP wrappers en xinetd
- 2.6. Kerberos
- 2.6.1. Wat is Kerberos?
- 2.6.2. Kerberos terminologie
- 2.6.3. Hoe werkt Kerberos
- 2.6.4. Kerberos en PAM
- 2.6.5. Het instellen van een Kerberos 5 server
- 2.6.6. Het instellen van een Kerberos 5 client
- 2.6.7. Domein naar gebied afbeelding
- 2.6.8. Instellen van secundaire KDC's
- 2.6.9. Cross gebieds authenticatie instellen
- 2.6.10. Extra hulpbronnen
- 2.7. Virtuele privé netwerken (VPN's)
- 2.8. Firewalls
- 2.9. IPTables
2.1. Werkstation beveiliging
Een Linux omgeving beveiligen begint met het werkstation. Of het gaat om het vergrendelen van een persoonlijke machine of het beveiligen van een bedrijfssysteem, een gezonde beveiligingstactiek begint met de individuele computer. Een computer netwerk slechts zo veilig als zijn zwakste node.
2.1.1. Het onderzoeken van werkstation beveiliging
Als de beveiliging van een Fedora werkstation onderzocht wordt, overweeg dan het volgende:
- BIOS en boot loader beveiliging — Kan een onbevoegde gebruiker fysieke toegang tot de machine krijgen en opstarten in de enkele-gebruikers of reddings mode zonder een wachtwoord?
- Wachtwoord beveiliging — Hoe veilig zijn de gebruikersaccount wachtoorden op de machine?
- Beheerscontrole — Wie heeft een account op het systeem en hoeveel beheerscontrole hebben zij?
- Beschikbare network services — Welke services luisteren naar verzoeken van het netwerk en moeten zij wel draaien?
- Persoonlijke firewalls — Welk type firewall, indien aanwezig, is nodig?
- Beveiligings verbeter gereedschappen — Welke gereedschappen moeten gebruikt worden om te communiceren tussen de werkstations en welke moeten gemeden worden?
2.1.2. BIOS en boot loader beveiliging
Wachtwoord bescherming voor de BIOS (of het equivalent daarvan) en de boot loader kan beletten dat onbevoegde gebruikers, die fysieke toegang tot systemen hebben, opstarten met verwijderbare media of root rechten krijgen met de enkele-gebruiker mode. De beveiligingsmaatregelen die je moet nemen om te beschermen tegen zulke aanvallen hangt zowel af van de gevoeligheid van de informatie op het werkstation als de locatie van de machine.
Bijvoorbeeld, als een machine gebruikt wordt op een beurs en geen gevoelige informatie bevat, dan hoeft het niet kritisch te zijn om zulke aanvallen te voorkomen. Als echter de laptop van een werknemer met privé, niet-versleutelde SSH sleutels voor het bedrijfsnetwerk onbeheerd achter wordt gelaten op dezelfde beurs, kan dat leiden tot een belangrijke beveiligings inbreuk met gevolgen voor het gehele bedrijf.
Als het werkstation zich op een locatie bevindt waarnaar alleen bevoegde of vertrouwde mensen toegang hebben, dan hoeft echter het beveiligen van de BIOS of de boot loader niet nodig zijn.
2.1.2.1. BIOS wachtwoorden
De twee belangrijkste redenen voor wachtwoord bescherming van de BIOS van een computer zijn[11]:
- Het voorkomen van het veranderen van de BIOS instelling — Als een indringer toegang heeft tot de BIOS, dan kunnen ze deze instellen om op te starten van een CD-ROM of diskette. Dit maakt het voor hen mogelijke om op te starten in de reddings mode of de enkele-gebruikers mode, wat op zijn beurt toestaat om willekeurige processen op het systeem op te starten of om gevoelige data te copiëren.
- Systeem opstarten beletten — Sommige BIOS'en staan wachtwoord bescherming toe voor het opstart proces. Als dit aangezet is, moet de aanvaller een wachtwoord opgeven voordat de BIOS de boot loader opstart.
Om dat de methode voor het instellen van een BIOS wachtwoord afhangt van de computer fabrikant, raadpleeg je de handleiding van de computer voor specifieke instructies.
Als je het BIOS wachtwoord vergeet, kan het terug gezet worden of met jumpers op het moederbord of door het los koppelen van de CMOS batterij. Hierdoor is het een goede praktijk om de computerkast af te sluiten als dit mogelijk is. Raadpleeg echter de handleding van de computer of het moederbord voordat je probeert om de CMOS batterij los te koppelen.
2.1.2.1.1. Het beveiligen van een niet-x86 platform
Andere architecturen gebruiken andere programma's om taken op een laag niveau uit te voeren die ruwweg overeenkomen met die van de BIOS van x86 systemen. Bijvoorbeeld, Intel® Itanium™ computers gebruiken de Extensible Firmware Interface (EFI) shell.
Voor instructies over wachtwoordbescherming van BIOS-achtige programma's op andere architecturem, refereer je naar de instructies van de fabrikant.
2.1.2.2. Boot loader wachtwoorden
De belangrijkste redenen voor wachtwoordbescherming van een Linux boot loader zijn:
- Het voorkomen van toegang tot de enkele-gebruikers mode — Als aanvallers de machine kunnen opstarten in de enkele-gebruikers mode, worden ze automatisch ingelogd als root zonder dat hen het rootwachtwoord gevraagd wordt.
- Het voorkomen van toegang tot de GRUB console — Als de machine GRUB als boot loader gebruikt, kan een aanvaller de GRUB bewerker interface gebruiken om zijn instelling te veranderen of om informatie te krijgen met behulp van het
catcommando. - Het voorkomen van toegang tot onveilige operating systemen — Als het een systeem is met meerdere operating systemen, kan een aanvaller tijdens het opstarten een operating systeem kiezen (bijvoorbeeld, DOS), welke toegangscontrole en bestandsrechten negeert.
Fedora wordt geleverd met de GRUB boot loader op het x86 platform. Voor een uitgebreide beschrijving van GRUB refereer je naar de Fedora installatie gids.
2.1.2.2.1. Wachtwoordbescherming voor GRUB
Je kunt GRUB instellen om de eerste twee problemen getoond in Paragraaf 2.1.2.2, “Boot loader wachtwoorden” op te lossen door het toevoegen van een password commando in zijn configuratie bestand. Om dit te doen, kies je eerst een sterk wachtwoord, je opent een shell, je logt in als root, en dan type je het volgende commando:
/sbin/grub-md5-crypt
Als er om gevraagd wordt type je het GRUB wachtwoord in en je drukt op Enter. Dit geeft een MD5 hash van het wachtwoord terug.
Vervolgens bewerk je het GRUB configuratie bestand
/boot/grub/grub.conf. Open het bestand en onder de timeout regel in de hoofd sectie van het document, voeg je de volgende regel toe:
password --md5 <wachtwoord-hash>
De volgende keer dat het systeem opstart, voorkomt het GRUB menu toegang tot de bewerker of commando interface zonder eerst op p te duwen gevolg door het GRUB wachtwoord.
Helaas belet deze oplossing een aanvaller niet om op te starten in een onveilig operating systeem in een omgeving met meerdere operating systemen. Hiervoor moet een ander deel van het
/boot/grub/grub.conf bestand bewerkt worden.
Zoek naar de
title regel van het operating systeem dat je wilt beveiligen, en voeg een regel toe met het lock commando direct onder deze.
Voor een DOS systeem, moet de strofe beginnen overeenkomstig het volgende:
title DOS lock
Waarschuwing
Een
password regel moet aanwezig zijn in de hoofd sectie van het /boot/grub/grub.conf bestand om deze methode goed te laten werken. Anders kan een aanvaller toegang krijgen tot de GRUB bewerker interface en de lock regel verwijderen.
Om een ander wachtwoord te maken voor een bepaalde kernel of operating systeem, voeg je een
lock regel toe aan de strofe, gevolgd door een password regel.
Elke strofe die beschermd wordt met een uniek wachtwoord moet beginnen met regels die lijken op het volgende voorbeeld:
title DOS lock password --md5 <wachtwoord-hash>
2.1.3. Wachtwoord beveiliging
Wachtwoorden is de belangrijkste methode die Fedora gebruik om de identiteit van een gebruiker te controleren. Daarom is wachtwoord beveiliging zo belangrijk voor de bescherming van de gebruiker, het werkstation, en het netwerk.
Voor beveiligings doeleinden, stelt het installatie programma het systeem in om Message-Digest Algorithm (MD5) en schaduw wachtwoorden te gebruiken. Het wordt ten sterkste afgeraden om deze instellingen te veranderen.
Als MD5 wachtwoorden worden uitgezet tijdens de installatie, wordt het oudere Data Encryption Standard (DES) formaat gebruikt. Dit formaat beperkt wachtwoorden tot acht alfanumerieke karakters (leestekens en andere speciale karakters zijn uitgesloten), en biedt een bescheiden 56-bit niveau van versleuteling.
Als schaduw wachtwoorden wordt uitgezet tijdens de installatie, worden alle wachtwoorden bewaard als een one-way hash in het
/etc/passwd bestand wat leesbaar is voor iedereen, wat het systeem gevoelig maakt voor offline wachtwoordkraak aanvallen. Als een indringer toegang tot de machine kan krijgen als een gewone gebruiker, kan hij het /etc/passwd bestand naar zijn eigen machine kopiëren en daarna er een aantal wachtwoordkraak programma's op los laten. Als er een onveilig wachtwoord in het bestand is, is het slechts een kwestie van tijd voordat de wachtwoordkraker het ontdekt.
Schaduw wachtwoorden sluiten dit type aanval uit door de wachtwoord hashes te bewaren in het bestand
/etc/shadow, welke alleen leesbaar is door de root gebruiker.
Dit forceert een potentiele aanvaller om wachtwoordkraken op afstand te proberen door in te loggen op een netwerk service van de machine zoals SSH of FTP. Dit soort brute kracht aanval is veel langzamer en laat een duidelijk spoor achter omdat honderden mislukte login pogingen naar systeembestanden geschreven worden. Natuurlijk, als de cracker de aanval midden in de nacht begint op een systeem met zwakke wachtwoorden, kan de cracker toegang hebben gekregen voor de ochtend en de logbestanden bewerkt hebben om zijn sporen te verbergen.
Naast de formaat en opslagplaats overwegingen is er die over de inhoud. Het aller belangrijkste wat een gebruiker kan doen om zijn account tegen een wachtwoordkraak aanval te beschermen is het maken van een sterk wachtwoord.
2.1.3.1. Sterke wachtwoorden maken
Als je een veilig wachtwoord wilt maken, is het een goede idee om de volgende richtlijnen te volgen:
- Gebruik niet alleen woorden of getallen — Gebruik nooit alleen getallen of woorden in een wachtwoord.Een paar onveilige wachtwoorden zijn de volgende:
- 8675309
- jan
- hackmij
- Gebruik geen herkenbare woorden — Woorden zoals gewone namen, woordenboek woorden, of zelfs uitdrukkingen uit televisie shows of boeken moeten vermeden worden, zelfs als ze omgeven zijn met getallen.Een paar onveilige wachtwoorden zijn de volgende:
- john1
- DS-9
- mentat123
- Gebruik geen woorden uit vreemde talen — Wachtwoordkraak programma's raadplegen vaak woordenlijsten die woordenboeken van vele vreemde talen omvatten. Steunen op vreemde talen voor veilige wachtwoorden is niet veilig.Een paar onveilige wachtwoorden zijn de volgende:
- cheguevara
- bienvenido1
- 1dumbKopf
- Gebruik geen hacker terminologie — Als je denkt dat je bij de elite hoort omdat je hacker terminologie — ook wel l337 (LEET) spraak genoemd — in je wachtwoord gebruikt, denk dan even na. Veel woordenlijsten bevatten LEET spraak.Een paar onveilige wachtwoorden zijn de volgende:
- H4X0R
- 1337
- Gebruik geen persoonlijke informatie — Vermijdt het gebruik van enige persoonlijke informatie in je wachtwoorden. Als de aanvaller je identiteit kent, wordt de taak van het ontdekken van je wachtwoorden gemakkelijker. Het volgende is een lijst van het type informatie die je moet vermijden als je een wachtwoord maakt:Een paar onveilige wachtwoorden zijn de volgende:
- Je naam
- De namen van je huisdieren
- De namen van familieleden
- Geboorte data
- Je telefoonnummer of postcode
- Keer geen herkenbare woorden om — Goede wachtwoord checkers keren gewone woorden altijd om, dus het omkeren van een slecht wachtwoord maakt het niet veiliger.Een paar onveilige wachtwoorden zijn de volgende:
- R0X4H
- naj
- 9-DS
- Schrijf je wachtwoord niet op — Bewaar een wachtwoord nooit op papier. Het is veel veiliger om het te onthouden.
- Gebruik niet hetzelfde wachtwoord voor alle machines — Het is belangrijk om aparte wachtwoorden te maken voor iedere machine. Op deze manier zijn niet alle machines in gevaar als een systeem in gevaar is gebracht.
De volgende richtlijnen zullen je helpen om een sterk wachtwoord te maken:
- Maak het wachtwoord ten minste acht karakters lang — Hoe langer het wachtwoord is, des te beter. Als MD5 wachtwoorden gebruikt worden, moet het 15 karakters zijn of langer. Met DES wachtwoorden gebruik je de maximale lengte (acht karakters).
- Vermeng hoofd en kleine letters — Fedora is gevoelig voor hoofd en kleine letters, dus vermeng deze om de kracht van je wachtwoord te versterken.
- Vermeng letter en cijfers — Cijfers toevoegen aan wachtwoorden kunnen de wachtwoord sterkte verbeteren, zeker als ze in het midden toegevoegd worden (niet alleen aan het begin en het eind).
- Voeg niet-alfanumerieke karakters toe — Speciale karakters zoals &, $, en > kunnen de kracht van een wachtwoord sterk verbeteren (dit is niet mogelijk bij het gebruik van DES wachtwoorden).
- Neem een wachtwoord dat je kunt onthouden — Het beste wachtwoord van de wereld helpt je weinig als het niet kunt onthouden; gebruik letterwoorden of andere geheugensteuntjes om je te helpen wachtwoorden te onthouden.
Met al deze regels, kan het moeilijk lijken om een wachtwoord te maken dat aan alle criteria voor goede wachtwoorden voldoet terwijl de problemen van slechte vermeden worden. Gelukkig zijn er enkele stappen die je kunt nemen om een eenvoudig-onthoudbaar, veilig wachtwoord kunt maken.
2.1.3.1.1. Een methode om veilige wachtwoorden te maken
Er zijn vele methodes die men gebruikt om veilige wachtwoorden te maken. Een van de meer populaire methodes gebruikt letterwoorden. Bijvoorbeeld:
- Bedenk een eenvoudig te onthouden zin, zoals:"over de rivier en door de wouden, gaan we naar grootmoeder's huis "
- Vervolgens, zet je het om een in letterwoord (inclusief de leestekens).
odreddw,gwngh. - Voeg complexiteit toe door het invullen van nummers en symbolen voor letters in het letterwoord. Bijvoorbeeld, vul
7in voorden het@symbool voorw:o7re77@,g@ngh. - voeg nog meer complexiteit toe door minsters een letter te vervangen door een hoofdletter, zoals
H.o7re77@,g@ngH. - Tenslotte, gebruik nooit het voorbeeld wachtwoord hierboven voor een systeem.
Terwijl het maken van veilige wachtwoorden noodzakelijk is, is het ook belangrijk ze goed te beheren, zeker voor systeembeheerders in grotere organisaties. De volgende paragraaf beschrijft goede praktijken voor het maken en beheren van gebruikerswachtwoorden in een organisatie.
2.1.3.2. Het maken van gebruikerswachtwoorden in een organisatie
Als een organisatie een groot aantal gebruikers heeft, hebben de systeembeheerders twee basis opties beschikbaar om het gebruik van goede wachtwoorden af te dwingen. Ze kunnen wachtwoorden maken voor de gebruiker, of ze kunnen gebruikers hun eigen wachtwoord laten maken, waarbij ze controleren of de wachtwoorden van acceptabele kwaliteit zijn.
Het maken van wachtwoorden voor de gebruikers verzekert dat de wachtwoorden goed zijn, maar het wordt een ontmoedigende taak als de organisatie groeit. Het vergroot ook het risico dat gebruikers hun wachtwoord opschrijven.
Om deze reden geven de meeste beheerders er de voorkeur aan dat gebruikers hun eigen wachtwoord maken, maar ze controleren dat de wachtwoorden goed zijn en, in enkele gevallen, dwingen hun gebruikers om hun wachtwoord periodiek te veranderen door middel van wachtwoord veroudering.
2.1.3.2.1. Sterke wachtwoorden afdwingen
Om het netwerk voor indringing te beschermen is het een goed idee dat systeembeheerders controleren of de wachtwoorden die in de organisatie gebruikt worden sterk zijn. Als gebruikers gevraagd worden wachtwoorden te maken of te veranderen, kunnen ze de commandoregel toepassing
passwd gebruiken, die bewust is van Pluggable Authentication Manager (PAM) en daarom controleert of het wachtwoord te kort is of op een andere manier eenvoudig te kraken. Deze controle wordt gedaan door de pam_cracklib.so PAM module. Om dat PAM aan te passen is, is het mogelijk om meer wachtwoord integriteit checkers toe te voegen, zoals pam_passwdqc (beschikbaar op http://www.openwall.com/passwdqc/) of een nieuwe module te schrijven. Voor een lijst van beschikbare PAM modules, refereer je naar http://www.kernel.org/pub/linux/libs/pam/modules.html. Voor meer informatie over PAM, refereer je naar Paragraaf 2.4, “Pluggable Authentication Modules (PAM)”.
De wachtwoord check die uitgevoerd wordt tijdens het maken ontdekt slechte wachtwoorden niet even effectief als het draaien van een wachtwoordkraak programma voor de wachtwoorden.
Vele wachtwoordkraak programma's zijn beschikbaar die in Fedora draaien, hoewel er geen meegeleverd wordt met het operating systeem. Hieronder is een korte lijst van de bekendere wachtwoordkraak programma's:
- John The Ripper — Een snel en flexibel wachtwoordkraak programma. Het staat het gebruik van meerdere woordenlijsten toe en is in staat brute-kracht wachtwoordkraken uit te voeren. Het is beschikbaar op http://www.openwall.com/john/.
- Crack — Misschien de meest bekende wachtwoordkraak software, Crack is ook erg snel, hoewel niet even eenvoudig te gebruiken als John The Ripper. Het kan gevonden worden op http://www.crypticide.com/alecm/security/c50-faq.html.
- Slurpie — Slurpie komt overeen met John The Ripper en Crack, maar het is ontworpen om tegelijkertijd op meerdere computers te draaien, waarmee het een verspreide wachtwoordkraak aanval maakt. Het kan gevonden worden tezamen met een aantal andere verspreide aanval beveiligings evaluatie gereedschappen op http://www.ussrback.com/distributed.htm.
Waarschuwing
Zorg ervoor dat je altijd schriftelijke toestemming hebt voordat je wachtwoorden gaat kraken in een organisatie.
2.1.3.2.2. Wachtzinnen
Wachtzinnen en wachtwoorden zijn de steunpilaren voor de beveiliging voor de meeste hedendaagse systemen. Helaas zijn technieken zoals biometrie en twee-factoren authenticatie nog geen heersende stroming in veel systemen wat een groot probleem begint te worden. Als wachtwoorden gebruikt gaan worden om een systeem te beveiligen, dan is het gebruik van wachtzinnen te overwegen. Wachtzinnen zijn langer dan wachtwoorden en bieden betere bescherming dan een wachtwoord zelfs als die gemaakt wordt met niet-standaard karakters zoals getallen en symbolen.
2.1.3.2.3. Wachtwoord verloop
Wachtwoord verloop is een andere techniek die gebruikt wordt door systeembeheerders voor de verdediging tegen slechte wachtwoorden in een organisatie. Wachtwoord verloop betekent dat na een vastgestelde periode (gewoonlijk 90 dagen), de gebruiker gevraagd wordt om een nieuw wachtwoord te maken. De theorie hier achter is dat als een gebruiker gedwongen wordt om zijn wachtwoord periodiek te veranderen, een gekraakt wachtwoord slechts tijdelijk voor een indringer bruikbaar is. Het nadeel van wachtwoord verloop is dat gebruikers meer de neiging hebben om hun wachtwoord op te schrijven.
Er zijn twee belangrijke programma's voor het opgeven van wachtwoord verloop in Fedora: het
chage commando of de grafische Gebruikersbeheerder (system-config-users) toepassing.
De
-M optie van het chage commando specificeert het maximale aantal dagen dat een wachtwoord geldig is. Bijvoorbeeld, om het wachtwoord van een gebruiker in te stellen om na 90 dagen te verlopen, gebruik je het volgende commando:
chage -M 90 <gebruikersnaam>
In het bovenstaande voorbeeld, vevang je
<gebruikersnaam> met de naam van de gebruiker. Om wachtwoord verloop uit te zetten, wordt gewoonlijk een waarde van 99999 na de -M optie ingevuld (dit komt overeen met 273 jaren).
Je kunt het
chage commando ook in interactieve mode gebruiken om meerdere wachtwoord verlopen en andere account details te veranderen. Gebruik het volgende commando om in de interactieve mode te komen:
chage <gebruikersnaam>
Het volgende is een voorbeeld interactieve sessie met gebruik van dit commando:
[root@interch-dev1 ~]# chage davido Changing the aging information for davido Enter the new value, or press ENTER for the default Minimum Password Age [0]: 10 Maximum Password Age [99999]: 90 Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]: [root@interch-dev1 ~]#
Refereer naar de manual pagina voor meer informatie over de beschikbare opties.
Je kunt ook de grafische Gebruikersbeheerder toepassing gebruiken om wachtwoord verloop tactiek te maken. Merk op: je hebt beheersrechten nodig om deze procedure uit te voeren.
- Klik op het menu op het Paneel, ga naar en klik dan op om de Gebruikersbeheerder te openen. Als alternatief type je het commando
system-config-usersop de shell prompt. - Klik op de Gebruikers tab en selecteer de gewenste gebruiker in de lijst van gebruikers.
- Klik op op de gereedsschapbalk om de Gebruikerseigenschappen dialoog te openen (of kies in het menu).
- Klik op de Wachtwoordinformatie tab, en selecteer het aanvinkhokje voor Wachtwoordverloop aanzetten.
- Vul de vereiste waarde in het Dagen voordat verandering is vereist veld in, en klik op .
Wachtwoordinformatie venster afbeelding.
Figuur 2.1. Wachtwoordverloop opties opgeven
2.1.4. Administratieve controles
Als je een thuis computer beheert, moet de gebruiker sommige taken uitvoeren als de root gebruiker of door het verkrijgen van effectieve root rechten met een setuid programma, zoals
sudoof met su. Een setuid programma is een programma dat werkt met de gebruikers ID (UID) van de eigenaar van het programma in plaats van de gebruiker van het programma. Zulke programma's worden aangegeven met een s in de eigenaars sectie van een lange formaat listing, zoals in het volgende voorbeeld:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
Opmerking
De
s kan in hoofd letter of kleine letter zijn. Als het in hoofdletter verschijnt, betekent het dat de achterliggende toestemmings bit niet gezet is.
Voor de systeembeheerders van een organisatie, moet echter een keuze gemaakt worden over hoe veel beheerstoegang gebruikers binnen de organisatie moeten hebben voor hun machine. Met een PAM module genaamd
pam_console.so, worden sommige activiteiten die normaal alleen voor de root gebruiker gereserveerd zijn, zoals opnieuw opstarten en het aankoppelen van verwijderbare media, toegestaan aan de eerste gebruiker die inlogt op de fysieke console (refereer naar Paragraaf 2.4, “Pluggable Authentication Modules (PAM)” voor meer informatie over de pam_console.so module). Echter, andere belangrijke systeembeheer taken, zoals het veranderen van netwerk instellingen, een nieuwe muis configureren, of netwerkapparaten aankoppelen, zijn niet mogelijk zonder beheersrechten. Het resultaat is dat systeembeheerders moeten beslissen hoeveel toegang de gebruikers op hun netwerk moeten krijgen.
2.1.4.1. Root toegang toestaan
Als de gebruikers binnen een organisatie vertrouwd zijn en computer kennis hebben, dat kan het toestaan van root toegang aan hen geen probleem zijn. Root toegang toestaan aan gebruikers betekent dat onbelangrijke activiteiten, zoals het toevoegen van apparaten of het instellen van netwerk interfaces, door de individuele gebruikers worden afgehandeld, waardoor systeembeheerders meer tijd hebben voor netwerk beveiliging en andere belangrijke zaken.
Aan de andere kant, leidt het geven van root toegang aan individuele gebruikers tot de volgende problemen:
- Verkeerde machine instelling — Gebruikers met root toegang kunnen hun machine verkeerd instellen en vereisen hulp om het probleem op te lossen. Nog erger, ze kunnen beveiligings gaten maken zonder dat ze het weten.
- Het draaien van onveilige services — Gebruikers met root toegang kunnen onveilige servers op hun machine draaien, zoals FTP of Telnet, waarmee potentieel hun gebruikersnamen en wachtwoorden in gevaar zijn. Deze services verzenden deze informatie in leesbare tekst over het netwerk.
- Het uitvoeren van email bijlages als root — Hoewel het zelden voorkomt, zijn er email virussen die effect hebben op Linux. De enigste keer dat ze echter een gevaar zijn, is als ze als de root gebruiker draaien.
2.1.4.2. Root toegang niet toestaan
Als een beheerder het om deze of andere redenen niet fijn vindt dat gebruikers als root inloggen, moet het root wachtwoord geheim gehouden worden, en moet toegang tot runlevel 1 of enkele-gebruikers mode verboden worden met boot loader wachtwoord bescherming (refereer naar Paragraaf 2.1.2.2, “Boot loader wachtwoorden” voor meer informatie hierover).
Tabel 2.1, “Methodes voor het onmogelijk maken van het root account” beschrijft manieren waarop een beheerder kan verzekeren dat inloggen als root niet toegestaan wordt:
| Methode | Beschrijving | Effecten | Het geen gevolgen voor | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Het veranderen van de root shell |
Bewerk het /etc/passwd bestand en verander de shell van /bin/bash naar /sbin/nologin.
|
|
| |||||||||||||||
| Root toegang onmogelijk maken via elk console apparaat (tty). |
Een leeg /etc/securetty bestand voorkomt root login op elk apparaat dat aangesloten is op de computer.
|
|
| |||||||||||||||
| Root SSH login niet toestaan |
Bewerk het /etc/ssh/sshd_config bestand en zet de PermitRootLogin parameter op no.
|
|
| |||||||||||||||
| Gebruik PAM om root toegang naar services te beperken. |
Bewerk het bestand voor de doel service in de /etc/pam.d/ map. Wees er zeker van dat pam_listfile.so nodig is voor authenticatie.[a]
|
|
| |||||||||||||||
[a] Refereer naar Paragraaf 2.1.4.2.4, “Root onmogelijk maken met PAM” voor details. | ||||||||||||||||||
Tabel 2.1. Methodes voor het onmogelijk maken van het root account
2.1.4.2.1. De root shell onmogelijk maken
Om te voorkomen dat gebruikers rechtstreeks inloggen als root, kan de systeembeheerder de shell van het root account instellen als
/sbin/nologin in het /etc/passwd bestand. Dit belet toegang tot het root account met commando's die een shell nodig hebben, zoals de su en ssh commando's.
Belangrijk
Programma's die geen toegang naar de shell nodig hebben, zoals email clienten of het
sudo commando, hebben nog steeds toegang naar het shell account.
2.1.4.2.2. Als root inloggen onmogelijk maken
Om de toegang naar het root account verder te beperken, kunnen beheerders het inloggen als root op de console onmogelijk maken door het
/etc/securetty bestand te bewerken. Dit bestand bevat een lijst van alle apparaten waarop de root gebruiker in kan loggen. Als dit bestand niet bestaat, kan de root gebruiker inloggen op elk communicatie apparaat op het systeem, of dit nu een console is of een ruwe netwerk interface. Dit is gevaarlijk, omdat een gebruiker op zijn machine kan inloggen als root met Telnet, die het wachtwoord als leesbare tekst over het netwerk stuurt. Standaard staat het /etc/securetty bestand van Fedora de root gebruiker alleen toe om in te loggen op de console die fysiek aangekoppeld is aan de machine. Om te verkomen dat root inlogt, verwijder je de inhoud van dit bestand door het intypen van het volgende commando:
echo > /etc/securetty
Waarschuwing
Een leeg
/etc/securetty bestand voorkomt niett dat de root gebruiker inlogt op afstand met gebruik van de OpenSSH suite van gereedschappen omdat de console niet geopend wordt tot na de authenticatie.
2.1.4.2.3. Root SSH inloggen onmogelijk maken
Als root inloggen met het SSH protocol is standaard in Fedora uitgezet; als deze optie echter is aangezet, kan het weer uitgezet worden door het configuratie bestand van de SSH daemon (
/etc/ssh/sshd_config) te bewerken. Verander de regel die er uitziet als:
PermitRootLogin yes
naar het volgende:
PermitRootLogin no
Om deze verandering effect te laten hebben moet de SSH daemon opnieuw opgestart worden. Dit kan gedaan worden met het volgende commando:
kill -HUP `cat /var/run/sshd.pid`
2.1.4.2.4. Root onmogelijk maken met PAM
PAM biedt door de
/lib/security/pam_listfile.so module, een hoge flexibiliteit in het verbieden van specifieke accounts. De beheerder kan deze module gebruiken om te refereren naar een lijst van gebruikers die niet in mogen loggen. Hieronder is een voorbeeld van het gebruik van deze module voor de vsftpd FTP server in het /etc/pam.d/vsftpd PAM configuratie bestand (de \ karakter op het eind van de eerste regel in het volgende voorbeeld is niet nodig als het commando in een regel past):
auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Dit instrueert PAM om het
/etc/vsftpd.ftpusers bestand te raadplegen en toegang naar de service te verbieden voor elke gebruiker in de lijst. De beheerder kan de naam van dit bestand veranderen, en kan aparte lijsten voor elke service hebben of een centrale lijst gebruiken voor het verbieden van toegang naar meerdere services.
Als de beheerder toegang wil verbieden naar meerdere services, kan een soortgelijke regel toegevoegd worden aan de PAM configuratie bestanden, zoals
/etc/pam.d/pop en /etc/pam.d/imap voor mail clienten, of /etc/pam.d/ssh voor SSH clienten.
Voor meer informatie over PAM, refereer je naar Paragraaf 2.4, “Pluggable Authentication Modules (PAM)”.
2.1.4.3. Root toegang beperken
Inplaats van toegang naar de root gebruiker helemaal te verbieden, kan de beheerder alleen toegang toe willen staan met setuid programma's, zoals
su of sudo.
2.1.4.3.1. Het su commando
Als een gebruiker het
su commando uitvoert, wordt deze gevraagd naar het root wachtwoord en, na authenticatie, krijgt deze een root shell prompt.
Zodra de gebruiker is ingelogd met het
su commando, is de gebruiker de root gebruiker en heeft absolute beheerstoegang tot het systeem[13]. Bovendien ,zodra een gebruiker root wordt, is het voor hen mogelijk om het su commando te gebruiken om te veranderen naar elke andere gebruiker op het systeem zonder naar een wachtwoord gevraagd te worden.
Omdat dit commando zo krachtig is, zullen beheerders in een organisatie beperkingen willen opleggen voor wie toegang heeft tot dit commando.
Een van de eenvoudigste manieren om dit te doen is om gebruikers toe te voegen aan een speciale beheersgroep met de naam wheel. Om dit te doen, type je het volgende commando als root:
usermod -G wheel <gebruikersnaam>
In het vorige commando vervang je
<gebruikersnaam> met de gebruikersnaam die je wilt toevoegen aan de wheel groep.
Je kunt ook Gebruikersbeheerder gebruiken om een groepslidmaatschap te veranderen. Merk op: je hebt beheersrechten nodig om dit uit te voeren.
- Klik op het menu op het Paneel, ga naar en klik dan op om de Gebruikersbeheerder te openen. Als alternatief type je het commando
system-config-usersop de shell prompt. - Klik op de Gebruikers tab en selecteer de gewenste gebruiker in de lijst van gebruikers.
- Klik op op de gereedsschapbalk om de Gebruikerseigenschappen dialoog te openen (of kies in het menu).
- Klik op de Groepen tab, selecteer het aanvinkhokje voor de wheel groep, en klik dan op . Refereer naar Figuur 2.2, “Gebruikers toevoegen aan de "wheel" groep.”.
- Open het PAM configuratiebestand voor
su(/etc/pam.d/su) in een tekstbewerker en verwijder de commentaar # in de volgende regel:auth required /lib/security/$ISA/pam_wheel.so use_uid
Deze verandering betekent dat alleen leden van de beheersgroepwheeldit programma kunnen gebruiken.
Groepen veenster afbeelding
Figuur 2.2. Gebruikers toevoegen aan de "wheel" groep.
Opmerking
De root gebruiker is standaard lid van de
wheel groep.
2.1.4.3.2. Het sudo commando
Het
sudo commando biedt een andere benadering voor het geven van beheerstoegang aan gebruikers. Als vertrouwde gebruikers een beheerscommando vooraf laten gaan door sudo, worden ze naarhun eigen wachtwoord gevraagd. Als ze authentiek verklaard zijn en aangenomen dat het commando toegestaan is, wordt daarna het beheerscommando uitgevoerd alsof ze de root gebruiker zijn.
Het basis formaat van het
sudo commando is als volgt:
sudo <commando>
In het voorbeeld hierboven, moet
<commando> vervangen worden door een commando dat normaal gereserveerd is voor de root gebruiker, zoals mount.
Belangrijk
Gebruikers van het
sudo commando moeten er aan denken om uit te loggen voordat ze van hun machine weglopen, omdat gebruikers van sudo het commando opnieuw kunnen gebruiken binnen een periode van vijf minuten zonder dat er naar hun wachtwoord gevraagd wordt. Deze instelling kan veranderd worden met het configuratiebestand, /etc/sudoers.
Het
sudo commando staat een hoge mate van flexibiliteit toe. Bijvoorbreeld, alleen gebruikers die vermeld zijn in het /etc/sudoers configuratiebestand hebben het recht om het sudo commando te gebruiken en het commando wordt uitgevoerd in de shell van de gebruiker, niet in een root shell. Dit betekent dat de root shell helemaal uitgezet kan worden, zoals getoond is in Paragraaf 2.1.4.2.1, “De root shell onmogelijk maken”.
Het
sudo commando biedt ook een uitgebreid controle spoor. Elke succesvolle authenticatie wordt vastgelegd in het bestand /var/log/messages en het opgegeven commando wordt tezamen met de gebruikersnaam van de opdrachtgever weggeschreven naar het bestand /var/log/secure.
Een ander voordeel van het
sudo commando is dat een beheerder verschilende gebruikers toegang kan geven tot specifieke commando's gebaseerd op hun behoefte.
Beheerder die het
sudo configuratiebestand, /etc/sudoers, willen bewerken, moeten het visudo commando gebruiken.
Om iemand volledige beheersrechten te geven, type je
visudo in en je voegt een regel die lijkt op de volgende toe in de gebruikersrechten specificatie sectie:
jan ALL=(ALL) ALL
Dit voorbeeld zegt dat de gebruiker,
jan, sudo kan gebruiken vanaf elke host en elk commando kan uitvoeren.
Het voorbeeld hier beneden laat de fijnkorreligheid zien die mogelijk is met het instellen van
sudo:
%users localhost=/sbin/shutdown -h now
Dit voorbeeld zegt dat elek gebruiker het commando
/sbin/shutdown -h now mag opgeven zolang het opgegeven wordt vanaf de console.
De manual pagina voor
sudoers heeft een gedetaileerde lijst van opties voor dit bestand.
2.1.5. Beschikbare netwerk services
Hoewel gebruikers toegang tot beheers controle een belangrijke zaak is voor systeembeheerders in een organisatie, is het bewaken van actieve netwerk services van levensbelang voor iedereen die een Linux systeem beheert en bedient.
Veel services in Fedora gedragen zich als netwerk servers. Als een netwerk service op een machine draait, dan luistert een server toepassing (een daemon genaamd) maar verbindingen op een of meer netwerk poorten. Ieder van deze servers moet behandeld worden als een potentiele toegang voor een aanval.
2.1.5.1. Risico's voor services
Netwerk services kunnen vele risico's vormen voor Linux systemen. Hieronder staat een lijst van de hoofdzaken:
- Service weigerings aanvallen (DoS) — Door het overspoelen van een service met verzoeken, kan een service weigerings aanval een systeem onbruikbaar maken als het probeert om ieder verzoek te verwerken.
- Script kwetsbaarheids aanval — Als een server scripts gebruikt om de acties aan de server kant uit te voeren, zoals Web servers gewoonlijk doen, kan een cracker aanvallen met onjuist geschreven scripts. Deze script kwetsbaarheids aanvallen kunnen leiden tot een buffer overloop conditie en staan de aanvaller toe om bestanden op het systeem te veranderen.
- Buffer overloop aanvallen — Services die verbinden met de poorten genummerd van 0 tot en met 1023 moeten draaien als een beheersgebruiker. Als de toepassing een benutbare buffer overloop heeft, kan een aanvaller toegang krijgen tot het systeem als de gebruiker die de daemon draait. Omdat benutbare buffer overlopen bestaan, gebruiken crackers automatische gereedschappen om systemen met kwetsbaarheden te identificeren, en zodra ze toegang hebben, kunnen ze geautomatiseerde rootkits gebruiken om hun toegang naar het systeem te handhaven.
Opmerking
De dreiging van buffer overloop kwetsbaarheden wordt in Fedora verlicht door ExecShield, een uitvoerbaar geheugen segmentatie en beschermings technologie ondersteund door x86-compatibele een- en multi-processor kernels. ExecShield vermindert het risico van buffer overloop door het verdelen van virtueel geheugen in uitvoerbare en niet-uitvoerbare segmenten. Elk programma dat probeert draaien buiten een uitvoerbaar segment (zoals kwaadwillige code ingebracht met een buffer overloop uitbuiting) veroorzaakt een segmentatie fout en stopt.
ExecShield bevat ook ondersteuning voor No eXecute (NX) technologie op AMD 64 platforms en eXecute Disable (XD) technologie op Itanium en Intel® 64 systemen. Deze technologie werkt samen met ExecShield om kwaadwillige code te beletten om te draaien in het uitvoerbare deel van virtueel geheugen met een verdeling van 4KB uitvoerbare code, wat het risico van een aanval van onopgemerkte buffer overloop aanvallen verlaagd.
Belangrijk
Om de blootstelling aan aanvallen over het Internet te beperken, moeten alle ongebruikte services uitgezet worden.
2.1.5.2. Het identificeren en instellen van services
Om beveiliging te verbeteren, worden de meeste netwerk services geinstalleerd met Fedora standaard uitgezet. Er zijn echter een paar belangrijke uitzonderingen:
cupsd— De standaard printer server in Fedora.lpd— Een alternatieve print server.xinetd— Een super server die verbindingen controleert van een reeks van ondergeschikte servers, zoalsgssftpentelnet.sendmail— Het Sendmail Mail Transport Agent (MTA) is standaard aangezet, maar luitert alleen naar verbindingen van de localhost.sshd— De OpenSSH server, wat een veilige vervanging is voor Telnet.
Om te bepalen of deze services moeten blijven draaien, is het het beste om je gezonde verstand te gebruiken en voorzichtig te blijven. Bijvoorbeeld, als er geen printer beschikbaar is, laat dan
cupsd niet draaien. Hetzelfde geldt voor portmap. Als je geen NFSv3 volumes aankoppelt of NIS (de ypbind service) gebruikt, dan moet portmap uitgezet worden.
Service configuratie gereedschap afbeelding
Figuur 2.3. Service configuratie gereedschap
Als je niet zeker bent van het doel van een bepaalde service, laat het Service configuratie gereedschap een omschrijving zien met extra informatie zoals getoond in Figuur 2.3, “Service configuratie gereedschap”.
Het controleren van welke services beschikbaar zijn om te starten tijdens het opstarten van de computer is een kant van het verhaal. Je moet ook controleren welke poorten open zijn en luisteren. Refereer naar Paragraaf 2.2.8, “Het verifieren van welke poorten luisteren” voor meer informatie.
2.1.5.3. Onveilige services
Potentieel is elke netwerk service onveilig. Daarom is het uitzetten van ongebruikte services zo belangrijk. Uitbuitingen voor services worden routinematig openbaar gemaakt en gecorrigeerd, wat het erg belangrijk maakt om regelmatig pakketten te vernieuwen die behoren bij een netwerk service. Refereer naar Paragraaf 1.5, “Beveiligings vernieuwingen” voor meer informatie.
Sommige netwerk protocollen zijn inherent onveiliger dan andere. Zij omvatten alle services die:
- Gebruikersnamen en wachtwoorden onversleuteld over een netwerk versturen — Vele oudere protocollen, zoals Telnet en FTP, versleutelen de authenticatie sessie niet en moeten wanneer mogelijk vermeden worden.
- Gevoelige data onversleuteld over een netwerk versturen — Vele protocollen verzenden data onversleuteld over het netwerk. Deze protocollen omvatten Telnet, FTP, HTTP, en SMTP. Veel netwerk bestandssystemen, zoals NFS en SMB, versturen ook informatie onversleuteld over het netwerk. Het is de verantwoordelijkheid van de gebruiker om bij het gebruik van deze protocollen het type van de verzonden data te beperken.Geheug dump services op afstand, zoals
netdump, verzenden de inhoud van het geheugen onversleuteld over het netwerk. Geheugen dumps kunnen wachtwoorden bevatten of, nog erger, database ingangen en andere gevoelige informatie.Andere services zoalsfingerenrwhodonthullen informatie over gebuikers van het systeem.
Voorbeelden van inherent onveilige services zijn
rlogin, rsh, telnet, en vsftpd.
Alle login en shell programma's op afstand (
rlogin, rsh, en telnet) moeten vermeden worden ten gunste van SSH. Refereer naar Paragraaf 2.1.7, “Communicatie greedschappen met verbeterde beveiliging” voor meer informatie over sshd.
FTP is niet even inherent gevaarlijk voor de beveiliging van het systeem als shells op afstand, maar FTP servers moeten zorgvuldig ingesteld en bewaakt worden om problemen te vermijden. Refreer naar Paragraaf 2.2.6, “FTP beveiligen” voor meer informatie over het beveiligen van FTP servers.
Services die zorgvulding ingesteld moeten worden en zich achter een firewall moeten bevinden omvatten:
fingerauthd(deze werdidentdgenoemd in vorige Fedora vrijgaves.)netdumpnetdump-servernfsrwhodsendmailsmb(Samba)yppasswddypservypxfrd
Meer informatie over het beveiligen van netwerk services is beschikbaar in Paragraaf 2.2, “Server beveiliging”.
De volgende paragraaf bespreekt gereedschappen om een eenvoudige firewall in te stellen
2.1.6. Persoonlijke firewalls
Als de noodzakelijke netwerk services zijn ingesteld, is het belangrijk om een firewall te maken.
Belangrijk
Je moet de noodzakelijke services instellen en een firewall maken voordat je verbindt met het Internet of elk ander netwerk.
Firewalls beletten netwerkpakketten toegang tot de netwerk interface van het systeem. Als een verzoek komt voor een poort die geblokkeerd is door een firewall, wordt het verzoek genegeerd. Als een service luistert naar een van deze geblokkeerde poorten, ontvang het deze pakketten niet en is effectief uitgezet. Daarom moet zorg worden betracht bij het instellen van een firewall om toegang te blokkeren naar poorten die niet in gebruik zijn, terwijl poorten in gebruik door ingestelde services niet geblokkeerd moeten worden.
Voor de meeste gebruikers is het beste gereedschap voor het instellen van een eenvoudige firewall het grafische firewall instel gereedschap dat met Fedora meegeleverd wordt: het Firewall Configuration Tool (
system-config-firewall). Dit gereedschap maakt ruime iptables regels voor een algemene firewall door het gebruik van een controle paneel interface.
Refereer naar Paragraaf 2.8.2, “Basis firewall instelling” voor meer informatie over het gebruik van deze toepassing en zijn beschikbare opties.
Voor gevorderde gebruikers en server beheerders, is het handmatig instellen van een firewall met
iptables waarschijnlijk een betere optie. Refereer naar Paragraaf 2.8, “Firewalls” voor meer informatie. Refereer naar Paragraaf 2.9, “IPTables” voor een uitgebreide gids voor het iptables commando.
2.1.7. Communicatie greedschappen met verbeterde beveiliging
Met de de groei van de grootte en populariteit van het Internet is ook de bedreiging van communicatie onderschepping gegroeid. In de loop der jaren zijn gereedschappen ontwikkeld om communicatie die over het netwerk verstuurd wordt te versleutelen.
Fedora wordt geleverd met twee basis gereedschappen die versleutel algorithme's van hoog niveau en gebaseerd op publieke sleutels gebruiken om informatie te beschermen als het over het netwerk gaat.
- OpenSSH — Een vrije implementatie van het SSH protocol voor versleutelde netwerk communicatie.
- Gnu Privacy Guard (GPG) — Een vrije implementatie van de PGP (Pretty Good Privacy) versleutelings toepassing voor het versleutelen van data.
OpenSSH een een veiliger manier om toegang te krijgen naar een machine op afstand en vervangt oudere, onversleutelde services zoals
telnet en rsh. OpenSSH bevat een netwerk service sshd genaamd en drie commandoregel client toepassingen:
ssh— Een veilige console toegang client op afstand.scp— Een veilig copiëer commando op afstand.sftp— Een veilige pseudo-ftp client die interactieve bestand overdracht sessies toestaat.
Refereer naar Paragraaf 3.6, “Beveiligde shell” voor meer informatie onver OpenSSH.
Belangrijk
Hoewel de
sshd service inherent veilig is, moet de service up-to-date worden gehouden om beveiligingsdreigingen te voorkomen. Refereer naar Paragraaf 1.5, “Beveiligings vernieuwingen” voor meer informatie.
GPG is een manier om privé email communicatie te verzekeren. Het kan gebruikt worden zowel voor het emailen van gevoelige data over publieke netwerken, als het beschermen van gevoelige data op harde schijven.
2.2. Server beveiliging
Als een systeem wordt gebruikt als een server op een publiek netwerk, wordt het een doel voor aanvallen. Het versterken van het systeem en afsluiten van services is daarom van groot belang voor de systeembeheerder.
Voordat we ingaan op specifieke zaken, bekijken we eerste de volgende algemene aanwijzingen voor het verbeteren van de beveiliging van een server:
- Houd alle services bij de tijd om ze te beschermen tegen de nieuwste bedreigingen.
- Gebruik waar mogelijk veilige protocollen.
- Lever slechts een type netwerk service per machine waar mogelijk.
- Bewaak alle servers zorgvuldig voor verdachte activiteit.
2.2.1. Het beveiligen van services met TCP wrappers en xinetd
TCP wrappers bieden toegangscontrole voor een groot aantal services. De meeste moderne netwerk services, zoals SSH, Telnet, en FTP, gebruiken TCP wrappers, die de wacht houden tussen een binnenkomend verzoek en de gevraagde service.
De voordelen geboden door TCP wrappers worden versterkt als ze samengaan met
xinetd, een super service die extra toegangs, logging, verbindings, omleidings, en hulpbron gebruiks controle biedt.
Opmerking
Het is een goed idee om iptables firewall regels te gebruiken samen met TCP wrappers en
xinetd om redundantie te maken voor service toegangscontrole. Refereer naar Paragraaf 2.8, “Firewalls” meer informatie over het maken van firewalls met iptables commando's.
De volgende paragrafen veronderstellen een basis kennis van ieder onderwerp en richten zich op specifieke beveiligings opties.
2.2.1.1. Het verbeteren van beveiliging met TCP wrappers
TCP wrappers kunnen veel meer dan het weigeren van toegang tot services. Deze paragraaf laat zien hoe ze gebruikt kunnen worden om verbindings banners te sturen, te waarschuwen voor aanvallen van bepaalde hosts, en de logging functionaliteit te verbeteren. Refereer naar de
hosts_options manula pagina voor informatie over de TCP wrapper functionaliteit en controle taal.
2.2.1.1.1. TCP wrappers en verbindings banners
Het laten zien van een geschikte banner als gebruikers verbinden met een service is een goede manier om potentiele aanvallers te laten weten dat de systeembeheerder waakzaam is. Je kunt ook bepalen welke informatie over het systeem aan gebruikers gepresenteerd wordt. Om een TCP wrapper banner te maken voor een service, gebruik je de
banner optie.
Dit voorbeeld maakt een banner voor
vsftpd. Om te beginnen maak je een banner bestand. Het kan zich overal op het systeem bevinden, maar het moet dezelfde naam hebben als de daemon. Voor dit voorbeeld, wordt het bestand /etc/banners/vsftpd genoemd en bevat de volgende regel:
220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed.
Het
%c symbool levert client informatie, zoals de gebruikersnaam en hostnaam, of de gebruikersnaam en IP adres om de verbinding nog intimiderender te maken.
Om deze banner te laten zien voor binnenkomende verbindingen, voeg je de volgende regel toe aan het
/etc/hosts.allow bestand:
vsftpd : ALL : banners /etc/banners/
2.2.1.1.2. TCP wrappers en aanval waarschuwingen
Als een bepaalde host of netwerk is ontdekt die de server aanvalt, kunnen TCP wrappers worden gebruikt om de beheerder te waarschuwen voor volgende aanvallen van die host of dat netwerk met het gebruik van de
spawn instructie.
In dit voorbeeld nemen we aan dat een cracker van het 206.182.68.0/24 netwerk is ondekt die probeerde de server aan te vallen. Plaats de volgende regel in het
/etc/hosts.deny bestand om alle verbindingspogingen van dat netwerk te verbieden, en log de pogingen in een speciaal bestand:
ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert
Het
%d symbool levert de naam van de service waarnaar de aanvaller toegang probeert te krijgen.
Om de verbinding toe te staan en het te loggen, plaats je de
spawn instructie in het /etc/hosts.allow bestand.
Opmerking
Omdat de
spawn instructie elk shell commando uitvoert, is het een goed idee om een speciaal script te maken om de beheerder te waarschuwen of een aantal commando's uit te voeren in het geval dat een bepaalde client probeert met de server te verbinden.
2.2.1.1.3. TCP wrappers en verbeterde logging
Als bepaalde types verbindingen van meer belang zijn dan andere, kan het log niveau verhoogd worden voor die service door de
severity optie te gebruiken.
Voor dit voorbeeld nemen we aan dat iedereen die probeert met poort 23 (Telnet) te verbinden op een FTP server een cracker is. Om dit aan te geven, plaats je een
emerg vlag in de log bestanden in plaats van de standaard vlag, info, en je verbiedt de verbinding.
Om dit te doen plaats je de volgende regel in
/etc/hosts.deny:
in.telnetd : ALL : severity emerg
Dit gebruikt de standaard
authpriv logging faciliteit, maar verhoogt de prioriteit van de standaard waarde info naar emerg, welke de log boodschappen rechtstreeks naar de console stuurt.
2.2.1.2. Beveiliging verbeteren met xinetd
Deze paragraaf richt zich op het gebruik van
xinetd om een valluik service in te stellen en het te gebruiken om hulpbron niveau's te controleren die beschikbaar zijn voor een gegeven xinetd service. Het instellen van hulpbron limieten kan helpen Weigering van service (DoS) aanvallen af te slaan. Refereer naar de manual pagina's voor xinetd en xinetd.conf voor een lijst van beschikbare opties.
2.2.1.2.1. Het instellen van een valluik
Een belangrijke eigenschap van
xinetd is de mogelijkheid om hosts toe te voegen aan een globale no_access lijst. Hosts op die lijst wordt het verboden om latere verbindingen te maken naar services die beheerd worden door xinetd voor een specifieke periode of totdat xinetd opnieuw is gestart. Je kunt dit doen door de SENSOR atribuut te gebruiken. Dit is een eenvoudige manier om hosts te blokkeren die proberen om de poorten van de server te scannen.
De eerste stap in het instellen van een
SENSOR is een service te kiezen die je niet van plan bent te gebruiken. Voor dit voorbeeld wordt Telnet gebruikt.
Bewerk het bestand
/etc/xinetd.d/telnet en verander de flags regel in:
flags = SENSOR
Voeg de volgende regel toe:
deny_time = 30
Dit verbiedt verdere vebindings pogingen naar die poort voor die host gedurende 30 minuten. Andere mogelijke waarden voor de
deny_time attribuut zijn FOREVER, welke het verbod laat duren totdat xinetd opnieuw is opgestart, en NEVER, die de verbinding toestaat en het logt.
De laatste regel moet tenslotte zijn:
disable = no
Dit zet de valluik zelf aan.
Terwijl het gebruik van
SENSOR een goede manier is om verbindingen van ongewenste hosts te detecteren en te stoppen, heeft het twee nadelen:
- Het werkt niet tegen heimelijke scans.
- Een aanvaller die weet dat een
SENSORdraait kan een Weigering van service aanval opzetten tegen bepaalde hosts door hun IP adressen te vervalsen en te verbinden met de verboden poort.
2.2.1.2.2. De hulpbronnen van de server controleren
Een andere belangrijke eigenschap van
xinetd is de mogelijkheid om hulpbron limieten in te stellen voor de services die het controleert.
Dit gebeurt met de volgende instructies:
cps = <number_of_connections> <wait_period>— Beperkt de snelheid van binnenkomende verbindingen. Deze instructie heeft twee argumenten:<number_of_connections>— Het aantal verbindingen per seconde die behandeld worden. Als de snelheid van de binnenkomende verbindingen hoger wordt, wordt de service tijdelijk uitgezet. De standaard waarde is vijftig (50).<wait_period>— Het aantal seconden die gewacht wordt totdat de service weer aangezet wordt nadat het is uitgezet. Het standaard interval is tien (10) seconden.
instances = <number_of_connections>— Specificeert het totale aantal verbindingen die toegstaan zijn voor een service. Deze instructie acceptert een geheel getal ofUNLIMITED.per_source = <number_of_connections>— Specificeert het aantal verbindingen toegestaan naar een service voor iedere host. Deze instructie accepteert een geheel getal ofUNLIMITED.rlimit_as = <number[K|M]>— Specificeert de hoeveelheid geheugen adres ruimte die de service kan bezetten in kilobytes of megabytes. Deze instructie accepteert een geheel getal ofUNLIMITED.rlimit_cpu = <number_of_seconds>— Specificeert de tijd in seconden die een service magen vragen van de CPU. Deze instructie accepteert een geheel getal ofUNLIMITED.
Het gebruiken van deze instructies kan helpen voorkomen dat een enkel
xinetd service het systeem overspoelt, resulterende in een weigering van service.
2.2.2. Portmap beveiligen
De
portmap service is een dynamische poort toekennings daemon voor RPC services zoals NIS en NFS. Het heeft zwakke authenticatie mechanismes en heeft de mogelijkheid om een brede reeks poorten toe te kennen aan de services die het controleert. Om deze redenen is het moeilijk te beveiligen.
Opmerking
Portmap beveiligen heeft alleen effect voor NFSv2 en NFSv3 implementaties, omdat NFSv4 het niet langer nodig heeft. Als je van plan bent om een NFSv2 of NFSv3 server te maken, is portmap vereist, en is de volgende paragraaf van toepassing.
Als je RPC services draait, volg dan deze basis regels.
2.2.2.1. Bescherm portmap met TCP wrappers
Het is belangrijk om TCP wrappers te gebruiken om te beperken welke netwerken of hosts toegang hebben tot de
portmap service omdat het geen ingebouwde vorm van authenticatie bevat.
Gebruik verder alleen IP adressen om toegang tot de server te beperken. Vermijd het gebruik van hostnamen, omdat ze vervalst kunnen worden door DNS vergiftiging en andere methodes.
2.2.2.2. Bescherm portmap met iptables
Om verdere toegang tot de
portmap service te beperken, is het een goed idee om iptables regels toe te voegen aan de server en de toegang te beperken tot specifieke netwerken.
Hieronder zijn twee voorbeeld iptables commando's. De eerste staat TCP verbindingen toe naar poort 111 (gebruikt door de
portmap service) vanaf het 192.168.0.0/24 netwerk. De tweede staat TCP verbindingen toe naar dezelfde poort vanaf de localhost. Dit is nodig voor de sgi_fam service gebruikt door Nautilus. Alle andere pakketten worden genegeerd.
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
Om op dezelfde manier UDP verkeer te beperken, gebruik je het volgende commando.
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP
Opmerking
Refereer naar Paragraaf 2.8, “Firewalls” voor meer informatie over het maken van firewalls met iptables commando's.
2.2.3. Het beveiligen van NIS
Het Network Information Service (NIS) is een RPC service,
ypserv genaamd, welke wordt gebruikt in combinatie met portmap en andere gerelateerde services om overzichten van gebruikersnamen, wachtwoorden en andere gevoelige informatie te verspreiden naar elke computer die beweert zich binnen het domein te bevinden.
Een NIS server wordt opgebouwd met verscheidene toepassingen. Ze omvatten de volgende:
/usr/sbin/rpc.yppasswdd— Ook deyppasswddservice genoemd, deze daemon staat gebruikers toe om hun NIS wachtwoorden te veranderen./usr/sbin/rpc.ypxfrd— Ook deypxfrdservice genoemd, deze daemon is verantwoordelijk voor NIS map verplaatsingen over het netwerk./usr/sbin/yppush— Deze toepassing geeft veranderde NIS databases door aan meerdere NIS servers./usr/sbin/ypserv— Dit is de NIS server daemon.
NIS is een beetje onveilig naar de hedendaagse standaarden. Het heeft geen host authenticatie mechanisme en verstuurt alle informatie onversleuteld over het netwerk, inclusief wachtwoord hashes. Daarom moet bijzondere zorg in acht genomen worden bij het opzetten van een netwerk dat NIS gebruikt. Dit wordt verder ingewikkeld gemaakt door het feit dat de standaard instelling van NIS inherent onveilig is.
Het wordt aanbevolden om iedereen die van plan is een NIS server te maken, eerst de
portmap service beveiligt zoals aangegeven in Paragraaf 2.2.2, “Portmap beveiligen”, en daarna de volgende zaken beschouwt, zoals netwerk planning.
2.2.3.1. Plan het netwerk zorgvuldig
Omdat NIS gevoelige informatie onversleuteld over het netwerk verstuurt, is het belangrijk dat de service achter een firewall en op een opgedeeld en veilig netwerk draait. Telkens wanneer NIS informatie over een onveilig netwerk wordt verstuurd, loopt het een risico om onderschept te worden. Zorgvuldig netwerk ontwerp kan ernstige beveiligings schendingen helpen voorkomen
2.2.3.2. Gebruik een NIS domeinnaan en hostnaam die lijkt op een wachtwoord
Elke machine binnen een NIS domein kan commando's gebruiken om informatie te achterhalen van de server zonder autheticatie, mits de gebruiker de DNS hostnaam van de server en de NIS domeinnaam weet.
Bijvoorbeeld, als iemand of een laptop computer met het netwerk verbindt of van buiten in het netwerk inbreekt (en er inslaagt om een intern IP adres te vervalsen), laat het volgende commando de
/etc/passwd map zien:
ypcat -d<NIS_domein>-h<DNS_hostnaam>passwd
Als deze aanvaller de root gebruiker is, kan deze het
/etc/shadow bestand verkrijgen met het volgende commando:
ypcat -d<NIS_domein>-h<DNS_hostnaam>shadow
Opmerking
Als Kerberos wordt gebruikt, wordt het
/etc/shadow bestand niet bewaard in een NIS map.
Om toegang tot NIS mappen moeilijker te maken voor een aanvaller, maak je een DNS hostnaam bestaande uit willekeurige karakters, zoals
o7hfawtgmhwg.domain.com. Maak op dezelfde manier een andere willekeurige NIS domeinnaam. Dit maakt het veel moeilijker voor een aanvaller om toegang te krijgen tot de NIS server.
2.2.3.3. Bewerk het /var/yp/securenets bestand
Als het
/var/yp/securenets bestand leeg is of niet bestaat (zoals het geval is na een standaard installatie), luistert NIS naar alle netwerken. Een van de eerste dingen om te doen is om netmasker/netwerk paren in het bestand te plaatsen zodat ypserv alleen verzoeken van het juiste netwerk beantwoordt.
Hieronder staat een voorbeeld regel in een
/var/yp/securenets bestand:
255.255.255.0 192.168.0.0
Waarschuwing
Start een NIS server nooit op voordat het
/var/yp/securenets bestand aangemaakt is.
Deze techniek geeft geen bescherming tegen een IP adres vervalsings aanval, maar beperkt ten minste de netwerken die bediend worden door de NIS server.
2.2.3.4. Ken statische poorten toe en gebruik iptables regels
Alle servers gerelateerd aan NIS kunnen specifieke poorten toegewezen krijgen behalve voor
rpc.yppasswdd — de daemon die gebruikers toestaat hun login wachtwoord te veranderen. Poorten toekennen aan de andere twee NIS server daemons, rpc.ypxfrd en ypserv, staat toe om firewall regels te maken om de NIS server daemons verder te beschermen tegen indringers.
Om dit te doen, voeg je de volgende rgels toe aan
/etc/sysconfig/network:
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
De volgende iptables regels kunnen dan gebruikt worden om te forceren naar welk netwerk de server luistert op deze poorten:
iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP
Dit betekent dat de server alleen verbindingen naar poort 834 en 835 toestaat als het verzoek van het 192.168.0.0/24 netwerk komt, ongeacht het protocol.
Opmerking
Refereer naar Paragraaf 2.8, “Firewalls” voor meer informatie over het maken van firewalls met iptables commando's.
2.2.3.5. Gebruik Kerberos authenticatie
Een van de problemen te overwegen als NIS gebruikt wordt voor authenticatie is dat telkens als een gebruiker inlogt op een machine, een wachtwoord hash van de
/etc/shadow map verstuurd wordt over het netwerk. Als een indringer toegang krijgt tot een NIS domein en het netwerkverkeer besnuffelt, kan deze gebruikersnamen en wachtwoord hashes verzamelen. Met genoeg tijd, kan een wachtwoord kraakprogramma zwakke wachtwoorden raden, en een aanvaller kan toegang krijgen tot een geldig account op het netwerk.
Omdat Kerberos geheime-sleutel versleuteling gebruikt, worden nooit wachtwoord hashes over het netwerk verstuurd, wat het systeem veel veiliger maakt. Refereer naar Paragraaf 2.6, “Kerberos” voor meer informatie over Kerberos.
2.2.4. NFS beveiligen
Belangrijk
De versie van NFS in Fedora, NFSv4, heeft de
portmap service niet langer nodig zoals aangegeven is in Paragraaf 2.2.2, “Portmap beveiligen”. NFS verkeer gebruikt nu TCP in alle versies, in plaats van UDP, en vereist dit als NFSv4 gebruikt wordt. NFSv4 bevat nu Kerberos gebruiker en groep authenticatie, als onderdeel van de RPCSEC_GSS kernel module. Informatie over portmap wordt nog steeds gegeven, omdat Fedora NFSv2 en NFSv3 ondersteunt, welke beide portmap nog gebruiken.
2.2.4.1. Plan het netwerk zorgvuldig
Nu NFSv4 de mogelijkheid heeft om alle informatie met gebruik van Kerberos versleuteld over een netwerk te versturen, is het belangrijk dat de service correct ingesteld wordt als het achter een firewall of in een verdeeld netwerk is. NFSv2 en NFSv3 geven data nog steeds onveilig door, en dit moet in gedachte worden gehouden. Zorgvuldig netwerk ontwerp in al deze opzichten kunnen beveiligings inbreuken helpen voorkomen.
2.2.4.2. Let op syntax fouten
De NFS server bepaalt welke bestandssystemen geëxporteerd worden en welke hosts deze mappen moeten exporteren door het raadplegen van het
/etc/exports bestand. Let er op om geen onnodige spaties toe te voegen bij het bewerken van dit bestand.
Bijvoorbeeld, de volgende regel in het
/etc/exports bestand deelt de map /tmp/nfs/ met de host bob.example.com met lees/schrijf rechten.
/tmp/nfs/ bob.example.com(rw)
De volgende regel in het
/etc/exports bestand, echter, deelt dezelfde map met de host bob.example.com met alleen-lezen rechten en deelt het met de wereld met lees/schrijf rechten dankzij de enkele spatie achter de hostnaam.
/tmp/nfs/ bob.example.com (rw)
Het is een goede praktijk om alle ingestelde NFS delingen te controleren met gebruik van het
showmount commando om te verifieren wat er gedeeld wordt:
showmount -e <hostnaam>
2.2.4.3. Gebruik de no_root_squash optie niet
Standaard veranderen NFS delingen de root gebruiker naar de
nfsnobody gebruiker, een gebruikersaccount zonder rechten. Dit verandert de eigenaar van alle door root aangemaakte bestanden naar nfsnobody, wat verhindert dat programma's binnen gehaald worden waarbij de setuid bit gezet is.
Als
no_root_squash wordt gebruikt, zijn root gebruikers op afstrand in staat om elk bestand in het gedeelde bestandssysteem te veranderen en toepassingen besmet met een trojaan achter te laten die andere gebruikers onopzettelijk uitvoeren.
2.2.4.4. NFS firewall instelling
De voor NFS gebruikte poorten worden dynamisch toegekend door rpcbind, wat problemen kan veroorzaken bij het maken van firewall regels. Om dit proces te vereenvoudigen gebruik je het /etc/sysconfig/nfs bestand om op te geven welke poorten gebruikt moeten worden:
MOUNTD_PORT— TCP en UDP poort voor mountd (rpc.mountd)STATD_PORT— TCP en UDP poort voor status (rpc.statd)LOCKD_TCPPORT— TCP poort voor nlockmgr (rpc.lockd)LOCKD_UDPPORT— UDP poort nlockmgr (rpc.lockd)
De opgegeven poortnummers moeten niet door een andere service gebruikt worden. Stel je firewall in om de opgegeven poortnummers toe te laten, en ook TCP en UDP poort 2049 (NFS).
Voer het
rpcinfo -p commando uit op de NFS server om te zien welke poorten en RPC progragramma's gebruikt worden.
2.2.5. De Apache HTTP server beveiligen
De Apache HTTP server is een van de meest stabiele en veilige services die meegeleverd worden met Fedora. Een groot aantal opties en technieken zijn beschikbaar om de Apache HTTP server te beveiligen — te veel om ze hier diepgaand te behandelen. De volgende paragraaf legt in het kort goede praktijken uit voor het draaien van de Apache HTTP server.
Controleer altijd dat alle scripts die op het systeem draaien werken zoals bedoeld is voordat je ze in gebruik neemt. Verzeker je er ook van dat alleen de root gebruiker schrijf rechten heeft in alle mappen die scripts of CGI's bevatten. Om dit te doen, voer je de volgende commando's uit als de root gebruiker:
chown root
<map_naam>chmod 755
<map_naam>
Systeembeheerders moeten opletten als de volgende configuratie opties gebruikt worden (ingesteld in
/etc/httpd/conf/httpd.conf):
FollowSymLinks- Deze instructie is standaard aangezet, dus wees voorzichtig met het maken van symbolische links naar de document root van de Web server. Bijvoorbeeld, het is een slecht idee om een symbolische link naar
/te maken. Indexes- Deze instructie is standaard aangezet, maar kan dit kan ongewenst zijn. Om te voorkomen dat bezoekers door bestanden op de server bladeren, verwijder je deze instructie.
UserDir- De
UserDirinstructie is standaard uitgezet omdat dit de aanwezigheid van een gebruikersaccount op het systeem kan bevestigen. Om het bladeren door gebruikersmappen op de server toe te staan, gebruik je de volgende instructies:UserDir enabled UserDir disabled root
Deze instructies activeren het bladeren door gebruikersmappen voor alle gebruikersmappen anders dan/root/. Om gebruikers toe te voegen aan de lijst uitgezette account, voeg je een door spaties gescheiden lijst van gebruikers toe aan deUserDir disabledregel.
Belangrijk
Verwijder de
IncludesNoExec instructie niet. Standaard kan de Server-Side Includes (SSI) module geen commando's uitvoeren. Het wordt aanbevolen dat je deze instelling niet verandert behalve als het obsoluut noodzakelijk is, om dat het in potentie een aanvaller in staat stelt om commando's op het systeem uit te voeren.
2.2.6. FTP beveiligen
Het File Transfer Protocol (FTP) is een ouder TCP protocol ontworpen voor het overbrengen van bestanden over een netwerk. Omdat alle transacties met de server, inclusief gebruikers authenticatie, onversleuteld zijn, wordt het beschouwd als een onveilig protocol en moet het zorgvuldig ingesteld worden.
Fedora levert drie FTP servers.
gssftpd— Een ftp daemon gebaseerd opxinetden bewust van Kerberos, die geen authenticatie informatie over het netwerk verstuurt.- Red Hat Content Accelerator (
tux) — Een kernel-ruimte Web server met FTP mogelijkheden. vsftpd— Een op zich staande, op veiligheid georienteerde uitvoering van de FTP service.
De volgende beveiligingsrichtlijnen gelden voor het instellen van de
vsftpd FTP service.
2.2.6.1. FTP begroetings koptekst
Voordat een gebruikersnaam en wachtwoord verstuurd worden, krijgen alle gebruikers een begroetings koptekst. Standaard bevat deze koptekst versie informatie die nuttig is voor crackers om te proberen zwaktes in een systeem te identificeren.
Om de begroetings koptekst voor
vsftpd te veranderen, voeg je de volgende instructie toe aan het /etc/vsftpd/vsftpd.conf bestand:
ftpd_banner=<vul_hier_begroeting_in>
Vervang
<vul_hier_begroeting_in> in bovenstaande instructie met de tekst van de begroetingsboodschap.
Voor kopteksten met meerdere regels, is het het beste om een kopstekst bestand te gebruiken. Om het beheer van meerdere kopteksten te vereenvoudigen, plaats je alle kopteksten in een nieuwe map met de naam
/etc/banners/. Het koptekst bestand voor FTP verbindingen is in dit voorbeeld /etc/banners/ftp.msg. Hieronder is een voorbeeld hoe zo'n bestand er uit kan zien:
######### # Hallo, alle activiteit op ftp.example.com wordt gelogged. #########
Opmerking
Het is niet nodig om elke regel van het bestand te beginnen met
220 zoals opgegeven is in Paragraaf 2.2.1.1.1, “TCP wrappers en verbindings banners”.
Om deze begroetings koptekst te koppelen aan
vsftpd, voeg je de volgende instructie toe aan het /etc/vsftpd/vsftpd.conf bestand:
banner_file=/etc/banners/ftp.msg
Het is ook mogelijk om extra kopteksten te sturen naar binnenkomende verbindingen die TCP wrappers gebruiken zoals beschreve in Paragraaf 2.2.1.1.1, “TCP wrappers en verbindings banners”.
2.2.6.2. Anonieme toegang
De aanwezigheid van de
/var/ftp/ map activeert het anonymous account.
De eenvoudigste manier om deze map te maken is het installeren van het
vsftpd pakket. Dit pakket zet een mapstructuur op voor anonieme gebruikers en stelt de rechten voor mappen in op alleen-lezen voor anonieme gebruikers.
Standaard kan de anonieme gebruiker in geen enkele map schrijven.
Waarschuwing
Als anonieme toegang naar een FTP server ingesteld wordt, let er dan op waar gevoelige informatie wordt bewaard.
2.2.6.2.1. Anonieme upload
Om anonieme gebruikers toe te staan om bestanden te uploaden, wordt het aanbevolen dat een alleen-schrijven map aangemaakt wordt binnen
/var/ftp/pub/.
Om dit te doen voer je het volgende commando uit:
mkdir /var/ftp/pub/upload
Vervolgens verander je de rechten zodat anonieme gebruikers de inhoud van de map niet kunnen bekijken:
chmod 730 /var/ftp/pub/upload
Een lang formaat inhoudslijst van de moet moet er zo uit zien:
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload
Waarschuwing
Beheerders die anonieme gebruikers toestaan om in mappen te lezen en te schrijven ontdekken vaak dat hun servers een repository van gestolen software worden.
Bovendien voeg je voor
vsftpd de volgende regel toe aan het /etc/vsftpd/vsftpd.conf bestand:
anon_upload_enable=YES
2.2.6.3. Gebruikersaccounts
Omdat FTP voor authenticatie onversleutelde gebruikersnamen en wachtwoorden verstuurd over onveilige netwerken, is het een goed idee om systeem gebruikers toegang tot de server vanaf hun gebruikersaccount te verbieden.
Om alle gebruikersaccount in
vsftpd uit te zetten, voeg je de volgende instructie toe aan /etc/vsftpd/vsftpd.conf:
local_enable=NO
2.2.6.3.1. Gebruikersaccounts beperken
Voor het uitzetten van FTP toegang voor specifieke accounts of specifieke groepen van accounts, zoals de root gebruiker en gebruikers met
sudo rechten, is dit het eenvoudigst te doen met een PAM lijst zoals beschreven in Paragraaf 2.1.4.2.4, “Root onmogelijk maken met PAM”. Het PAM configuratie bestand voor vsftpd is /etc/pam.d/vsftpd.
Het is ook mogelijk om gebruikersaccounts direct binnen elke service uit te zetten.
Om een specifiek gebruikersaccount in
vsftpd uit te zetten, voeg je de gebruikersnaam toe aan /etc/vsftpd.ftpusers
2.2.6.4. Gebruik TCP wrappers om toegang te controleren
Gebruik TCP wrappers om toegang tot elke FTP daemon te controleren zoals beschreven in Paragraaf 2.2.1.1, “Het verbeteren van beveiliging met TCP wrappers”.
2.2.7. Sendmail beveiligen
Sendmail is een Mail Transfer Agent (MTA) die het Simple Mail Transfer Protocol (SMTP) gebruikt om electronische boodschappen te bezorgen naar andere MTA's en naar email clienten of afleveringsagenten. Hoewel vele MTA's hun verkeer kunnen versleutelen, doen de meeste dit niet, dus het versturen van email over alle publieke netwerken wordt als een inherent onveilige manier van communicatie beschouwd.
Het wordt aanbevolen dat iedereen die van plan is een Sendmail server te maken aandacht geeft aan de volgende punten.
2.2.7.1. Het beperken van een service weigerings aanval
Door de aard van email, kan een vastbesloten aanvaller de server gemakkelijk met mail overspoelen en zo een service weigering veroorzaken. Door limieten in te stellen voor de volgende instructies in
/etc/mail/sendmail.mc, wordt de effectiviteit van zulke aanvallen beperkt.
confCONNECTION_RATE_THROTTLE— Het aantal verbindingen die de server per seconde kan ontvangen. Standaard heeft Sendmail geen limiet op het aantal verbindingen. Als een limiet ingesteld is en bereikt wordt, worden verdere verbindingen vertraagd.confMAX_DAEMON_CHILDREN— Het maximale aantal child processen die de server kan opstarten. Standaard kent Sendmail geen limiet toe aan het aantal child processen. Als een limiet ingesteld is en bereikt wordt, worden verdere verbindingen vertraagd.confMIN_FREE_BLOCKS— Het minimale aantal vrije blokken die beschikbaar moet zijn voor de server om mail te accepteren. De standaard is 100 blokken.confMAX_HEADERS_LENGTH— De maximaal aanvaardbare grootte (in bytes) van een bericht koptekst.confMAX_MESSAGE_SIZE— De maximaal aanvaardbare grootte (in bytes) voor een enkel bericht.
2.2.7.2. NFS en Sendmail
Plaats de mail spool map,
/var/spool/mail/, nooit in een NFS gedeelde volume.
Omdat NFSv2 and NFSv3 geen controle onderhouden van gebruikers en groeps ID's, kunnen twee of meer gebruikers dezelfde UID hebben en kunnen elkaars mail ontvangen en lezen.
Opmerking
Met het gebruik van Kerberos door NFSv4 is dit hier niet het geval, omdat de
SECRPC_GSS kernel module geen op UID gebaseerde authenticatie gebruikt. Het wordt echter nog steeds als een goede praktijk beschouwd on de mail spool map niet op een NFS gedeelde volume te plaatsen.
2.2.7.3. Alleen-mail gebruikers
Om uitbuitingen door locale gebruikers van de Sendmail server te helpen voorkomen, is het het beste dat mail gebruikers alleen toegang hebben tot de Sendmail server door het gebruik van een email programma. Shell account moeten op de mail server niet toegelaten worden en alle gebruikers in het
/etc/passwd bestand moeten ingesteld worden met /sbin/nologin (met de root gebruiker als mogelijke uitzondering).
2.2.8. Het verifieren van welke poorten luisteren
Na het instellen van de netwerk services, is het belangrijk om aandacht te geven naar welke poorten van de interfaces van het netwerk van het systeem feitelijk geluisterd wordt.
Er zijn twee basis benaderingen voor het opsommen van de poorten die luisteren op het netwerk. De minst betrouwbare benadering is het bevragen van de netwerk status stack met gebruik van commando's zoals
netstat -an of lsof -i. Deze methode is minder betrouwbaar omdat deze programma's niet met de machine verbinden vanaf het netwerk, maar in plaats daarvan controleren wat er op de server draait. Om deze reden zijn deze toepassingen vaak doelen voor aanvallers. Crackers proberen hun sporen te verbergen als ze ongeoorloofde poorten openen door het vervangen van netstat en lsof met hun eigen, veranderde versies.
Een meer betrouwbare manier om te controleren welke poorten op het netwerk luisteren is om een poort scanner te gebruiken zoals
nmap.
Het volgende comando uitgevoerd vanaf de console bepaalt welke poorten luisteren naar TCP verbindingen op het netwerk:
nmap -sT -O localhost
De output van dit commando is als volgt:
Starting Nmap 4.68 ( http://nmap.org ) at 2009-03-06 12:08 EST Interesting ports on localhost.localdomain (127.0.0.1): Not shown: 1711 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 834/tcp open unknown 2601/tcp open zebra 32774/tcp open sometimes-rpc11 Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.24 Uptime: 4.122 days (since Mon Mar 2 09:12:31 2009) Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.420 seconds
Deze output laat zien dat het systeem
portmap draait door de aanwezigheid van de sunrpc service. Er is echter ook een geheimzinnige service op poort 834. Om te controleren of de poort verbonden is met de officiele lijst van bekende services, type je:
cat /etc/services | grep 834
Dit commando geeft geen output terug. Dit geeft aan dat hoewel de poort zich in een gereserveerde reeks bevindt (0 tot en met 1024) en root toegang nodig heeft om geopend te worden, het niet verbonden is met een bekende service.
Vervolgens zoeken we naar informatie met het gebruik van
netstat of lsof Om poort 834 te controleren met netstat, gebruik je het volgende commando:
netstat -anp | grep 834
Het commando geeft de volgende output terug:
tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind
De aanwezigheid van de open poort in
netstat is geruststellend omdat een cacker die een poort op een gekraakt systeem stiekem opent het niet zal toestaan dat dit ontdekt wordt met dit commando. De [p] optie laat ook het proces ID (PID) zien van de service die de poort opende. In dit geval behoort de open poort toe aan ypbind (NIS), wat een RPC service is die in combinatie met de portmap service afgehandeld wordt.
Het
lsof commando laat soortgelijke informatie zien als netstat omdat het ook in staat is om open poorten te verbinden met services:
lsof -i | grep 834
Het relevante gedeelte van de output van dit commando is:
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
Deze gereedschappen laten veel zien over de status van services die op een machine draaien. Deze gereedschappen zijn flexibel en bieden een schat van informatie over netwerk services en instellingen. Refereer naar de manual pagina's voor
lsof, netstat, nmap, en services voor meer informatie.
2.3. Eenmalig inschrijven (Single sign-on - SSO)
2.3.1. Inleiding
De Fedora SSO functionaliteit reduceert het aantal keren dat Fedora bureaublad gebruikers hun wachtwoord moeten opgeven. Verscheidene belangrijke toepassingen gebruiken hetzelfde onderliggende authenticatie en autorisatie mechanisme zodat gebruikers op Fedora in kunnen loggen met het log-in scherm, en daarna hun wachtwoord niet opnieuw hoeven op te geven. Deze toepassingen worden hieronder beschreven.
Bovendien kunnen gebruikers inloggen op hun machine zelfs als er geen netwerk is (offline mode) of als de netwerkverbinding onbetrouwbaar is, bijvoorbeeld draadloze toegang. In het laatste geval zullen services elegant afnemen.
2.3.1.1. Ondersteunde toepassingen
De volgende toepassingen worden op dit moment ondersteund door het verenigde log-in systeem in Fedora:
- Login
- Screensaver
- Firefox en Thunderbird
2.3.1.2. Ondersteunde authenticatie mechanismes
Fedora ondersteunt op dit moment de volgende authenticatie mechanismes:
- Kerberos naam/wachtwoord login
- Smart card/PIN login
2.3.1.3. Ondersteunde Smart Cards
Fedora is getest met de Cyberflex e-gate card en lezer, maar elke kaart die voldoet aan zowel Java card 2.1.1 als Global Platform 2.0.1 specificaties moet correct werken, evenals elke lezer die ondersteund wordt door PCSC-lite.
Fedora is ook getest met Common Access Cards (CAC). De ondersteunde lezer voor CAC is de SCM SCR 331 USB Reader.
Sinds Fedora 5.2 worden Gemalto smart cards (Cyberflex Access 64k v2, standaard met DER SHA1 waarde ingesteld als in PKCSI v2.1) ondersteund. Deze smart cards zijn nu lezer compatibel met Chip/Smart Card Interface Devices (CCID).
2.3.1.4. Voordelen van Fedora eenmalig inschrijven
Op dit moment bestaan er vele beveiligings mechanismes die een groot aantal protocollen en bewaarplaatsen voor legitimatie gebruiken. Voorbeelden zijn SSL, SSH, IPsec, en Kerberos. Fedora SSO heeft als doel om deze systemen te verenigen om de hierboven getoonde vereisten te ondersteunen. Dit betekent niet dat Kerberos vervangen wordt door X.509v3 certificaten, maar meer ze te fuseren om de last te verlichten van zowel systeem gebruikers als de beheerders die deze beheren.
Om dit doel te bereiken heeft Fedora:
- Een enkele, gedeelde instantiatie van de NSS crypto bibliotheken voor ieder operating systeem.
- Het Certificate System's Enterprise Security Client (ESC) met het basis operating systeem. De ESC toepassing bewaakt smart card transacties. Als het ontdekt dat een gebruiker een smart card heeft gebruikt die ontworpen was om gebruikt te worden met het Fedora Certificate System server product, laat het een gebruikers interface zien met instructies om die smart card in dienst te nemen.
- Kerberos en NSS verenigd zodat gebruikers die inloggen op het operating systeem met gebruik van een smart card ook een Kerberos legitimatie krijgen (die hen toestaat om in te loggen op de bestand server, enz.)
2.3.2. Beginnen met je nieuwe Smart Card
Voordat je jouw smart card kunt gebruiken om in te loggen op je systeem en voordeel te hebben van de verbeterde beveiligings opties die deze technologie biedt, moet je eerst een paar basis installatie en configuratie stappen uitvoeren. Deze zijn hieronder beschreven.
Opmerking
Deze paragraaf biedt een hoog-niveau overzicht om te beginnen met je smart card. Meer gedetaileerde informatie is beschikbaar in de Red Hat Certificate System Enterprise Security Client Guide.
- Log in met je Kerberos naam en wachtwoord
- Wees er zeker van dat je het
nss-toolspakket geladen hebt - Download en installeer de root certificaten voor jouw onderneming. Gebruik het volgende commando in de root CA certificaat te installeren:
certutil -A -d /etc/pki/nssdb -n "root ca cert" -t "CT,C,C" -i ./ca_cert_in_base64_format.crt
- Controleer dat de volgende RPM's op je systeem geinstalleerd zijn: esc, pam_pkcs11, coolkey, ifd-egate, ccid, gdm, authconfig, en authconfig-gtk.
- Zet Smart Card login ondersteuning aan
- In de GNOME menu balk selecteer je Systeem->Beheer->Authenticatie
- Type het root wachtwoord van de machine in, indien nodig.
- In de Authenticatie configureren dialoog, klik je op de Authenticatie tab.
- Selecteer het SmartCar-ondersteuning aanzetten vakje.
- Klik op de knop om de SmartCard-instellingen dialoog te laten zien, specificeer de gewenste instellingen:
- SmartCard vereist voor inloggen — Deselecteer dit vakje. Nadat je succesvol ingelogd hebt met je smart card kun je deze optie selecteren om te voorkomen dat andere gebruikers inloggen zonder smart card.
- Card verwijderen actie — Dit bepaalt wat er gebeurt als je de smart card verwijdert nadat je ingelogd hebt. De beschikbare opties zijn:
- Vergrendelen — Het verwijderen de smart card blokkeert het X scherm
- Negeren — Het verwijderen
- Als je het Online Certificate Status Protocol (OCSP) moet aanzetten, open je het
/etc/pam_pkcs11/pam_pkcs11.confbestand, en je zoekt de volgende regel:enable_ocsp = false;Verander deze waarde naar true, als volgt:enable_ocsp = true; - Neem je smart card in dienst
- Als je een CAC card gebruikt, moet je ook de volgende stappen uitvoeren:
- Verander naar de root account en maak een bestand aan met de naam
/etc/pam_pkcs11/cn_map. - Voeg de volgende regel toe aan het
cn_mapbestand:MY.CAC_CN.123454->mijnloginidwaarinMY.CAC_CN.123454de Common Name op jouw CAC is enmijnloginidje UNIX login ID is.
- Log uit
2.3.2.1. Foutzoeken
Als je problemen hebt om je smart card werkend te krijgen, probeer je het volgende commando om de bron van het probleen te localiseren:
pklogin_finder debug
Als je het
pklogin_finder gereedschap in de debug mode draait terwijl een in dienst genomen smart card ingebracht is, probeert het informatie te geven over de geldigheid van de certificaten, en als dat lukt probeert het een login ID te koppelen aan de certificaten op de card.
2.3.3. Hoe werkt het in gebruik nemen van een Smart Card
Smart cards zijn in gebruik genomen als ze een juist certificaat hebben ontvangen die is ondertekend door een geldige Certificaat Authoriteit (CA). Dit houdt verschillende stappen in, hieronder beschreven:
- De gebruiker stopt zijn smart card in de smart card lezer van zijn werkstation. Deze actie wordt herkend door de Enterprise Security Client (ESC).
- De in gebruik name pagina wordt getoond op het bureaublad van de gebruiker. De gebruiker vult de vereiste details in en het systeem van de gebruiker verbindt daarna met het Token Processing System (TPS) en de CA.
- De TPS neemt de smart card in gebruik met een certificaat getekend door de CA.
Hoe werkt Smart Card ingebruikname
Figuur 2.4. Hoe werkt het in gebruik nemen van een Smart Card
2.3.4. Hoe werkt inloggen met een Smart Card
Deze paragraaf geeft een kort overzicht van het inloggen met gebruik van een smart card.
- als de gebruiker zijn smart card in de smart card lezer stopt, dan wordt deze actie herkend door de PAM faciliteit, die de gebruiker naar zijn PIN vraagt.
- Het systeem zoekt dan de huidige certificaten van de gebruiker op en verifieert de geldigheid hiervan. Het certificaat wordt daarna afgebeeld op de UID van de gebruiker.
- Dit wordt bekrachtigd door de KDC en inloggen wordt toegestaan.
Hoe werkt inloggen met een Smart Card
Figuur 2.5. Hoe werkt inloggen met een Smart Card
Opmerking
Je kunt niet inloggen met een smart card die niet in gebruik genomen is, zelfs als deze al geformatteerd is. Je moet inloggen met een geformatteerde, in gebruik genomen card, of geen smart card gebruiken, voordat je een nieuwe card in gebruik kunt nemen.
Refereer naar Paragraaf 2.6, “Kerberos” en Paragraaf 2.4, “Pluggable Authentication Modules (PAM)” voor meer informatie over Kerberos en PAM.
2.3.5. Het instellen van Firefox om Kerberos te gebruiken voor SSO
Je kunt Firefox instellen om Kerberos te gebruiken voor eenmalig inschrijven. Om dit correct te laten werken, moet je jouw web browser instellen om jouw Kerberos legitimatie naar de juiste KDC te sturen. De volgende paragraaf beschrijft de configuratie veranderingen en andere vereisten om dit te bereiken.
- In de adresbalk van Firefox type je
about:configom de lijst van de huidige configuratie opties te laten zien. - In het Filter veld type je
negotiateom de lijst van opties te beperken. - Dubbel-klik op de network.negotiate-auth.trusted-uris regel om de Voer stringwaarde in dialoog op te roepen.
- Vul de naam van het domein in voor welke je wilt authenticeren, bijvoorbeeld,
.example.com. - Herhaal het bovenstaande voor de network.negotiate-auth.delegation-uris regel en gebruik hetzelfde domein.
Opmerking
Je kunt deze waarde leeg laten omdat het Kerberos kaartjes doorgeven toestaat, wat niet vereist is.Als je deze twee configuratie opties niet ziet, is je Firefox versie misschien te oud om Negotiate authenticatie te ondersteunen, en moet je een upgrade overwegen.
Het instellen van Firefox om Kerberos te gebruiken voor SSO
Figuur 2.6. Het instellen van Firefox voor SSO met Kerberos
Je moet er nu zeker van zijn dat je Kerberos kaartjes hebt. Op de commando regel type je
kinit om Kerberos kaartjes op te halen. Om de lijst van beschikbare kaartjes te laten zien, type je klist. Het volgende geeft een voorbeeld output van deze commando's:
[user@host ~] $ kinit
Password for user@EXAMPLE.COM:
[user@host ~] $ klist
Ticket cache: FILE:/tmp/krb5cc_10920
Default principal: user@EXAMPLE.COM
Valid starting Expires Service principal
10/26/06 23:47:54 10/27/06 09:47:54 krbtgt/USER.COM@USER.COM
renew until 10/26/06 23:47:54
Kerberos 4 ticket cache: /tmp/tkt10920
klist: You have no tickets cached
2.3.5.1. Foutzoeken
Als je de configuratie stappen hierboven hebt opgevolgd en Negotiate authenticatie werkt niet, kun je uitgebreide logging van het authenticatie proces aanzetten. Dit kan je helpen om de oorzaak van het probleem te vinden. Om uitgebreide logging aan te zetten, gebruik je de volgende procedure:
- Sluit alle instantiaties van Firefox.
- Open een commando shell, en type de volgende commando's:
export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
- Start Firefox opnieuw op in die shell, en bezoek de website waar authenticatie eerder niet lukte. Informatie zal opgeslagen worden in
/tmp/moz.log, en kan je misschien een idee geven over het probleem. Bijvoorbeeld:-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found
Dit geeft aan de je geen Kerberos kaartjes hebt, en je moetkinituitvoeren.
Als je
kinit succesvol op je machine kunt uitvoeren maar je kunt geen authenticatie uitvoeren, zul je misschien zoiets als het volgende in het log bestand zien:
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database
Dit geeft in het algemeen een Kerberos configuratie probleem aan. Wees er zeker van dat je de correcte regels in het [domain_realm] gedeelte van het
/etc/krb5.conf bestand hebt. Bijvoorbeeld:
.example.com = EXAMPLE.COM example.com = EXAMPLE.COM
Als er niets in de log verschijnt dan is het mogelijk dat je achter een proxy zit, en dat de proxy de HTTP kopteksten verwijdert die nodig zijn voor Negotiate authenticatie. Als noodoplossing, kun je proberen om met de server te verbinden met gebruik van HTTPS, welke het verzoek om onveranderd door te geven zal toestaan. Ga dan verder met het foutzoeken met het logbestand, zoals hierboven aangegeven.
2.4. Pluggable Authentication Modules (PAM)
Programma's die gebruikers toegang geven tot een systeem gebruiken authenticatie om elkaars identiteit te controleren (dat betekent, vast te stellen dat een gebruiker is wie hij zegt te zijn).
Vroeger had ieder programma zijn eigen manier voor de authenticatie van gebruikers. In Fedora zijn veel programma's ingesteld om een centraal authenticatie mechanisme te gebruiken, Pluggable Authentication Modules (PAM) genaamd
PAM gebruikt een inplugbare, modulaire architectuur, welke de systeemberheerder veel flexibiliteit toestaat in het instellen van authenticatie tactieken voor het systeem.
In de meeste gevallen is het standaard PAM configuratie bestand voldoende voor een toepassing die zich bewust is van PAM. Soms is het echter nodig om een PAM configuratie bestand te bewerken. Omdat een verkeerde instelling van PAM de systeem beveiliging kan aantasten, is het belangrijk om de structuur van deze bestanden te begrijpen voordat je veranderingen maakt. Refereer naar Paragraaf 2.4.3, “PAM configuratie bestand formaat” voor meer informatie.
2.4.1. Voordelen van PAM
PAM biedt de volgende voordelen:
- een gemeenschappelijk authenticatie systeem dat door een groot aantal toepassingen gebruikt kan worden.
- belangrijke flexibiliteit en controle over authenticatie voor zowel systeembeheerders als toepassingsontwikkelaars.
- een enkele, volledig gedocumenteerde bibliotheek die ontwikkelaars toestaat om programma's te schrijven zonder dat ze hun eigen authenticatie schema hoeven te maken.
2.4.2. PAM configuratie bestanden
De
/etc/pam.d/ map bevat de PAM configuratie bestanden voor elke toepassing die zich bewust is van PAM. In eerdere versies van PAM werd het /etc/pam.conf bestand gebruikt, maar dit bestand is nu verouderd en wordt alleen gebruikt als de /etc/pam.d/ map niet betaat.
2.4.2.1. PAM service bestanden
Iedere toepassing of service die zich bewust is van PAM heeft een bestand in de
/etc/pam.d/ map. Ieder bestand in deze map heeft dezelfde naam als de service waarvoor het de toegang controleert.
Het programma dat zich bewust is van PAM is verantwoordelijk voor het bepalen van de servicenaam en het installeren van zijn eigen PAM configuratie bestand in de
/etc/pam.d/ map. Bijvoorbeeld, het login programma definieert zijn service naam als login en installeert het /etc/pam.d/login PAM configuratie bestand.
2.4.3. PAM configuratie bestand formaat
Elk PAM configuratie bestand bevat een groep van instructies die als volgt geformatteerd zijn:
<module interface><controle vlag><module naam><module argumenten>
Ieder van dezel onderdelen worden in de volgende paragrafen uitgelegd.
2.4.3.1. Module interface
Op dit moment zijn er vier types PAM module interfaces beschikbaar. Elke van deze komt overeen met een verschillend aspect van het authenticatie proces:
auth— Deze module geeft authenticatie voor gebruik. Bijvoorbeeld, het verzoekt en verifieert de geldigheid van een wachtwoord. Modules met deze interface kunnen ook legitimatie instellen, zoals lidmaatschap van een groep of Kerberos kaartjes.account— Deze module interface verifieert of toegang is toegestaan. Bijvoorbeeld, het kan controleren of een gebruikersaccount verlopen is en of het een gebruiker toegestaan is op een bepaalde tijd van de dag in te loggen.password— Deze module interface wordt gebruikt voor het veranderen van wachtwoorden van gebruikers.session— Deze module interface configureert en beheert sessies. Modules met deze interface kunnen ook extra taken uitvoeren die nodig zijn om toegang toe te staan, zoals het aankoppelen van de persoonlijke map van de gebruiker en het beschikbaar maken van de mailbox van de gebruiker.
Opmerking
Een individuele module kan elke of alle module interfaces hebben. Bijvoorbeeld,
pam_unix.so biedt alle vier module interfaces.
In een PAM configuratie bestand, is de module interface gedefinieerd in het eerste veld. Bijvoorbeeld, een typische regel in een configuratie kan er als volgt uitzien:
auth required pam_unix.so
Dit instrueert PAM om de
auth interface van de pam_unix.so module te gebruiken.
2.4.3.1.1. Module interfaces stapelen
Module interface instructies kunnen gestapeld worden, of op elkaar geplaatst, zodat meerdere modules tezamen gebruikt worden voor een doel. Als de controle vlag van een module de "sufficient" of "requisite" waarde gebruikt (refereer naar Paragraaf 2.4.3.2, “Controle vlag” voor meer informatie over deze vlaggen), dan is de volgorde waarin de modules opgesomd worden belangrijk voor het autheticatie proces.
Stapelen maakt het eenvoudig voor een beheerder om te vereisen dat specifieke condities bestaan voordat een gebruiker authenticatie wordt toegestaan. Bijvoorbeeld, het
reboot commando gebruikt normaal meerdere gestapelde modules, zoals te zien is in zijn PAM configuratie bestand:
[root@MyServer ~]# cat /etc/pam.d/reboot #%PAM-1.0 auth sufficient pam_rootok.so auth required pam_console.so #auth include system-auth account required pam_permit.so
- De eerste regel is commentaar en wordt niet verwerkt.
auth sufficient pam_rootok.so— Deze regel gebruikt depam_rootok.somodule om te controleren of de huidige gebruiker root is, door het verifieren dat het UID 0 is. Als deze test succes heeft, worden geen andere modules geraadpleegd en het commando wordt uitgevoerd. Als de test faalt, dan wordt de volgende module geraadpleegd.auth required pam_console.so— Deze regel gebruikt depam_console.somodule om te proberen de gebruiker te bekrachtigen. Als deze gebruiker al ingelogd is op de console, controleertpam_console.soof er een bestand is in de/etc/security/console.apps/map met dezelfde naam als de service naam (reboot). Als zo'n bestand bestaat, slaagt authenticatie en wordt de controle doorgegeven aan de volgende module.#auth include system-auth— Deze regel is commentaar en wordt niet verwerkt.account required pam_permit.so— Deze regel gebruikt depam_permit.somodule om de root gebruiker of iedereen die ingelogd is op de console toe te staan om het systeem te rebooten.
2.4.3.2. Controle vlag
Alle PAM modules genereren een succes of een faal resultaat als ze aangeroepen worden. Controle vlaggen vertellen PAM wat met dit resultaat te doen. Modules kunnen op een bepaalde manier gestapeld worden, en de controle vlaggen bepalen hoe belangrijk het succes of falen van een bepaalde module is voor het totale doel voor de authenticatie van de gebruiker voor de service.
Er zijn vier voorgedefinieerde controle vlaggen:
required— Het resultaat van de module moet succes zijn om de authenticatie te vervolgen. Als de test op dit punt faalt, wordt dit pas bericht aan de gebruiker totdat de rsultaten van alle module testen die naar die interface refereren compleet. zijn.requisite— Het module resultaat moet succes zijn om de authenticatie te vervolgen. Als de test echter faalt op dit punt, wordt de gebruiker hiervan op de hoogte gebracht met een boodschap welke de eerste gefaalderequiredofrequisitemodule test aangeeft.sufficient— Het module resultaat wordt genegeerd als het faalt. Als echter het resultaat van een module met de vlagsufficientsucces is en er hebben geen voorgaande modules met de vlagrequiredgefaald, dan zijn er geen andere resultaten nodig en krijgt de gebruiker authenticatie voor de service.optional— Het module resultaat wordt genegeerd. Een module met de vlagoptionalwordt alleen nodig voor succescolle authenticatie als geen andere module naar de interface refereert.
Belangrijk
De volgorde waarin
required modules worden aangeroepen is niet kritisch. Alleen de sufficient en requisite controle vlaggen maken dat de volgorde belangrijk wordt.
Een nieuwere controle vlag syntax die een meer nauwkeurige controle toestaat is nu beschikbaar voor PAM
De
pam.d manual pagina en de PAM documentatie, welke zich bevindt in de /usr/share/doc/pam-<versie-nummer>/ map, waarin <versie-nummer> het versie nummer van PAM op jouw systeem is, beschrijft deze nieuwere syntax in detail.
2.4.3.3. Module naam
De module naam geeft PAM de naam van de inplugbare module die de opgegeven module interface bevat. In oudere versies van Fedora werd het volledige pad naar de module opgegeven in het PAM configuratie bestand. Echter sinds de komst van multilib systemen, die 64-bit PAM modules in de
/lib64/security/ map bewaren, wordt de map naam weggelaten omdat de toepassing gekoppeld is aan de juiste versie van libpam, welke de locatie van de juiste versie van de module kan bepalen.
2.4.3.4. Module argementen
PAM gebruikt argumenten om voor sommige modules informatie door te geven aan een inplugbare module tijdens de authenticatie
Bijvoorbeeld, de
pam_userdb.so module gebruikt informatie die bewaard wordt in een Berkeley DB bestand voor authenticatie van de gebruiker. Berkeley DB is is een open bron database systeem ingebouwd in vele toepassingen. De module neemt een db argument zodat Berkeley DB weet welke database gebruikt moet worden voor de gevraagde service.
Het volgende is een typische
pam_userdb.so regel in een PAM configuratie. De <pad-naar-bestand> is het volledige pad naar het Berkeley DB database bestand:
auth required pam_userdb.so db=<pad-naar-bestand>
Ongeldige argumenten worden in het algemeen genegeerd en beinvloeden het succes of falen van een PAM module niet. Sommige modules, echter, kunnen falen op ongeldige argumenten. De meeste modules rapporteren fouten in het
/var/log/secure bestand.
2.4.4. Voorbeeld PAM configuratie bestanden
Het volgende is een voorbeeld PAM toepassings configuratie bestand:
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_cracklib.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- De eerste regel is commentaar, aangegeven door het hash teken (
#) op het begin van de regel. - Regel twee tot en met vier stapelen drie modules voor login authenticatie.
auth required pam_securetty.so— Deze module verzekert dat als de gebruiker probeert in te loggen als root, de tty waarop de gebruiker ingelogd is vermeld wordt in het/etc/securettybestand, als dat bestand bestaat.Als de tty niet in het bestand staat, zal elke poging om in te loggen als root falen met eenLogin incorrectboodschap.auth required pam_unix.so nullok— Deze module vraagt de gebruiker om een wachtwoord en controleert dan het wachtwoord met gebruik van informatie die bewaard wordt in/etc/passwden, als deze bestaat,/etc/shadow.- Het argument
nullokinstrueert depam_unix.somodule om een leeg wachtwoord toe te staan.
auth required pam_nologin.so— Dit is de laatse authenticatie stap. Het controleert of het/etc/nologinbestand bestaat. Als het bestaat en de gebruiker is geen root, dan faalt authenticatie.Opmerking
In dit voorbeeld worden alle drieauthmodules gecontroleerd, zelfs als de eersteauthmodule faalt. Dit voorkomt dat de gebruiker weet in welke fase de authenticatie faalde. Deze kennis kan in handen van een aanvaller het gemakkelijker maken om te bepalen hoe het systeem gekraakt moet worden.account required pam_unix.so— Deze module voert de nodige account verificatie uit. Bijvoorbeeld, als schaduw wachtwoorden worden gebruikt, controleert de account interface van depam_unix.somodule of het account verlopen is en of de gebruiker het wachtwoord niet veranderd heeft binnen de toegestane grace periode.password required pam_cracklib.so retry=3— Als een wachtwoord verlopen is, vraagt de wachtwoord component van depam_cracklib.somodule om een nieuw wachtwoord. Het test daarna het nieuwe wachtwoord om te zien of het eenvoudig bepaald kan worden door een kraak programma gebaseerd op een woordenboek.- Het argument
retry=3specificeert dat als de test de eerste keer faalt, de gebruiker nog twee kansen heeft om rrn sterk wachrwoord te maken.
password required pam_unix.so shadow nullok use_authtok— Deze regel specificeert dat als het programma het wachtwoord van de gebruiker verandert, moet het depasswordinterface van depam_unix.somodule gebruiken om dit te doen.- Het argument
shadowinstrueert de module om schaduw wachtwoorden aan te maken als het wachtwoord van een gebruiker vernieuwd wordt. - Het argument
nullokinstrueert de module om de gebruiker toe te staan zijn wachtwoord te veranderen van een leeg wachtwoord, anders wordt een leeg wachtwoord behandeld als een account afsluiting. - Het laatste argument op deze regel,
use_authtok, geeft een goed voorbeeld van het belang van volgorde bij het stapelen van PAM modules. Dit argument instrueert de module om de gebruiker niet om een nieuw wachtwoord te vragen. In plaats daarvan accepteert het elk wachtwoord dat door een vorige wachtwoord module is opgenomen. Op deze manier, moeten alle nieuwe wachtwoorden depam_cracklib.sotest voor veilige wachtwoorden passeren voordat ze geaccepteerd worden.
session required pam_unix.so— De laatste regel instrueert de sessie interface van depam_unix.somodule om de sessie te beheren. Deze module logt de gebruikersnaam en het service type naar/var/log/secureaan het begin en het einde van iedere sessie. Deze module kan uitgebreid worden door het te stapelen met andere sessie modules voor extra functionaliteit.
2.4.5. PAM modules aanmaken
Je kunt ten alle tijde nieuwe PAM modules aanmaken of toevoegen voor het gebruik door toepassingen die zich bewust zijn van PAM.
Bijvoorbeeld, een ontwikkelaar kan een eenmalige-wachtwoord aanmaak methode maken en een PAM module schrijven om het te ondersteunen. Programma's die zich bewust zijn van PAM kunnen deze nieuwe module en wachtwoord methode onmiddelijk gebruiken zonder dat het opnieuw gecompileerd moet worden of anderszins veranderd.
Dit staat ontwikkelaars en systeembeheerders toe om authenticatie methodes voor verschillende programma's te mix-and-matchen, en ook te testen, zonder opnieuw te compileren.
Documentatie over het schrijven van modules is toegevoegd aan de
/usr/share/doc/pam-<versie-numner>/ map, waarin <versie-nummer> het versie nummer van PAM op je systeem is.
2.4.6. PAM en administratieve legitimatie opslag
Een aantal grafische administratieve gereedschappen in Fedora bieden gebruikers voor vijf minuten verhoogde rechten aan met gebruik van de
pam_timestamp.so module. Het is belangrijk om te begrijpen hoe dit mechanisme werkt, omdat een gebruiker die wegloopt van een terminal terwijl pam_timestamp.so effectief is de machine open laat voor manipulatie voor iedereen met fysieke toegang tot de console.
In het PAM tijdsstempel schema, vraagt de grafische administratieve toepassing als het het opgestart wordt de gebruiker naar het root wachtwoord. Als de gebruiker gemachtigd is, maakt de
pam_timestamp.so module een tijdsstempel bestand aan. Standaard wordt dit aangemaakt in de /var/run/sudo/ map. Als het tijdsstempel bestand al bestaat, vragen grafische administratieve programma's niet naar een wachtwoord. In plaats daarvan ververst de pam_timestamp.so module het tijdsstempel bestand, en reserveert eenextra vijf minuten van ongehinderde administratieve toegang.
Je kunt de actuele status van het tijdsstamp bestand verifieren door het
/var/run/sudo/<gebruiker> bestand te bekijken. Voor het bureaublad, is het relevante bestand unknown:root. Als het aanwezig is en zijn tijdstempel minder dan vijf minuten oud, zijn de legitimaties geldig.
Het bestaan van het tijdstempel bestand wordt aangegeven door een authenticatie icoon, welke verschijnt in het mededelingengebied van het paneel.
Afbeelding van de authenticatie icoon.
Figuur 2.7. De authenticatie icoon
2.4.6.1. Het tijdstempel bestand verwijderen
Voordat je een console verlaat waar een PAM tijdstempel actief is, wordt het aanbevolen dat het tijdstempel bestand vernietigd wordt. Om dit te doen in een grafische omgeving, klik je op de authenticatie icoon op het paneel. Dit laat een dialoog scherm verschijnen. Klik op de knop om de actieve tijdsstempel bestand te vernietigen.
Afbeelding van de autenticatie opzeggen dialoog
Figuur 2.8. Authenticatie opzeggen dialoog
Je moet op het volgende verdacht zijn met betrekking tit het tijdsstempel bestand:
- Als je op afstand ingelogd bent op het systeem met
ssh, gebruik je het/sbin/pam_timestamp_check -k rootcommando om het tijdsstempel bestand te vernietigen. - Je moet het
/sbin/pam_timestamp_check -k rootcommando van dezelfde terminal uitvoeren als waarvan de toepassing met extra rechten hebt opgestart. - Je moet ingelogd zijn als de gebruiker de die
pam_timestamp.somodule origineel aanriep om het/sbin/pam_timestamp_check -kcommando te gebruiken. Log niet in als de root gebruiker om dit commando te gebruiken. - Als je de legitimaties op het bureaublad wilt vernietigen (zonder de actie op het icoon te gebruiken), gebruik je het volgende commando:
/sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
Als je dit commando niet gebruikt zal alleen de legitimaties (als ze er zijn) verwijderen van de pty waarop de het commando uitvoert.
Refereer naar de
pam_timestamp_check manual pagina voor meer informatie over het vernietigen van het tijdsstempel bestand met gebruik van pam_timestamp_check.
2.4.6.2. Algemene pam_timestamp instructies
De
pam_timestamp.so module accepteert verscheidene instructies. De volgende zijn de twee meest gebruikte optios:
timestamp_timeout— Specificeert de periode (in seconden) waarvoor het tijdsstempel geldig is. De standaard waarde is 300 (vijf minuten).timestampdir— Specificeert de map waarin het tidsstempel bestand bewaard wordt. De standaard waarde is/var/run/sudo/.
Refereer naar Paragraaf 2.8.9.1, “Geinstalleerde firewall documentatie” voor meer informatie over het controleren van de
pam_timestamp.so module.
2.4.7. PAM en apparaat eigendom
In Fedora kan de eerste gebruiker die inlogt op de fysieke console van de machine bepaalde apparaten manipuleren en bepaalde taken uitvoeren die normaal voorbehouden zijn aan de root gebruiker. Dit wordt gecontroleerd door een PAM module met de naam
pam_console.so.
2.4.7.1. Apparaat eigendom
Als een gebruiker inlogt op een Fedora systeem, wordt de
pam_console.so module aangeroepen door login of de grafische login programma's, gdm, kdm, en xdm. Als deze gebruiker de eerste gebruiker is die inlogt op de fysieke console — waarnaar gerefereerd wordt als de console gebruiker — geeft de module de gebruiker het eigendom van een aantal apparaten die normaal eigendom zijn van root. De console gebruiker heeft deze apparaten in eigendom totdat de laatste sessie van die gebruiker beeindigd wordt. Nadat deze gebruiker uitgelogd is, vervalt het eigendom van de apparaten terug aan de root gebruiker.
De betroffen apparaten zijn, onder andere, geluidskaarten, schijfstations, en CD-ROM stations.
Deze voorziening staat een locale gebruiker toe om deze apparaten te manipuleren zonder root toegang, wat normale taken eenvoudiger maakt voor de console gebruiker.
Je kunt de lijst van apparaten die gecontroleerd worden door
pam_console.so veranderen door de volgende bestanden te bewerken:
/etc/security/console.perms/etc/security/console.perms.d/50-default.perms
Je kunt de permissies veranderen van andere apparaten dan die vermeld zijn in de bovengenoemde bestanden, of de opgegeven standaarden veranderen. In plaats van het veranderen van het
50-default.perms bestand, moet je een nieuw bestand aanmaken (bijvoorbeeld, xx-name.perms51-default.perms). Dit zal de standaarden in het 50-default.perms bestand overschrijven.
Waarschuwing
Als het gdm, kdm, of xdmdisplay beheerder configuratie bestand veranderd is om gebruikers op afstand toe te staan om en te loggen en de host is ingesteld om te draaien in runlevel 5, wordt het aanbevolen om de
<console> en <xconsole> instructies in /etc/security/console.perms te veranderen naar de volgende waarden:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 <xconsole>=:0\.[0-9] :0
Dit voorkomt dat gebruikers op afstand toegang krijgen tot apparaten en beperkte toepassingen op de machine.
Als het gdm, kdm, of xdm display beheerder configuratie bestand is veranderd om gebruikers op afstand toe te staan in te loggen en de host is ingesteld op een runlevel voor meerdere gebruikers anders dan 5, wordt het aanbevolen om de
<xconsole> instructie helemaal te verwijderen en de <console> instructie te veranderen naar de volgende waarde:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
2.4.7.2. Toepassing toegang
De console gebruiker heeft ook toegang tot bepaalde programma's ingesteld voor gebruik in de
/etc/security/console.apps/ map.
Deze map bevat configuratie bestanden die de console gebruiker toestaan om bepaalde toepassingen in
/sbin en /usr/sbin uit te voeren.
Deze configuratie bestanden hebben dezelfde naam als de toepassingen die ze instellen.
Een belangrijke groep van toepassingen waarnaar de console gebruiker toegang heeft zijn drie programma's die het systeem uitzetten of opnieuw opstarten.
/sbin/halt/sbin/reboot/sbin/poweroff
Omdat dit toepassingen zijn die bewust zijn van PAM, roepen zij de
pam_console.so module aan als een vereiste voor gebruik.
Refereer naar Paragraaf 2.8.9.1, “Geinstalleerde firewall documentatie” voor meer informatie
2.4.8. Extra hulpbronnen
De volgende hulpbronnen leggen meer methodes uit voor het gebruik en instellen van PAM. Naast deze hulpbronnen, lees je ook de PAM configuratie bestanden op het systeem om beter te begrijpen hoe ze opgebouwd zijn.
2.4.8.1. Geinstalleerde PAM documentatie
- Aan PAM gerelateerde manual pagina's — Verscheidene manual pagina's bestaan voor verschillende toepassingen en configuratie bestanden betrokken bij PAM. De volgende lijst laat een aantal van de meer belangrijke manual pagina's zien.
- Configuratie bestanden
pam— Goede inleidings informatie over PAM, inclusief de structuur en doel van de PAM configuratie bestanden.Merk op dat deze manual pagina zowel/etc/pam.confals individuele configuratie bestanden in de/etc/pam.d/map bespreekt. Standaard gebruikt Fedora de individuele configuratie bestanden in de/etc/pam.d/map en negeert/etc/pam.confzelfs als deze bestaat.pam_console— Beschrijft het doel van depam_console.somodule. Het beschrijft ook de juiste syntax voor een regel in een PAM configuratie bestand.console.apps— Beschrijft het formaat en de opties beschikbaar in het/etc/security/console.appsconfiguratie bestand, welke definieert welke toepassingen toege kend door PAM toegankelijk zijn voor de console gebruiker.console.perms— Beschrijft het formaat en de opties beschikbaar in het/etc/security/console.permsconfiguratie bestand, welke permissies toegekend door PAM aan de console gebruiker beschrijft.pam_timestamp— Beschrijft depam_timestamp.somodule.
/usr/share/doc/pam-— Bevat een System Administrators' Guide, een Module Writers' Manual, en de Application Developers' Manual, en ook een kopie van de PAM standaard, DCE-RFC 86.0, waarin<versie-nummer><versie-nummer>het versie nummer van PAM is./usr/share/doc/pam-— Bevat informatie over de<versie-nummer>/txts/README.pam_timestamppam_timestamp.soPAM module, waarin<versie-nummer>het versie nummer van PAM is.
2.4.8.2. Nuttige PAM websites
- http://www.kernel.org/pub/linux/libs/pam/ — De hoofd distributie website voor het Linux-PAM project, deze bevat informatie over verscheidene PAM modules, een FAQ, en extra PAM documentatie.
Opmerking
De documentatie op bovengenoemde website is voor de laatste vrijgegeven upstream versie van PAM en hoeft niet 100% correct te zijn voor de PAM versie in Fedora.
2.5. TCP wrappers en xinetd
Het controleren van toegang tot netwerk services is een van de belangrijkste beveiligings taken voor de beheerder van een server. Fedora biedt verscheidene gereedschappen voor dit doel. Bijvoorbeeld, een op
iptables gebaseerde firewall filtert netwerkpakketten uit die niet welkom zijn in de netwerk stack van de kernel. Voor netwerk services die het gebruiken, voegen TCP Wrappers een extra beschermingslaag toe door het definieren van welke hosts wel of geen verbinding kunnen maken met "wrapped" netwerk services. Een van deze wrapped netwerk services is de xinetd super server. Deze server wordt een super server genoemd omdat het de verbindingen controleert van een subset van netwerk services en toegangs controle verder verbetert.
Figuur 2.9, “Toegangs controle voor netwerk services” is een basis afbeelding die laat zien hoe deze gereedschappen samenwerken om netwerk services te beschermen.
Expositie A: Sroomschema voor toegangs controle voor netwerk services
Figuur 2.9. Toegangs controle voor netwerk services
Dit hoofdstuk richt zich op de rol van TCP wrappers en
xinetd bij het controleren van toegang tot netwerk services en bespreekt hoe deze gereedschappen gebruikt kunnen worden om zowel logging als gebruiks beheer te verbeteren. Refereer naar Paragraaf 2.9, “IPTables” voor informatie over het gebruik van firewalls met iptables.
2.5.1. TCP wrappers
Het TCP wrappers pakket (
tcp_wrappers) wordt standaard geinstalleerd en biedt op host gebaseerde toegangscontrole voor netwerk services. Het belangrijkste onderdeel van het pakket is de /usr/lib/libwrap.a bibliotheek. In het algemeen is een service gewrapt met TCP een service die gecompileerd is met de libwrap.a bibliotheek.
Als er geprobeerd wordt een verbinding te maken met een service die gewrapt is met TCP, refereert de service eerst naar de toegangsbestanden van de host (
/etc/hosts.allow en /etc/hosts.deny) om te bepalen of het de client wel of niet toegestaan is om verbinding te maken. In de meeste gevallen gebruikt het daarna de syslog daemon (syslogd) om de naam van de aanvragende client en de gewenste service naar /var/log/secure of /var/log/messages te schrijven.
Als het een client toegestaan is om te verbinden, geeft TCP wrappers de controle van de verbinding over aan de gevraagde service en neemt verder geen deel aan de communicatie tussen de client en de server.
Naast toegangscontrole en logging, kan TCP wrappers commando's uitvoeren interactief met de client voor het verbieden of het overgeven van de controle over de verbinding aan de gevraagde service.
Omdat TCP wrappers een waardevolle bijdrage geeft aan het arsenaal van gereedschappen voor elke server beheerder, zijn de meeste services van Fedora gekoppeld aan de
libwrap.a bibliotheek. Sommige van die toepassingen zijn /usr/sbin/sshd, /usr/sbin/sendmail, en /usr/sbin/xinetd.
Opmerking
Om te bepalen of een netwerk service binair gekoppeld is aan
libwrap.a, type je het volgende commando in als de root gebruiker:
ldd <binaire-naam> | grep libwrap
Vervang
<binaire-naam> met de naam van het netwerk service binaire bestand.
Als het commando direct naar de prompt terug komt zonder output, dan is de netwerk service niet gekoppeld aan
libwrap.a.
Het volgende voorbeeld geeft aan dat
/usr/sbin/sshd gekoppled is met libwrap.a:
[root@myServer ~]# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib/libwrap.so.0 (0x00655000)
[root@myServer ~]#
2.5.1.1. Voordelen van TCP wrappers
TCP wrappers bieden de volgende voordelen boven andere netwerk service controle technieken:
- Transparant voor zowel de client als de gewrapte netwerk service — Zowel de verbindende client als de gewrapte netwerk service hebben niet in de gaten dat TCP wrappers gebruikt wordt. Geldige gebruikers worden gelogd en verbonden met de gevraagde service terwijl verbindingen van verbannen clienten falen.
- Centraal beheer van meerdere protocollen — TCP wrappers werkt onafhankelijk van de netwerk service die ze beschermen, wat toestaat dat veel server toepassingen gezamelijk een aantal toegangs controle configuratie bestanden delen, wat het beheer eenvoudiger maakt.
2.5.2. Configuratie bestanden voor TCP wrappers
Om te bepalen of het een client toegestaan is met een service te verbinden, refereren TCP wrappers naar de volgende twee bestanden, gewoonlijk aangegeven als hosts toegangs bestanden:
/etc/hosts.allow/etc/hosts.deny
Als een service die gewrapt is met TCP een verzoek van een client ontvangt, voert het de volgende twee stappen uit:
- Het refereert naar
/etc/hosts.allow. — De service die gewrapt is met TCP gaat regel voor regel door het/etc/hosts.allowbestand en past de eerste regel toe die voor die service opgegeven is. Als het een overeenkomende regel vindt, dan wordt de verbinding toegestaan. Indien niet, dan gaat het verder met de volgende. - Het refereert naar
/etc/hosts.deny. — De service die gewrapt is met TCP gaat regel voor regel door het/etc/hosts.denybestand. Als het een overeenkomende regel vindt, dan wordt de verbinding verboden. Indien niet, dan wordt de toegang naar de service toegestaan.
Het volgende zijn belangrijke punten om te overwegen wanneer TCP wrappers gebruikt moeten worden om netwerk service te beschermen:
- Omdat de toegangs regels in
hosts.alloweerst toegepast worden, hebben ze voorrang boven regels opgegeven inhosts.deny. Als daarom toegang tot een service toegestaan wordt inhosts.allow, zal een regel die toegang weigert naar dezelfde service inhosts.denygenegeerd worden. - De regels in ieder bestand worden van boven naar beneden gelezen en de eerste overeenkomende regel voor een gegeven service is de enigste die toegepast wordt. De volgorde van de regels is uiterst belangrijk.
- Als in beide bestanden geen regels voor de service gevonden worden, of een of beide bestanden bestaan niet, dan wordt toegang tot de service verleend.
- Services met TCP wrappers slaan de regels van de hosts toegangs bestanden niet op, dus elke verandering in
hosts.allowofhosts.denyheeft onmiddelijk effect, zonder het opnieuw moeten starten van de netwerk services.
Waarschuwing
Als de laatste regel van een hosts toegangs bestand niet een nieuwe regel karakter is (gemaakt door te duwen op de Enter toets), zal de laatste regel van dat bestand falen en er wordt een fout gelogd in
/var/log/messages of /var/log/secure. Dit is ook het geval voor een regel die meerdere lijnen bevat zonder gebruik te maken van de backslash karakter. Het volgende voorbeeld is het relevante deel van een log boodschap voor het falen van een regel voor een van deze fouten.
warning: /etc/hosts.allow, line 20: missing newline or line too long
2.5.2.1. Tpegangs regels formatteren
Het formaat voor zowel
/etc/hosts.allow als /etc/hosts.deny is identiek. Elke regel moet op zijn eigen lijn zijn. Lege lijnen of lijnen die beginnen met een hash (#) worden genegeerd.
Elke regel gebruikt het volgende basis formaat om toegang tot netwerk service te controleren:
<daemon lijst>:<client lijst>[:<optie>:<optie>: ...]
<daemon lijst>— Een door komma's gescheiden lijst van proces namen (niet service namen) of deALLwildcard. De daemon lijst accepteert ook operatoren (refereer naar Paragraaf 2.5.2.1.4, “Operatoren”) om grotere flexibiliteit toe te staan.<client lijst>— Een door komma's gescheiden lijst van hostnamen, host IP adressen, speciale patronen, of wildcards welke de hosts identificeren voor wie de regel geldt. De client lijst accepteert ook operatoren getoond in Paragraaf 2.5.2.1.4, “Operatoren” om grotere flexibiltiet toe te staan.<optie>— Een optionele actie of een door dubbelepunten gescheiden lijst van acties die uitgevoerd worden als de regel op gang komt.
Opmerking
Meer informatie over de speciale termologie hierboven kan elders in deze gids gevonden worden:
Het volgende is een basis voorbeeld hosts toegangs regel:
vsftpd : .example.com
Deze regel instrueert de TCP wrapper om te kijken naar verbindingen naar de ftp daemon (
vsftpd) vanaf elke host in het example.com domein. Als deze regel verschijnt in hosts.allow wordt de verbinding toegestaan. Als deze regel verschijnt in hosts.deny wordt de verbinding verboden.
De volgende voorbeeld hosts toegangs regel is complexer en gebruikt twee optie velden:
sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny
Merk op dat ieder optie veld voorafgegaan wordt door de backslash (\). Het gebruik van de backslash voorkomt het falen van de regel door zijn lengte.
Deze voorbeeld regel zegt dat als er een verbinding naar de SSH daemon (
sshd) wordt geprobeert vanaf een host in het example.com domein, het echo commando wordt uitgevoerd om de poging toe te voegen aan een speciaal logbestand, en daarna de verbinding te verbieden. Omdat de optionele deny instructie wordt gebruikt, zal deze regel toegang verbieden zelfs als het verschijnt in het hosts.allow bestand. Refereer naar Paragraaf 2.5.2.2, “Optie velden” voor een meer uitgebreide beschrijving van de beschikbare opties.
2.5.2.1.1. Wildcards
Wildcards staan TCP wrappers toe om groepen van daemons of hosts eenvoudiger te kunnen vergelijken. Ze worden meestal gebruikt in het client lijst veld van toegangs regels.
De volgende wildcards zijn beschikbaar:
ALL— Komt overeen met alles. Kan gebruikt worden voor zowel de daemon lijst als de client lijst.LOCAL— Komt overeen met elke host die geen punt (.) bevat, zoals localhost.KNOWN— Komt overeen met elke host waarvan de hostnaam en hostadres bekend zijn of waar de gebruiker bekend is.UNKNOWN— Komt overeen met elke host waarvan de hostnaam of hostadres onbekend zijn of waar de gebruiker onbekend is.PARANOID— Komt overeen met elke host waarvan de hostnaam niet overeenkomt met het host adres.
Belangrijk
De
KNOWN, UNKNOWN, en PARANOID wildcards moeten zorgvuldig gebruikt worden, omdat ze bouwen op een werkende DNS server voor hun juiste werking. Elke onderbreking van naam resolutie kan legitieme gebruikers verhinderen om toegang te krijgen tot een service.
2.5.2.1.2. Patronen
Patronen kunnen gebruikt worden in het client veld van teogangs regels om nauwkeurige groepen van client hosts op te geven.
Het volgende is een lijst van algemene patronen voor het client veld:
- Hostnaam beginnend met een punt (.) — Het plaatsen van een punt aan het begin van een hostnaam komt overeen met alle hosts die de getoonde onderdelen van de naam gemeen hebben. Het volgende voorbeeld is van toepassing voor iedere host binnen het
example.comdomein:ALL : .example.com
- IP adres dat eindigt met een punt (.) — Het plaatsen van een punt aan het einde van een IP adres komt overeen met alle hosts die de eerste numerike groepen van een IP aders gemeen hebben. Het volgende voorbeeld is van toepassing voor elek host binnen het
192.168.x.xnetwerk:ALL : 192.168.
- IP adres/netmasker paar — Netmasker uitdrukkingen kunnen ook gebruikt worden als een patroon om toegang naar een specifieke groep IP adressen te controleren. Het volgende voorbeeld is van toepassing voor iedere host met een adres reeks van
192.168.0.0tot en met192.168.1.255:ALL : 192.168.0.0/255.255.254.0
Belangrijk
Als je werkt in de IP4v adres ruimte dan wordt de adres/prefix lengte (prefixlen) paar declaraties (CIDR notation) niet ondersteund. Alleen IPv6 regels gebruiken dit formaat. - [IPv6 adres]/prefixlen paar — [net]/prefixlen paren kunnen ook gebruikt worden om toegang tot een bepaalde groeps van IPv6 adressen te controleren. Het volgende voorbeeld zal van toepassing zijn voor elke host met een adres reeks van
3ffe:505:2:1::tot en met3ffe:505:2:1:ffff:ffff:ffff:ffff:ALL : [3ffe:505:2:1::]/64
- De asterisk (*) — Asteriks kunnen gebruikt worden om overeen te komen met hele groepen van hostnamen of IP adressen, zolang ze niet worden vermengd in een cleint lijst met andere patroontypes. Het volgende voorbeeld is van toepassing op elek host binnen het
example.comdomein:ALL : *.example.com
- De slash (/) — Als een client lijst begint met een slash, dan wordt het behandeld als een bestandsnaam. Dit is nuttig als het nodig is dat regels grote aantallen hosts opgeven. Het volgende voorbeeld refereert TCP wrappers naar het
/etc/telnet.hostsbestand voor aale Telnet verbindingen:in.telnetd : /etc/telnet.hosts
Andere, minder vaak gebruikte, patronen worden ook geaccepteerd door TCP wrappers. Refereer naar de
hosts_access man 5 pagina voor meer informatie.
Waarschuwing
Wees erg voorzichtig met het gebruik van hostnamen en domeinnamen. Aanvallers kunnen een groot aantal trucjes gebruiken om nauwkeurige naam resolutie te omzeilen. Bovendien zal een onderbreking van de DNS sevice gemachtigde gebruikers beletten om netwerk services te gebruiken. Het is daarom het beste om, waar mogelijk, IP adressen te gebruiken.
2.5.2.1.3. Portmap en TCP wrappers
De implementatie van TCP wrappers in
portmap ondersteunt geen host opzoeken, wat betekent dat portmap geen hostnamen kan gebruiken om hosts te identificeren. Als gevolg hiervan moeten toegangs controle regels voor portmap in hosts.allow of hosts.deny IP adressen gebruiken, of het sleutelwoord ALL voor het specificeren van hosts.
Veranderingen in
portmap toegangs controle regels hebben misschien niet meteen effect. Het kan nodig zijn om de portmap service opnieuw op te moeten starten.
Veel gebruikt services, zoals NIS en NFS, hangen af van
portmap, dus wees bedacht op deze beperkingen.
2.5.2.1.4. Operatoren
Op dit moment accepteren toegangs controle regels een operator,
EXCEPT. Het kan gebruikt worden in zowel de daemon lijst als de client lijst van een regel.
De
EXCEPT operator staat specifieke uitzonderingen toe voor brede overeenkomsten binnen dezelfde regel.
In het volgende voorbeeld uit een
hosts.allow bestand, wordt het aan alle example.com hosts toegestaan om naar alle services te verbinden behalve cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
In een ander voorbeeld uit een
hosts.allow bestand, kunnen clienten uit het 192.168.0.x netwerk alle services gebruiken behalve FTP:
ALL EXCEPT vsftpd: 192.168.0.
Opmerking
Organisatorisch is het vaak eenvoudiger om het gebruik van
EXCEPT operatoren te vermijden. Dat staat beheerders toe om snel de betreffende bestanden door te nemen om te zien welke host wel of geen toegang hebben tot services, zonder rekening hoeven te houden met de EXCEPT operatoren.
2.5.2.2. Optie velden
Naast de basis regels die toegang toestaan en verbieden ondersteunt de Fedora implementatie van TCO wrappersw ook uitbreidingen in toe toegangs controle taal met behulp van optie velden. Door optie velden in host toegangs regels te gebruiken, kunnen systeembeheerders een groot aantal taken uitvoeren, zolas het veranderen van het log gedrag, de toegangscontrole versterken, en shell commando's opstarten.
2.5.2.2.1. Logging
Optie velden laten beheerders op eenvoudige manier de log mogelijkheden en het prioriteits niveau van een regel veranderen door de
severity instructie te gebruiken.
In het volgende voorbeeld worden verbindingen naar de SSH daemon van elke host in het
example.com domein gelogd naar de standaard authpriv syslog voorziening (omdat er geen voorzienings waarde is opgegeven) met een prioriteit van emerg:
sshd : .example.com : severity emerg
Het is ook mogelijk om een voorziening op te geven met gebruik van de
severity optie. Het volgende voorbeeld logt elke SSH verbindings poging van het example.com domein naar de local0 voorziening met een prioriteit van alert:
sshd : .example.com : severity local0.alert
Opmerking
In de praktijk werkt dit voorbeeld niet totdat de syslog daemon (
syslogd) is ingesteld om te loggen naar de local0 voorziening. Refereer naar de syslog.conf manual pagina voor informatie over het instellen van aangepaste log voorzieningen.
2.5.2.2.2. Toegangs controle
Optie velden staan beheerders ook toe om hosts expliciet toe te staan of te verbieden in een enkele regel door het toevoegen van de
allow of deny instructie als de laatste optie.
Bijvoorbeeld, de volgende twwe regels laten SSH verbindingen toe van
client-1.example.com, maar verbieden verbindingen van client-2.example.com:
sshd : client-1.example.com : allow sshd : client-2.example.com : deny
Door het toestaan van toegangs contole op per-regel basis, staat het optie veld beheerders toe om alle toegangs regels te verzamelen in een enkel bestand: of
hosts.allow of hosts.deny. Sommige beheerders vinden dit een eenvoudiger manier voor het organiseren van toegangs regels.
2.5.2.2.3. Shell commando's
Optie velden staan toegangs regels toe om shell comaando's op te starten met behulp van de volgende twee instructies:
spawn— Start een shell commando op als een child proces. Deze instructie kan taken uitvoeren zoals het gebruiken van/usr/sbin/safe_fingerom meer informatie te krijgen over de client die een verbinding vraagt of het maken van speciale log bestanden met gebruik van hetechocommando.In het volgende voorbeeld worden clienten die proberen toegang te krijgen tot de Telnet services vanaf hetexample.comdomein stilletjes gelogd naar een speciaal bestand:in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allowtwist— Vervangt de gevraagde service met het opgegeven commando. Deze instructie wordt vaak gebruikt om vallen op te zetten voor indringers (ook "honing pot" genoemd). Het kan ook gebruikt worden om boodschappen naar de verbindende client te sturen. Detwistinstructie moet aan het einde van de regel lijn gebruikt worden.In het volgende voorbeeld, krijgen clienten die proberen toegang te krijgen naar FTP services vanaf hetexample.comdomein een boodschap met gebruik van hetechocommando:vsftpd : .example.com \ : twist /bin/echo "421 This domain has been black-listed. Access denied!"
Voor meer informatie over shell commando opties, refereer je naar de
hosts_options manual pagina.
2.5.2.2.4. Uitbreidingen
Uitbreidingen die tesamen met de
spawn en twist instructies gebruikt worden, bieden informatie over de client, server en de betrokken processen.
De volgende lijst laat de ondersteunde uitbreidingen zien:
%a— Geet het IP adres van de client terug.%A— Geeft het IP adres van de server terug.%c— Geeft verschillende informatie over de client terug, zoals de gebruikersnaam en hostnaam, og de gebruikersnaam en het IP adres.%d— Geeft de daemon proces naam terug.%h— Geeft de hostnaam van de client terug (of IP adres, als de hostnaam niet beschikbaar is).%H— Geeft de hostnaam van de server terug (of IP adres, als de hostnaam niet beschikbaar is).%n— Geeft de kostnaam van de client terug. Als deze niet beschikbaar is, wordtunknownafgedrukt. Als de hostnaam en het hostadres van de client niet overeenkomen, wordtparanoidafgedrukt.%N— Geeft de hostnaam van de server terug. Als deze niet beschikbaar is, wordt Als wordtunknownafgedrukt. Als de hostnaam en het hostadres van de server niet overeenkomen, wordtparanoidafgedrukt.%p— Geeft het proces ID van de daemon terug.%s— Geeft verscheidene soorten server informatie terug, zoals het daemon proces, en de host of IP adres van de server.%u— Geeft de gebruikersnaam van de client terug. Als deze niet beschikbaar is, wordtunknownafgedrukt.
De volgende voorbeeld regel gebruikt een uitbreiding tesamen met het
spawn commando om de client host te identificeren in een speciaal log bestand.
Als verbindingen naar de SSH daemon (
sshd) worden geprobeerd vanaf een host in het example.com domein, wordt het echo commando uitgevoerd om de poging te loggen, inclusief de hostnaam van de client (door de %h uitbreiding te gebruiken) naar een speciaal bestand:
sshd : .example.com \
: spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
: deny
Vergelijkbaar kunnen uitbreidingen gebruikt worden om boodschappen naar de client persoonlijk te maken. In het volgende voorbeeld, worden clienten die proberen toegang te krijgen tot FTP services vanaf het
example.com domein verteld dat ze verbannen zijn van de server:
vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!"
Voor een volledige uitleg over de beschikbare uitbreidingen, en extra toegangs controle opties, refereer je naar sectie 5 van de manual pagina's voor
hosts_access (man 5 hosts_access) en de manual pagina voor hosts_options.
Refereer naar Paragraaf 2.5.5, “Extra hulpbronnen” voor meer informatie over TCP wrappers.
2.5.3. xinetd
Het
xinetd daemon is een met TCP gewrapte super service welek toegang controleert naar een subset van populaire netwerk services, inclusief FTP, IMAP, en Telnet. Het biedt ook service specifieke configuratie opties voor toegangs controle, verbeterde logging, verbinding, omleiding, en hulpbron gebruiks controle.
Als een client probeert te verbinden met een netwerk service die gecontroleerd wordt door
xinetd, ontvangt de super service het verzoek en controleert of er TCP wrapper toegangs regels zijn.
als toegang toegestaan wordt, verifieert
xinetd dat de verbinding toegestaan is onder de de eigen toegangs regels van die service. Het controleert ook of de service meer hulpbronnen toegewezen kan krijgen en of dit niet verboden wordt door een van de aangemaakte regels.
Als aan al deze voorwaarden voldaan wordt (dat betekent, toegang naar de service is toegestaan; de service heeft zijn hulpbronnen limiet niet bereikt; en de service verbreekt geen van de opgegeven regels), dan start
xinetd een instantiering van de gevraagde service en geeft de controle over de verbinding hieraan over. Nadat de verbinding gelegd is, neemt xinetd verder geen deel aan de communicatie tussen de client en de server.
2.5.4. xinetd configuratie bestanden
De cofiguratie bestanden voor
xinetd zijn de volgende:
/etc/xinetd.conf— Het globalexinetdconfiguratie bestand./etc/xinetd.d/— De map die alle service specifieke bestanden bevat.
2.5.4.1. Het /etc/xinetd.conf bestand
Het
/etc/xinetd.conf bestand bevat algemene configuratie instellingen die effect hebben voor iedere service onder de controle van xinetd. Het wordt gelezen als de xinetd service wordt opgestart, dus om veranderingen in de configuratie effect te laten krijgen, moet je de xinetd service opnieuw opstarten. Het volgende is een voorbeeld /etc/xinetd.conf bestand:
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
Deze regels controleren de volgende aspecten van
xinetd:
instances— Specificeert het maximum aantal gelijktijdige verzoeken datxinetdkan verwerken.log_type— Steltxinetdin om deauthprivlog voorziening te gebruiken, welke log ingangen naar het/var/log/securebestand schrijft. Toevoegen van een instructie zoalsFILE /var/log/xinetdlogzal een aangepast log bestand met de naamxinetdlogaan maken in de/var/log/map.log_on_success— Steltxinetdin om succesvolle verbindingspogingen te loggen. Standaard worden het IP adres van de host op afstand en het proces ID van de server die het verzoek verwerkt opgeschreven.log_on_failure— Steltxinetdin om gefaalde verbindingspogingen of verboden verbindingen te loggencps— Steltxinetdin om niet meer dan 25 verbindingen per seconde toe te staan aan elke service. Als deze limiet wordt overschreden, wacht de service gedurende 30 seconden.includedir/etc/xinetd.d/— voegt options toe die zijn opgegeven in service specifieke configuratie bestanden in de/etc/xinetd.d/map. Refereer naar Paragraaf 2.5.4.2, “De /etc/xinetd.d/ map” vor meer informatie.
Opmerking
Vaak worden zowel de
log_on_success als de log_on_failure instellingen in /etc/xinetd.conf verder aangepast in de service specifieke configuratie bestanden. Daarom kan er meer informatie verschijnen in het log bestand van een gegeven service dan wordt aangegeven in het /etc/xinetd.conf bestand. Refereer naar Paragraaf 2.5.4.3.1, “Logging opties” voor meer informatie.
2.5.4.2. De /etc/xinetd.d/ map
De
/etc/xinetd.d/ map bevat de configuratie bestanden voor elke service die beheerd wordt door xinetd en de namen van de bestanden komen overeen met die van de service. Zoals met xinetd.conf, wordt deze map gelezen als de xinetd service wordt opgestart. Om veranderingen effect te laten hebben, moet de beheerder de xinetd service opnieuw opstarten.
Het formaat van de bestanden in de
/etc/xinetd.d/ map gebruikt dezelfde conventie als /etc/xinetd.conf. De belangrijkste reden dat de instelling voor elke service in een apart bestand wordt bewaard is om aanpassingen eenvoudiger te maken zonder effect te hebben op andere services.
Om te begrijpen hoe de structuur van deze bestanden is, beschouw je het
/etc/xinetd.d/krb5-telnet bestand:
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
disable = yes
}
Deze regels controleren verschillende aspecten van de
telnet service:
service— Specificeert de service naam, gewoonlijk een van degene opgegeven in het/etc/servicesbestand.flags— Stelt een aantal attributen in voor de verbinding.REUSEinstrueertxinetdom de socket voor een Telnet verbinding te hergebruiken.Opmerking
DeREUSEvlag is verouderd. Alle service gebruiken nu deREUSEvlag impliciet.socket_type— Stel de netwerk socket type in naarstream.wait— Specificeert of de service enkel-threaded (yes) of multi-threaded (no) is.user— Specificeert onder welk gebruikers ID het proces draait.server— Specificeert welk binaire programma uitgevoerd moet worden.log_on_failure— Specificeert logging parameters voorlog_on_failurebovenop die als ingesteld zijn inxinetd.conf.disable— Specificeert of de service uitgezet (yes) of aangezet (no) is.
Refereer naar de
xinetd.conf manual pagina voor meer informatie over deze opties en hun gebruik.
2.5.4.3. xinetd configuratie bestanden veranderen
Een aantal instructies is beschikbaar voor service de beschermd worden door
xinetd. Deze paragraaf laat een aantal veel gebruikte opties zien.
2.5.4.3.1. Logging opties
De volgende opties zijn beschikbaar voor zowel
/etc/xinetd.conf als de service specifieke bestanden in de /etc/xinetd.d/ map.
De volgende lijst laat een aantal vaak gebruikte logging opties zien:
ATTEMPT— Logt het feit dat een gefaalde poging is gedaan (log_on_failure).DURATION— Logt de tijdsduur dat de service is gebruikt door een systeem op afstand (log_on_success).EXIT— Logt de exit status of terminal signaal van de service (log_on_success).HOST— Logt het IP adres van de host op afstand (log_on_failureenlog_on_success).PID— Logt het proces ID van de server die het verzoek ontvangt (log_on_success).USERID— Logt de gebruiker op afstand met de methode gedefinieerd in RFC 1413 voor alle multi-threaded services (log_on_failureenlog_on_success).
Voor een complete lijst van alle loggings opties, refereer je naar de
xinetd.conf manual pagina.
2.5.4.3.2. Toegangs controle opties
Gebruikers van
xinetd services kunnen kiezen om de TCP wrapper host toegangsregels te gebruiken, toegangs controle te bieden met de xinetd configuratie bestanden, of een combinatie van beide. Refereer naar Paragraaf 2.5.2, “Configuratie bestanden voor TCP wrappers” voor meer informatie over TCP wrapper host toegangs controle bestanden.
Deze paragraaf bespreekt het gebruik van
xinetd om toegang tot de services te controleren.
Opmerking
In tegenstelling tot TCP wrappers, hebben veranderingen in toegangs controle pas effect als de
xinetd beheerder de xinetd service opnieuw opstart.
En ook in tegenstelling tot TCP wrappers, heeft toegangscontrole met
xinetdalleen effect voor services die gecontroleerd worden door xinetd.
De
xinetd hosts toegangs controle verschilt van de methode die gebruikt wordt met TCP wrappers. Terwijl TCP wrappers alle toegangs instellingen in twee bestanden plaatst, /etc/hosts.allow en /etc/hosts.deny, wordt de toegangs controle van xinetd gevonden in het configuratie bestand van elke service in de /etc/xinetd.d/ map.
De volgende host toegangs opties worden ondersteund door
xinetd:
only_from— Staat alleen de opgegeven hosts het gebruik van de service toe.no_access— Staat de opgegeven hosts het gebruik van de service niet toe.access_times— Specificeert het tijdsslot waarbinnen een bepaalde service gebruikt mag worden. Het tijdsslot moet in 24-uur notatie opgegeven worden, UU:MM-UU:MM.
De
only_from enno_access opties kunnen een lijst van IP adressen of hostnamen gebruiken, of kunnen een heel netwerk specificeren. Net als TCPOwrappers, kan het combineren van xinetd toegangs controle met verbeterde loggings instelling de beveiliging verbeteren door het blokkeren van verzoeken van verbannen hostes terwijl iedere verbindings poging uitvoerig opgeslagen wordt.
Bijvoorbeeld, het volgende
/etc/xinetd.d/telnet bestand kan gebruikt worden om Telnet toegang vanaf een bepaalde netwerk groep te blikkeren en het tijdsslot te beperken waarbinnen zelfs goedgekeurde gebruikers in kunnen loggen:
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/kerberos/sbin/telnetd
log_on_failure += USERID
no_access = 172.16.45.0/24
log_on_success += PID HOST EXIT
access_times = 09:45-16:15
}
Als in dit voorbeeld een client systeem van het
10.0.1.0/24 netwerk, zoals 10.0.1.2, toegang tot de Telnet service probeert te krijgen, ontvang het de volgende boodschap:
Connection closed by foreign host.
Boverndien worden hun inlog pogingen als volgt in
/var/log/messages gelogd:
Sep 7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107 Sep 7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)
Als TCP wrappers tesamen met
xinetd toegangs controle gebruikt wordt, is het belangrijk om de relatie tussen de twee toegangs controle mechanismes te begrijpen.
Het volgende is de volgorde van gebeurtenissen doorlopen door
xinetd als een client een verbinding aanvraagt:
- De
xinetddaemon krijgt toegang tot de TCP wrappers host toegangs regels met gebruik van eenlibwrap.abibliotheek aanroep. Als een weigerings regel overeenkomt met de client, wordt de verbinding verbroken. Als een toestemmings regel overeenkomt met de client, wordt de verbinding doorgegeven aanxinetd. - De
xinetddaemon controleert zijn eigen toegangs controle regels zowel voor dexinetdservice als de gevraagde service. Als een weigerings regel overeen komt met de client, wordt de verbinding verbroken. Anders startxinetdeen instantiatie van de gevraagde service op en geeft de controle over de verbinding door aan die service.
Belangrijk
Let op bij het gebruik van TCP wrappers tesamen met
xinetd toegangs regels. Een verkeerde instelling kan ongewenste effecten hebben.
2.5.4.3.3. Verbindings en omleidings opties
De service configuratie bestanden voor
xinetd ondersteunen het verbinden van de service aan een IP adres en het omleiden van binnenkomende verzoeken voor die service naar een ander IP adres, hostnaam of poort.
Verbinden wordt gecontroleerd door de
bind optie in de service specifieke configuratie bestanden en verbindt de service met het IP adres van het systeem. Als dit ingesteld is, staat de bind optie alleen verzoeken naar het juiste IP adres toe voor toegang naar de service. Je kunt deze methode gebruiken om verschillende services te verbinden met verschillende neterk interfaces gebaseerd op de vereisten.
Dit is in het bijzonder nuttig voor systemen met meerdere netwerk adapters of met meerdere IP adressen. Op zo'n systeem, kunnen onveilige services (bijvoorbeeld, Telnet) ingesteld worden om alleen te luisteren naar de interface die verbonden is met een privé netwerk en niet naar de interface die verbonden is met het Internet.
De
redirect optie accepteert een IP adres of hostnaam gevolgd door een poort nummer. Het stelt de service in om elk verzoek voor deze service om te leiden naar de opgegeven host en poort nummer. Deze eigenschap kan gebruikt worden om naar een ander poort nummer op hetzelfde systeem te wijzen, om het verzoek om te leiden naar een ander IP adres op dezelfde machine, om het verzoek te door te geven aan een totaal ander systeem en poort nummer, of elke combinatie van deze opties. Een gebruiker die verbindt met een bepaalde service op een systeem kan daarom omgeleid worden van een ander systeem zonder onderbreking.
De
xinetd daemon is in staat om deze omleiding uit te voeren door het maken van een proces dat blijft bestaan tijdens de duur van de verbinding tussen de vragende client machine en de host die de service in feite biedt, en dat de data overdracht tussen de twee systemen verzorgt
De voordelen van de
bind and redirect opties zijn het duidelijkst zichtbaar als ze tesamen worden gebruikt. Door een service te verbinden met een bepaald IP adres op een systeem en dan de verzoeken voor deze service om te leiden naar een tweede machine die alleen de eerste machine kan zien, kan een intern systeem worden gebruikt om services aan te bieden voor een totaal ander netwerk. Deze opties kunnen alternatief gebruikt worden om de zichtbaarheid te beperken van een bepaalde service op een multi-homed machine naar een bekend IP adres, en ook elk verzoek voor die service om te leiden naar een andere machine die speciaal voor dat doel is ingesteld.
Bijvoorbeeld, overweeg een systeem dat wordt gebruikt als een firewall met deze instelling voor zijn Telnet service:
service telnet
{
socket_type = stream
wait = no
server = /usr/kerberos/sbin/telnetd
log_on_success += DURATION USERID
log_on_failure += USERID
bind = 123.123.123.123
redirect = 10.0.1.13 23
}
De
bind and redirect opties in dit bestand verzekeren dat de Telnet service op de machine is verbonden met het externe IP adres (123.123.123.123), het adres dat het Internet ziet. Bovendien wordt elk verzoek voor de Telnet service die gestuurd wordt naar 123.123.123.123 omgeleid met een tweede netwerk adapter naar een intern IP adres (10.0.1.13) dat alleen toegang heeft to de firewall en interne systemen. De firewall bestuurt dan communicatie tussen de twee systemen, en het verbindende systeem denkt dat het verbonden is met 123.123.123.123 terwijl het in werkelijkheid met een ander systeem verbonden is.
Deze eigenschap is in het bijzonder nuttig voor gebruikers met breedband verbindingen en slechts een vast IP adres. Als Network Address Translation (NAT) gebruikt wordt, zijn de systemen achter de gateway machine, welke alleen interne IP adressen gebruiken, niet beschikbaar buiten het gateway systeem. Als echter bepaalde services gecontroleerd door
xinetd ingesteld zijn met de bind en redirect opties, kan de gateway machine als een proxy functioneren tussen de systemen buiten en een bepaalde interne machine ingesteld om de service te verlenen. Bovendien zijn de verschillende xinetd toegangs controle en loggings opties ook beschikbaar voor extra bescherming.
2.5.4.3.4. Hulpbronnen beheer opties
De
xinetd daemon kan een basis niveau van bescherming bieden voor weigering van dienst (DoS) aanvallen. De instructies van de volgende lijst kunnen helpen om de effectiviteit van zo'n aanval te beperken:
per_source— Definieert het maximum aantal instantiaties van een service per bron IP adres. Het accepteert alleen gehele getallen als argument en kan gebruikt worden in zowelxinetd.confals de configuratie bestanden specifiek voor een service in dexinetd.d/map.cps— Definieert het maximum aantal verbindingen per seconde. Deze instructie heeft twee gehele getallen als argument gescheiden door spaties. Het eerste argument is het maximum aantal verbindingen oer seconde toegestaan voor de service. Het tweede argument is het aantal secondes datxinetdmoet wachten voor dat de service weer beschikbaar komt. Het accepteert alleen gehele getallen als argument en kan gebruikt worden in zowelxinetd.confals de configuratie bestanden specifiek voor een service in dexinetd.d/map.max_load— Definieert het CPU gebruik of gemiddelde load drempel voor een service. Het accepteert een drijvendekommagetal als argument.De gemiddelde load is een ruwe maatstaf voor het aantal processen dat op een gegeven moment actief is. Zie deuptime,who, enprocinfocommando's voor meer informatie over gemiddelde load.
Er zijn meer hulpbron beheer opties beschikbaar voor
xinetd. Refereer naar de xinetd.conf manual pagina voor meer informatie.
2.5.5. Extra hulpbronnen
Meer informatie over TCP wrappers en
xinetd is beschikbaar in de systeem documentatie en op het Internet.
2.5.5.1. Geinstalleerde TCP wrapper documentatie
De documentatie op je systeem is een goede plek om te beginnen voor het zoeken naar extra configuratie opties voor TCP wrappers,
xinetd, en toegangs controle.
/usr/share/doc/tcp_wrappers-— Deze map bevat een<versie>/READMEbestand dat uitlegt hoe TCP wrappers werken en bespreekt de verschillende hostnaam en hostadres voor de gek houden risico's./usr/share/doc/xinetd-— Deze map bevat een<versie>/READMEbestand dat de verschillende aspecten van toegangs controle bespreekt en eensample.confbestand met verschillende ideetjes voor het veranderen van service specifieke configuratie bestanden in de/etc/xinetd.d/map.- TCP Wrappers en
xinetdgerelateerde manual pagina's — Er bestaan een aantal manual pagina's voor de verschillende toepassingen en configuratie bestonden betrokken bij TCP wrappers enxinetd. De volgende zijn de belangrijkste:- Server toepassingen
man xinetd— De manual pagina voorxinetd.
- Configuratie bestanden
man 5 hosts_access— De manual pagina voor de TCP wrapper hosts toegangscontrole bestanden.man hosts_options— De manual pagina voor de optie velden van TCP wrappers.man xinetd.conf— De manual pagina die de configuratie opties vanxinetdlaat zien.
2.5.5.2. Nuttige TCP wrapper websites
- http://www.xinetd.org/ — De thuisbasis van
xinetd, welke voorbeeld configuratie bestanden bevat, een volledige lijst van eigenschappen, en een informatieve FAQ. - http://www.docstoc.com/docs/2133633/An-Unofficial-Xinetd-Tutorial — Een gedegen handleiding die verschillende manieren bespreekt om standaard
xinetdconfiguratie bestanden te optimaliseren voor het bereiken van specifieke beveiligings doelen .
2.5.5.3. Gerelateerde boeken
- Hacking Linux Exposed door Brian Hatch, James Lee, en George Kurtz; Osbourne/McGraw-Hill — Een uitstekende beveiligings hulpbron met informatie over TCP wrappers en
xinetd.
2.6. Kerberos
Systeem beveiliging en integriteit binnen een netwerk kan onhandelbaar zijn. Het kan verschillende beheerders bezighouden om alleen maar in de gaten te houden welke services op een netwerk draaien en hoe deze services gebruikt worden.
Verder kan het authenticeren van gebruikers voor netwerk services gevaarlijk blijken als de methode gebruikt in het protocol inherent onveilig is, zoals aangetoond wordt door het versturen van onversleutelde wachtwoorden over een netwerk met FTP en Telent protocollen.
Kerberos is een manier om de noodzaak voor protocollen die onveilige authenticatie methodes toestaan te elimineren, en op die manier de netwerk beveiliging verbeteren.
2.6.1. Wat is Kerberos?
Kerberos is een netwerk authenticatie protocol gemaakt door MIT, wat symmetrische sleutel cryptografie[14] gebruikt om gebruikers te authenticeren voor netwerk services, wat betekent dat wachtwoorden nooit echt over het netwerk verstuurd worden.
Als gevolg hiervan zullen gebruikers die authenticeren voor netwerk services met gebruik van Kerberos, ongeoorloofde gebruikers die proberen wachtwoorden te verzamelen door het bekijken van het netwerk verkeer effectief dwarsbomen.
2.6.1.1. Voordelen van Kerberos
De meeste conventionele netwerk services gebruiken een op wachtwoorden gebaseerd authenticatie schema. Zulke schema's vereisen dat een gebruiker zich authentiseert bij een bepaalde service door een gebruikersnaam en wachtwoord op te geven. Helaas gebeurt het versturen van deze authenticatie informatie voor veel services onversleuteld. Om zo'n schema veilig te laten zijn, moet het netwerk ontoegankelijk voor buitenstaanders zijn, en moeten alle computers en gebruikers op het netwerk vertrouwd en betrouwbaar zijn.
Zelfs als dit het geval is, kan een netwerk dat verbonden is met het Internet niet langer als veilig verondersteld worden. Elke aanvaller die toegang krijgt tot het netwerk kan een eenvoudig pakket analyse programma, ook bekend als pakket snuffelaar, gebruiken om gebruikersnamen en wachtwoorden te onderscheppen, en gebruikersaccounts en de integriteit van de gehele beveiligings infrastructuur in gevaar brengen.
Het belangrijkste ontwerp doel van Kerberos is om het versturen van onversleutelde wachtwoorden over het netwerk te elimineren. Als het juist gebruikt wordt, zal Kerberos de bedreiging, die pakket suffelaars anders op een netwerk zijn, effectief te elimineren.
2.6.1.2. Nadelen van Kerberos
Hoewel Kerberos een algemene en ernstige beveiligings bedreiging verwijdert, kan het om een aantal redenen moeilijk te implementeren zijn:
- Het verhuizen van gebruikers wachtwoorden van een standaard UNIX wachtwoorden database, zoals
/etc/passwdof/etc/shadow, naar een Kerberos wachtwoord database kan vervelend zijn, omdat er geen geautomatiseerd mechanisme is om deze taak uit te voeren. Refereer naar Vraag 2.23 in de online Kerberos FAQ: - Kerberos is slechts gedeeltelijk compatibel met het Pluggable Authentication Modules (PAM) systeem die door de meeste Fedora servers gebruikt wordt. Refereer naar Paragraaf 2.6.4, “Kerberos en PAM” voor meer informatie over dit probleem.
- Kerberos neemt aan dat elke gebruiker vertrouwd is, maar dat deze een onvertrouwde host op een onvertrouwd netwerk gebruikt. Zijn belangrijkste doel is om te voorkomen dat onversleutelde wachtwoorden over dat netwerk verstuurd worden. Als echter iemand anders dan de werkelijke gebruiker toegang heeft tot de host die kaartjes voor authenticatie uitgeeft — het sleutel distributie centrum (KDC) genaamd — is het hele Kerberos authenticatie systeem in gevaar.
- Om een toepassing Kerberos te laten gebruiken, moet zijn broncode veranderd worden om de juiste aanroepen naar de Kerberos bibliotheken te maken. Toepassingen die op deze manier veranderd zijn worden bewust van Kerberos, of kerberized genoemd. Voor sommige toepassingen kan dit een heel probleem zijn door de grootte van de toepassing of zijn ontwerp. Voor andere niet-compatibele toepassingen moeten veranderingen gemaakt worden in de manier waarop de server en client communiceren. Dit kan nogal wat werk zijn. Gesloten bron toepassingen die standaard geen Kerberos ondersteuning hebben zijn vaak de meest problematische.
- Kerberos is een alles of niets oplossing. Als Kerberos op het netwerk gebruikt wordt, is elk onversleuteld wachtwoord verstuurd naar een service die zich niet bewust is van Kerberos een gevaar. Dus het netwerk heeft geen voordeel van het gebruik van Kerberos. Om een netwerk met Kerberos te beveiligen, moet men of zich van Kerberos bewuste versies van alle client/server toepassingen die wachtwoorden onverslueteld versturen gebruiken, of geen enkele van zulke client/server toepassingen gebruiken.
2.6.2. Kerberos terminologie
Kerberos heeft zijn eigen terminologie om verschillende aspecten van de service te definiëren. Voordat je leert hoe Kerberos werkt, is het belangrijk om de volgende vaktermen te leren.
- authenticatie server (AS)
- Een server die kaartjes uitgeeft voor een gewenste service die op hun beurt gegeven worden aan gebruikers voor toegang tot de service. De AS beantwoordt verzoeken van clienten die geen legitimatie hebben of niet hebben verstuurd met een verzoek. Het wordt gewoonlijk gebruikt om toegang te krijgen tot de kaartjes uitgevende server (TGS) service door het uitgeven van een kaartjes-gerechtigde kaartje (TGT). De AS draait gewoonlijk op dezelfde host als het sleutel verdelings centrum (KDC).
- ciphertext
- Versleutelde data
- client
- Een eenheid op het netwerk (een gebruiker, een host, of een toepassing) die een kaarje van Kerberos kan ontvangen.
- legitimatiebewijs
- Een tijdelijke set van electronische legitimatie die de identiteit van een gebruiker voor een bepaalde service verifieert. Ook een kaartje genoemd.
- legitimatie opslag of kaartjes bestand
- Een bestand dat de sleutels bevat voor het versleutelen van de communicatie tussen een gebruiker en verscheidene netwerk services. Kerberos 5 ondersteunt een raamwerk voor het gebruik van andere opslag types, zoals gedeeld geheugen, maar bestanden worden meer uitgebreid ondersteund.
- crypt hash
- Een eenrichtings hash gebruikt om gebruikers te authenticeren. Deze zijn veiliger dan het gebruik van niet-versleutelde data, maar ze zijn relatief eenvoudig te ontsleutelen voor een ervaren cracker.
- GSS-API
- De Generic Security Service Application Program Interface (gedefinieerd in RFC-2743 uitgegeven door The Internet Engineering Task Force) is een set functies die beveiligings services bieden. Deze API wordt gebruikt door clienten en ervices om elkaar te authenticeren zonder dat een van de programma's specifieke kennis heeft van het onderliggende mechanisme. Als een netwerk service (zoals cyrus-IMAP) GSS-API gebruikt, kan het Kerberos gebruiken voor authenticatie.
- hash
- Ook bekent als een hash waarde. Een waarde gemaakt door op opgeven van een reeks karakters aan een hash functie. Deze waarden worden gewoonlijk gebruikt om de verzekeren van de verstuurde data niet gemanipuleerd is.
- hash functie
- Een manier om een digitale "vingerafdruk" van input data te maken. Deze functie, herrangschikken, transponeren of veranderen data op een andere manier om een hash waarde te maken.
- sleutel
- Data gebruikt om adere date te versleutelen of ontsleutelen. Versleutelde data kan niet ontsleuteld worden zonder de juiste sleutel of met uitzonderlijk goed geluk door de cracker.
- sleutel distributie centrum (KDC)
- Een service die Kerberos kaartjes uitgeeft, en die gewoonlijk op dezelfde host draait als de kaartjes-verlenende server (TGS)
- sleuteltab (of sleutel tabel)
- Een bestand dat een niet-versleutelde lijst van hoofdrolspelers en hun sleutels bevat. Servers halen de sleutel die ze nodig hebben van de sleuteltab bestanden in plaats van
kinitte gebruiken. Het standaard sleuteltab bestand is/etc/krb5.keytab. De KDC beheer server,/usr/kerberos/sbin/kadmind, is de enigste service die een ander bestand gebruikt (het gebruikt/var/kerberos/krb5kdc/kadm5.keytab). - kinit
- Het
kinitcommando laat een hoofdrolspeler die al ingelogd is het initiële kaartjes-verlenende kaarjte (TGT) verkrijgen en opslaan. - hoofdrolspeler (of hoofdrolspeler naam)
- De hoofdrolspeler is de unieke naam van een gebruiker of service die toegestaan is om Kerberos te gebruiken voor authenticatie. Een hoofdrolspeler volgt de vorm
root[/instance]@REALM. Voor een typische gebruiker, is de root gelijk aan hun login ID. Deinstanceis optioneel. Als de hoofdrolspeler een instance heeft, is het gescheiden van de root met een slash ("/"). Een lege string ("") wordt als een geldige instance beschouwd (welke verschilt van de standaardNULLinstance), maar het gebruiken kan verwarrend zijn. Alle hoofdrolspelers in een gebied hebben hun eigen sleutel, welke voor gebruikers is afgeleid van een wachtwoord of willekeurig is ingesteld voor services. - gebied
- Een netwerk dat Kerberos gebruikt, bestaande uit een of meer servers, KDC's genaamd, en een potentieel grote groep clienten.
- service
- Een programma waarnaar over het netwerk toegang wordt verkregen.
- kaartje
- Een tijdelijke set van electrische legitimatie die de identiteit van een client voor een bepaalde service verifieert. Ook legitimatiebewijs genaamd.
- kaartje-verlenende server (TGS)
- Een server die kaartjes uitgeeft voor een gewenste service welke op zijn beurt gebruikers toegang geeft tot de service. De TGS draait gewoonlijk op dezelfde host als de KDC.
- kaartjes-verlenende kaartje (TGT)
- Een speciaal kaartje dat de client toestaat om extra kaartjes te verkrijgen zonder ze aan te hoeven vragen bij de KDC.
- onversleuteld wachtwoord
- Een leesbare tekst wachtwoord
2.6.3. Hoe werkt Kerberos
Kerberos verschilt van de gebruikersnaam/wachtwoord authenticatie methodes. In plaats van het authenticeren van elke gebruiker voor elke netwerk service, gebruikt Kerberos symmetrische versleuteling en een vertrouwde derde partij (een KDC), om gebruikers te authenticeren voor een aantal netwerk services. Als een gebruiker authenticeert naar de KDC, stuurt de KDC een kaartje specifiek voor die sessie terug naar de machine van de gebruiker, en elke service bewust van Kerberos kijkt naar het kaartje op de machine van de gebruiker in plaats van het vragen aan de gebruiker om authentiek verklaard te worden met gebruik van een wachtwoord.
Als een gebruiker op een netwerk dat zich bewust is van Kerberos inlogt op zijn werkstation, wordt zijn hoofdrolspeler opgestuurd naar de KDC als onderdeel van een verzoek voor een TGT van de Authenticatie server. Dit verzoek kan verstuurd worden het login programma zodat het transparant is voor de gebruiker, of het kan verzonden worden door het
kinit programma nadat de gebruiker heeft ingelogd.
De KDC controleert daarna voor de hoofdrolspeler in zijn database. Als de hoofdrolspeler wordt gevonden, maakt de KDC een TGT, die versleuteld wordt met de sleutel van de gebruiker en teruggestuurd naar die gebruiker.
Het login of
kinit programma op de client ontsleuteld daarna de TGT met gebruik van de sleutel van de gebruiker, welke berekend wordt van het wachtwoord van de gebruiker. De sleutel van de gebruiker wordt alleen op de client machine gebruikt en wordt niet over het netwerk verstuurd.
De TGT wordt ingesteld om te verlopen na een zekere tijdsperiode (gewoonlijk tien tot vierentwintig uur) en wordt bewaard in de legitimatie opslag van de client machine. Een verloop tijd wordt ingesteld zodat een in gevaar gebrachte TGT slechts korte tijd door een aanvaller gebruikt kan worden. Nadat de TGT is uitgegeven, hoeft de gebruiker zijn wachtwoord niet meer op te geven totdat de TGT verloopt of totdat de gebruiker uitlogt en opnieuw inlogt.
Iedere keer dat een gebruiker toegang nodig heeft tot een netwerk service, gebruikt de client software de TGT om een nieuw kaartje voor die specifieke service aan de TGS. Het service kaartje wordt daarna gebruikt om de gebruiker transparant voor authentiek te verklaren voor die service.
Waarschuwing
Het Kerberos systeem kan in gevaar worden gebracht als een gebruiker op het netwerk authenticieert bij een service die niet bewust is van Kerberos door een wachtwoord in leesbare tekst te versturen. Het gebruik van services niet bewust van Kerberos wordt ten sterkste ontraden. Zulke services zijn Telnet en FTP. Het gebruik van andere versleutelde protocollen, zoals SSH of SSL beveiligde services heeft de voorkeur, maar dit is niet ideaal.
Dit is slechts een algemeen overzicht over de werking van Kerberos authenticatie. Refereer naar Paragraaf 2.6.10, “Extra hulpbronnen” voor meer detail informatie.
Opmerking
Kerberos is afhankelijk van de juiste werking van de volgende netwerk services.
- Bij benadering tijdssynchronisatie tussen de machines op het netwerk.Een tijdssynchronisatie programma moet ingesteld worden voor het netwerk, zoals
ntpd. Refereer naar/usr/share/doc/ntp-voor meer informatie over het instellen van Network Time Protocol servers (waarin<versie-nummer>/index.html<versie-nummer>het versie nummer is van hetntppakket geinstalleerd op je systeem). - Domain Name Service (DNS).Je moet er zeker van zijn dat de DNS regels en hosts in het netwerk juist ingesteld zijn. Refereer naar Kerberos V5 System Administrator's Guide in
/usr/share/doc/krb5-server-voor meer informatie (waarin<versie-nummer><versie-nummer>het versie nummer is van hetkrb5-serverpakket geinstalleerd op jouw systeem.
2.6.4. Kerberos en PAM
Services die zich bewust zijn van Kerberos maken op dit moment geen gebruik van Pluggable Authentication Modules (PAM) — deze services mijden PAM helemaal. Toepassingen die echter PAM gebruiken kunnen gebruik maken van Kerberos voor authenticatie als de
pam_krb5 module (geleverd in het pam_krb5 pakket) geinstalleerd is. Het pam_krb5 pakket bevat voorbeeld configuratie bestanden die services zoals login en gdm toestaan om gebruikers te authenticeren en ook om initiële legitimatie te verkrijgen met gebruik van hun wachtwoord. Als toegang tot netwerk services altijd wordt uitgevoerd met service die zich bewust zijn van Kerberos of services die GSS-API gebruiken zoals IMAP, kan het netwerk als redelijk veilig beschouwd worden.
Belangrijk
Beheerders moet er op letten om gebruikers niet toe te staan om authenticatie uit te voeren voor de meeste netwerk services met gebruik van Kerberos wachtwoorden. Vele protocollen versleutelen hun wachtwoorden niet voordat ze over het netwerk verzonden worden, wat de voordelen van het Kerberos systeem vernietigd. Bijvoorbeeld, gebruikers moeten niet toegestaan worden om authenticatie uit te voeren voor Telnet met hetzelfde wachtwoord dat ze voor Kerberos gebruiken.
2.6.5. Het instellen van een Kerberos 5 server
Als Kerberos ingesteld wordt, installeer dan de KDC eerst. Als het nodig is om slaaf servers in te stellen, installeer dan de meester eerst.
Om de eerste Kerberos KDC in te stellen, volg je deze stappen op:
- Verzeker je ervan dat tijdssynchronisatie en DNS correct werken op alle client en server machines voor het instellen van Kerberos. Geef in het bijzonder aandacht aan de tijdssynchronisatie tussen de Kerberos server en zijn clienten. Als het tijdsverschil tussen de server en zijn clienten groter is dan vijf minuten (dit is instelbaar in Kerberos 5) kunnen Kerberos clienten geen authenticatie krijgen van de server. Deze tijdssynchronisatie is nodig om een aanvaller te beletten om een oud Kerberos kaartje te gebruiken om zich de vermommen als een geldige gebruiker.Het wordt aanbevolen om een Network Time Protocol (NTP) compatibel client/netwerk in te stellen zelfs als Kerberos niet wordt gebruikt. Fedora bevat het
ntppakket voor dit doel. Refereer naar/usr/share/doc/ntp-(waarin<versie-nummer>/index.html<versie-nummer>het versie nummer is van hetntppakket geinstalleerd op je systeem) voor details over het instellen van Network Time Protocol servers, en http://www.ntp.org voor meer informatie over NTP. - Installeer de
krb5-libs,krb5-server, enkrb5-workstationpakketten op de specifieke computer die de KDC draait. Deze machine moet goed beveiligd zijn — indien mogelijk moet het geen andere services draaien dan de KDC. - Bewerk de
/etc/krb5.confen/var/kerberos/krb5kdc/kdc.confconfiguratie bestanden om de gebiedsnaam en de domein naar gebied afbeelding weer te geven. Een eenvoudig gebied kan gemaakt worden door het vervangen van instantiaties vanEXAMPLE.COMenexample.commet de correcte domein naam — let er op om de hoofd en kleine letter namen in het juiste formaat te houden — en door het veranderen van de KDC vankerberos.example.comnaar de naam van de Kerberos server. Bij conventie zijn alle gebiedsnamen in hoofsletters en alle DNS hostnamen en domeinnamen in kleine letters. Voor volledige details over het formaat van deze configuratie bestanden, refereer je naar hun respectievelijke manual pagina's. - Maak de database met gebruik van het
kdb5_utilprogramma vanaf een shell prompt:/usr/kerberos/sbin/kdb5_util create -s
Hetcreatecommando maakt de database dat de sleutels voor het Kerberos gebied bewaart. De-sschakelaar forceert het aanmaken van een stash bestand waarin de meester server sleutel bewaard wordt. Als er geen stash bestand aanwezig is om de sleutel van te lezen, vraagt de Kerberos server (krb5kdc) de gebruiker naar het meester server wachtwoord (welek gebruikt kan worden om de sleutel te genereren) iedere keer als het opstart. - Bewerk het
/var/kerberos/krb5kdc/kadm5.aclbestand. Dit bestand wordt gebruikt doorkadmindom te bepalen welke hoofrolspelers beheerstoegang hebben tot de Kerberos database en hun niveau van toegang. De meeste organisaties kunnen volstaan met een enkele regel:*/admin@EXAMPLE.COM *
De meeste gebruikers worden in de database gerepresenteerd door een enkele hoofdrolspeler (met een NULL, of lege, instance, zoals joe@EXAMPLE.COM). In deze configuratie zijn gebruikers met een tweede hoofdrolspeler met een instance van admin (bijvoorbeeld, joe/admin@EXAMPLE.COM) in staat om volledige macht over de Kerberos database van het gebied uit te voeren.Nadatkadmindis opgestart op de server, kan elke gebruiker toegang krijgen tot zijn services door het uitvoeren vankadminop een van de clienten of servers in het gebied. Echter alleen gebruikers opgegeven in hetkadm5.aclbestand kunnen de database op enige manier veranderen, behalve voor het veranderen van hun eigen wachtwoorden.Opmerking
Hetkadminprogramma communiceert met dekadmindserver over het netwerk, en gebruikt Kerberos om authenticatie af te handelen. Als gevolg hiervan moet de eerste hoofdrolspeler al bestaan voordat het met de server kan verbinden over het netwerk om het te beheren. Maak de eerste hoofdrolspeler met hetkadmin.localcommando, welke specifiek is ontworpen om gebruikt te worden op dezelfde host als de KDC en Kerberos niet gebruikt voor authenticatie.Type het volgendekadmin.localcommando op de KDC termial om de eerste hoofdrolspeler aan te maken:/usr/kerberos/sbin/kadmin.local -q "addprinc
username/admin" - Start Kerberos met de volgende commando's:
/sbin/service krb5kdc start /sbin/service kadmin start /sbin/service krb524 start
- Voeg hoofdrolspelers toe voor de gebruikers met het
addprinccommando inkadmin.kadminenkadmin.localzijn commandoregel interfaces voor de KDC. Daarom zijn vele commando's — zoalsaddprinc— beschikbaar na het opstarten van hetkadminprogramma. Refereer naar dekadminmanual pagina voor meer informatie. - Verifieer dat de KDC kaartjes uitgeeft. Voer eerst
kinituit om een kaartje te krijgen en het te bewaren in het legitimatie opslag bestand. Vervolgens gebruik jeklistom de lijst van legitimaties in de opslag te zien en gebruik jekdestroyom de opslag en de legitimatie die het bevat te vernietigen.Opmerking
Standaard probeertkinitauthenticatie uit te voeren met dezelfde systeem login gebruikersnaam (niet de Kerberos server). Als die gebruikersnaam niet overeenkomt met een hoofdrolspeler in de Kerberos database, geeftkiniteen fout boodschap. Als dat gebeurt, geeft jekinitde naam van de juiste hoofdrolspeler mee als argument op de commandoregel (kinit).<hoofdrolspeler>
Zodra deze stappen klaar zijn, moet de Kerberos server klaar zijn en draaien.
2.6.6. Het instellen van een Kerberos 5 client
Het instellen van een Kerberos 5 client is eenvoudiger dan het instellen van de server. Als een minimum installeer je de client pakketten en geef je iedere client een geldig
krb5.conf configuratie bestand. Terwijl ssh en slogin de voorkeurs mthodes zijn om in te loggen op client systemen, zijn kerberized versies van rsh en rlogin nog steeds beschikbaar, hoewel het gebruik hiervan vereist dat nog een aantal extra configuratie veranderingen gemaakt worden.
- Wees er zeker van dat tijdssynchronisatie aanwezig is tussen de Kerberos client en de KDC. Refereer naar Paragraaf 2.6.5, “Het instellen van een Kerberos 5 server” voor meer informatie. Verifieer bovendien dat DNS correct werkt op de Kerberos client voordat je de Kerberos client programma's instelt.
- Installeer de
krb5-libsenkrb5-workstationpakketten op alle client machines. Maak een geldig/etc/krb5.confbestand voor iedere client (gewoonlijk kan dit hetzelfdekrb5.confbestand zijn gebruikt door de KDC). - Voordat een werkstation in het gebied Kerberos kan gebruiken voor authenticatie van gebruikers die verbinden met
sshof kerberizedrshofrlogin, moet het zijn eigen hoofdrolspeler hebben in de Kerberos database. Desshd,kshd, enklogindserver programma's hebben allemaal toegang nodig tot de sleutels voor de host service van de hoofdrolspeler. Bovendien moet het werkstation, om de kerberizedrshenrloginservices te gebruiken, hetxinetdpakket geinstalleerd hebben.Met gebruik vankadminvoeg je een host hoofdrolspeler toe voor het werkstation op de KDC. De instance is in dit geval de hostnaam van het werkstation. Gebruik de-randkeyoptie voor hetaddprinccommando van dekadminom de hoofdrolspeler aan te maken en ken het een wiilekeurige sleutel toe:addprinc -randkey host/
blah.example.comNu de hoofdrolspeler is aangemaakt, kunnen sleutels bepaald worden voor het werkstation door het uitvoeren vankadminop het workstation zelf, en het gebruik van hetktaddcommando binnenkadmin:ktadd -k /etc/krb5.keytab host/
blah.example.com - Om andere kerberized netwerk services re gebruiken, moeten ze eerst gestart worden. Hieronder is een lijst van enkele algemene kerberized services en instructies over het aanzetten:
ssh— OpenSSH gebruikt GSS-API voor authenticatie van gebruikers voor servers als de configuratie bestanden van zowel de client als de server beideGSSAPIAuthenticationaangezet hebben. Als de client ookGSSAPIDelegateCredentialsaangezet heeft, wordt de legitimatie van de gebruiker beschikbaar gemaakt op het systeem op afstand.rshenrlogin— Om kerberized versies vanrshenrloginte gebruiken, zet jeklogin,eklogin, enkshellaan.- Telnet — Om kerberized Telnet te gebruiken, moet
krb5-telnetaangezet worden. - FTP — Om FTP toegang te geven, bepaal je een sleutel voor de hoofdrolspeler met een root
ftp. Wees er zeker van om de instance in te stellen naar de volledig gekwalificeerde hostnaam van de FTP serverm en zet dangssftpaan. - IMAP — Om een kerberized IMAP server te gebruiken, gebruikt het
cyrus-imappakket Kerberos 5 als ook hetcyrus-sasl-gssapipakket geinstalleerd is. Hetcyrus-sasl-gssapipakket bevat de Cyrus SASL plugins welke GSS-API authenticatie ondersteunen. Cyrus IMAP moet correct werken met Kerberos zo lang decyrusgebruiker in staat is om de juiste sleutel in/etc/krb5.keytabte vinden, en de root voor de hoofdrolspeler in ingesteld naarimap(aangemaakt metkadmin).Een alternatief voorcyrus-imapkan gevonden worden in hetdovecotpakket, welke ook toegevoegd is aan Fedora. Dit pakket bevat een IMAP server die, op dit moment GSS-API en Kerberos niet ondersteund. - CVS — Om een kerberized CVS server te gebruiken, gebruikt
gservereen hoofdrolspeler met een rootcvsen is anders identiek aan depserver.
2.6.7. Domein naar gebied afbeelding
Als een client probeert om toegang te krijgen tot een service die op een bepaalde server draait, weet het de naam van de service (host) en de naam van de server (foo.example.com), maar omdat er meer dan een gebieden in je netwerk kunnen zijn, moet het raden naar de naam van het gebied waarin de server zich bevindt.
Standaard wordt aangenomen dat de naam van het gebied de DNS naam van de server is in hoofdletters.
foo.example.org → EXAMPLE.ORG
foo.example.com → EXAMPLE.COM
foo.hq.example.com → HQ.EXAMPLE.COM
In sommige configuraties zal dit voldoende zijn, maar in andere zal de gebiedsnaam die zo afgeleid wordt, de naam van een niet bestaand gebied zijn. In die gevallen moet de afbeelding van de DNS domeinnaam van de server naar de naam van zijn gebied opgegeven worden in de domain_realm sectie van het
krb5.conf bestand op het client systeem. Bijvoorbeeld:
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
De bovenstaande instelling geeft twee afbeeldingen op. De eerste afbeelding specificeert dat elk systeem in het "example.com" DNS domein onderdeel is van het EXAMPLE.COM gebied. De tweede specificeert dat een systeem met de exacte naam "example.com" ook onderdeel van het gebied is. (Het verschil tussen een domein en een specifieke host wordt aangegeven door de aanwezigheid of ontbreken van de eerste ".".) De afbeelding kan ook direct in DNS opgeslagen worden.
2.6.8. Instellen van secundaire KDC's
Om een aantal redenen kun je er voor kiezen om meerdere KDC's te draaien in een bepaald gebied. In dit scenario bewaart een KDC (de meester KDC) een schrijfbare kopie van de gebieds database en draait
kadmind (het is ook de admin server voor jouw gebied), en een of meer KDC's (slaaf KDC's) bewaren alleen-lezen kopieën van de database en draaien kpropd.
De meester-slaaf overdrachtsprocedure houdt in dat de meester KDC zijn database dumpt in een tijdelijk dump bestand en dat bestand dan overbrengt naar iedere slaaf., welke daarna zijn vorig ontvangen alleen-lezen kopieën van de database overschrijft met de inhoud van het dump bestand.
Om een slaaf KDC in te srellen, wees er dan eerst zeker van om de
krb5.conf en kdc.conf bestanden van de meester KDC te kopiëren naar de slaaf KDC.
Start
kadmin.local op in een root shell op de meester KDC en gebruik zijn add_principal commando om een nieuwe regel aan te maken voor de host service van de meester KDC, en gebruik daarna zijn ktadd commando om gelijktijdig een willekeurige sleutel voor de service in te stellen en die sleutel op te slaan in het standaard keytab bestand van de meester. Deze sleutel zal door het kprop commando gebruikt worden voor authenticatie naar de slaaf servers. Je hoeft dit maar een keer te doen, onafhankelijk van hoeveel slaaf servers je installeert.
#kadmin.local -r EXAMPLE.COMAuthenticating as principal root/admin@EXAMPLE.COM with password.kadmin:add_principal -randkey host/masterkdc.example.comPrincipal "host/host/masterkdc.example.com@EXAMPLE.COM" created.kadmin:ktadd host/masterkdc.example.comEntry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.kadmin:quit
Start
kadmin op in een root shell op de slaaf KDC en gebruik zijn add_principal commando om een nieuwe regel aan te maken voor de host service van de slaaf KDC, en gebruik daarna zijn ktadd commando om gelijktijdig een willekeurige sleutel voor de service in te stellen en die sleutel op te slaan in het standaard keytab bestand van de slaaf. Deze sleutel wordt door de kpropd srviece gebruikt voor authenticatie van clienten.
#kadmin -p jimbo/admin@EXAMPLE.COM -r EXAMPLE.COMAuthenticating as principal jimbo/admin@EXAMPLE.COM with password.Password for jimbo/admin@EXAMPLE.COM:kadmin:add_principal -randkey host/slavekdc.example.comPrincipal "host/slavekdc.example.com@EXAMPLE.COM" created.kadmin:ktadd host/slavekdc.example.com@EXAMPLE.COMEntry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.kadmin:quit
Met zijn service sleutel, kan de slaaf KDC elke client authenticeren die er naar verbindt. Het is duidelijk dat het ze niet allemaal toegestaan kan zijn om de
kprop service van de slaaf te voorzien met een nieuwe gebiedsdatabase. Om toegang te beperken, zal de kprop service op de slaaf KDC alleen vernieuwingen accepteren van clienten waarvan de hoofdrolspeler namen opgegeven zijn in /var/kerberos/krb5kdc/kpropd.acl. Voeg de naam van de host service van de master KDC toe aan dat bestand.
# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
Zodra de slaaf KDC een kopie van de database heeft verkregen, zal het ook de meester sleutel nodig hebben die gebruikt is om het te versleutelen. Als de meester sleutel van de database van jouw KDC wordt bewaard in een stash bestand op de meester KCD (gewoonlijk met de naam
/var/kerberos/krb5kdc/.k5.REALM), kopieer je het naar de slaaf KDC met een beschikbare veilige methode, of je maakt een dummy database en identiek stash bestand op de slaaf KDC door kdb5_util create -s uit te voeren (de dummy database zal overschreven worden door de eerste succesvolle database overdracht) en hetzelfde wachtwoord op te geven.
Verzeker je ervan dat de firewall van de slaaf KDC de meester KDC toestaat om er toegang tot te hebben met gebruik van TCP op poort 754 (krb5_prop), en start de
kprop service. Controleer daarna opnieuw of de kadmin service uitgezet is.
Voer nu een handmatige database overdrachts test uit door het dumpen van de gebiedsdatabase, op de meester KDC, naar het standaard data bestand welke het
kprop commando zal lezen (/var/kerberos/krb5kdc/slave_datatrans), en gebruik daarna het kprop commando om zijn inhoud over te brengen naar de slaaf KDC.
# /usr/kerberos/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans# kprop slavekdc.example.com
Met gebruik van
kinit verifieer je dat een client systeem waarvan krb5.conf alleen de slaaf KDC laat zien in zijn lijst van KDC's voor jouw gebied, nu correct in staat is om initiele legitimatie te verkrijgen van de slaaf KDC.
Als dat gebeurd is, maak je een script welke de gebiedsdatabase dumpt en het
kprop commando uitvoert om de database naar iedere slaaf KDC over te brengen, en stel de cron service in om het script periodiek uit te voeren.
2.6.9. Cross gebieds authenticatie instellen
Cross-gebieds authenticatie is de term die gebruikt wordt voor het beschrijven van situaties waarin clienten (gewoonlijk gebruikers) van een gebied Kerberos gebruiken voor authenticatie van services (gewoonlijk server processen die draaien op een bepaald server systeem) die behoort tot een ander gebied dan hun eigen.
In het eenvoudigste geval, om voor een client in een gebied met de naam
A.EXAMPLE.COM toegaang te krijgen tot een service in het B.EXAMPLE.COM gebied, moeten beide gebieden een sleutel delen voor een hoofdrolspeler van de naam krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM, en beide sleutels moeten hetzelfde sleutel versie nummer ermee verbonden hebben.
Om dit te bereiken, kies je een zeer sterk wachtwoord of wachtzin, en je maakt een regel voor de hoofdrolspeler voor beide gebieden met gebruik van kadmin.
# kadmin -r A.EXAMPLE.COMkadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMEnter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit # kadmin -r B.EXAMPLE.COMkadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COMEnter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit
Gebruik het
get_principal commando om te verifieren dat beide regels overeenkomende sleutel versie nummers (kvno waarden) en versleuteling types hebben
Het dumpen van de database werk niet
Beheerders die bewust zijn van beveiliging proberen misschien de
-randkey optie van het add_principal commando te gebruiken om een willekeurige sleutel toe te kennen in plaats van een wachtwoord, dumpen daarna de nieuwe regel uit de database van het eerste gebied, en importeren het in het tweede. Dit zal niet werken behalve als de meester sleutels voor de gebieds databases identiek zijn, omdat de sleutels in een database dump zelf versleuteld zijn met de meester sleutel.
Clienten in het
A.EXAMPLE.COM gebied kunnen nu authentificeren voor services in het B.EXAMPLE.COM gebied. Anders gezegd, het B.EXAMPLE.COM gebied vertrouwt nu het A.EXAMPLE.COM gebied, of nog eenvoudiger, B.EXAMPLE.COM vertrouwt nu A.EXAMPLE.COM.
Dit brengt ons naar een belangrijk punt: cross-gebieds vertrouwen is standaard in een richting. De KDC voor het
B.EXAMPLE.COM gebied kan de clienten van A.EXAMPLE.COM vertrouwen voor authenticatie voor services in het B.EXAMPLE.COM gebied, maar dit heeft geen effect of clienten in het B.EXAMPLE.COM gebied wel of niet vertrouwd worden voor authenticatie voor services in het A.EXAMPLE.COM gebied. Om vertrouwen in de andere richting te krijgen, moeten beide gebieden sleutels delen voor de krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM service (let op de omgekeerde volgorde van de twee gebieden vergeleken met het vorige voorbeeld).
Als directe vertrouwens relaties de enigste methode was voor het aanbieden van vertrouwen tussen gebieden, dan zouden netwerken die meerdere gebieden bevatten erg moeilijk in te stellen zijn. Gelukkig is cross-gebieds vetrouwen transitief. Als clienten van
A.EXAMPLE.COM authenticatie kunnen verkrijgen voor services in B.EXAMPLE.COM, en clienten van B.EXAMPLE.COM authenticatie kunnen verkrijgen voor services inC.EXAMPLE.COM, dan kunnen clienten in A.EXAMPLE.COM ook authenticatie verkrijgen voor services in C.EXAMPLE.COM, zelfs als C.EXAMPLE.COM A.EXAMPLE.COM niet direct vertrouwt. Dit betekent dat op een netwerk met meerdere gebieden die elkaar moeten vertrouwen, het maken van goede keuzes over de op te zetten vetrouwens relaties, de hoeveelheid werk aanzienlijk kan reduceren.
Nu zit je met de meer conventionele problemen: het systeem van de client moet zodanig ingesteld worden, dat het correct het gebied kan bepalen waartoe een bepaalde service hoort en het moet in staat zijn om te bepalen hoe legitimatie voor services in dat gebied te verkrijgen zijn.
Eerste dingen eerst: de naam van de hoofdrolspeler voor een service geboden van af een specifieke server in een gegeven gebied ziet er als volgt uit:
service/server.example.com@EXAMPLE.COM
In dit voorbeeld is service gewoonlijk of de naam van het protocol dat gebruikt wordt (andere veel voorkomende waarden zijn ldap, imap, cvs, en HTTP) of host, server.example.com is de volledig gekwalifiseerde domein naan van het systeem die de service draaut, en
EXAMPLE.COM is de naam van het gebied.
Om te bepalen tot welk gebied de service behoort, zullen clienten vaak DNS moeten raadplegen, of de
domain_realm sectie van /etc/krb5.conf om of een hostnaam (server.example.com) of een DNS domein naam (.example.com) te koppelen aan de naam van het gebied (EXAMPLE.COM).
Nadat bepaald is tot welk gebied een service behoort, moet een client bepalen welke set van gebieden het moet benaderen, en in welke volgorde dit moet gebeuren om legitmatie te krijgen om authenticatie te vragen aan de service.
Dit kan op twee manieren gedaan worden.
De standaard methode, die geen expliciete instelling nodig heeft, is om gebieden namen te geven binnen een gedeelde hierarchie. Als voorbeeld, beschouw gebieden met de namen
A.EXAMPLE.COM, B.EXAMPLE.COM, en EXAMPLE.COM. Als een client in het A.EXAMPLE.COM gebied probeert authenticatie te krijgen voor een service in B.EXAMPLE.COM, zal het standaard eerst proberen legitimatie voor het EXAMPLE.COM gebied te krijgen, en deze legitimatie gebruiken om legitimatie te krijgen voor gebruik in het B.EXAMPLE.COM gebied.
De client behandelt de gebiedsnaam in dit scenario zoals men een DNS naam behandelt. Het stript herhaaldelijk onderdelen van zijn eigen gebiedsnaam af om de namen van gebieden tre genereren die "boven" zijn in de hierarchie totdat het een punt bereikt die ook "boven" is voor het gebied van de service. Op dat punt begint het met toevoegen van onderdelen van de gebiedsnaam van de server totdat het gebied van de server bereikt wordt. Elk gebied die in dit proces betrokken is is een nieuwe "hop".
Bijvoorbeeld, met gebruik van legitimatie in
A.EXAMPLE.COM, om dan authenticatie te krijgen voor een service in B.EXAMPLE.COM A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM A.EXAMPLE.COMenEXAMPLE.COMdelen een sleutel voorkrbtgt/EXAMPLE.COM@A.EXAMPLE.COMEXAMPLE.COMenB.EXAMPLE.COMdelen een sleutel voorkrbtgt/B.EXAMPLE.COM@EXAMPLE.COM
Een ander voorbeeld, met gebruik van legitimatie in
SITE1.SALES.EXAMPLE.COM, om dat authenticatie te krijgen voor een service in EVERYWHERE.EXAMPLE.COM SITE1.SALES.EXAMPLE.COM → SALES.EXAMPLE.COM → EXAMPLE.COM → EVERYWHERE.EXAMPLE.COM SITE1.SALES.EXAMPLE.COMenSALES.EXAMPLE.COMdelen een sleutel voorkrbtgt/SALES.EXAMPLE.COM@SITE1.SALES.EXAMPLE.COMSALES.EXAMPLE.COMenEXAMPLE.COMdelen een sleutel voorkrbtgt/EXAMPLE.COM@SALES.EXAMPLE.COMEXAMPLE.COMrnEVERYWHERE.EXAMPLE.COMdelen een sleutel voorkrbtgt/EVERYWHERE.EXAMPLE.COM@EXAMPLE.COM
Een ander voorbeeld, deze keer met gebiedsnamen waarvan de namen geen gemeenschappelijke achtervoegsel hebben (
DEVEL.EXAMPLE.COM en PROD.EXAMPLE.ORG DEVEL.EXAMPLE.COM → EXAMPLE.COM → COM → ORG → EXAMPLE.ORG → PROD.EXAMPLE.ORG DEVEL.EXAMPLE.COMenEXAMPLE.COMdelen een sleutel voorkrbtgt/EXAMPLE.COM@DEVEL.EXAMPLE.COMEXAMPLE.COMenCOMdelen een sleutel voorkrbtgt/COM@EXAMPLE.COMCOMenORGdelen een sleutel voorkrbtgt/ORG@COMORGenEXAMPLE.ORGdelen een sleutel voorkrbtgt/EXAMPLE.ORG@ORGEXAMPLE.ORGenPROD.EXAMPLE.ORGdelen een sleutel voorkrbtgt/PROD.EXAMPLE.ORG@EXAMPLE.ORG
De meer ingewikkelde, maar ook meer flexibele, methode bevat het instellen van de
capaths sectie van /etc/krb5.conf, zodat clienten die legitimatie hebben voor een gebied in staat zijn om op te zoeken welk gebied de volgende is in de keten die zal leiden tot het punt waarop het authenticatie kan aanvragen aan de servers.
Het formaat van de
capaths sectie is relatief ongecompliceerd: iedere regel in de sectie wordt genoemd naar een gebied waarin een client kan bestaan. Binnen die subsectie, wordt een lijst gegeven van tussengelegen gebieden waarvan de client legitimatie moet verkrijgen met als waarde de sleutel die overeenkomt met het gebied waarin een service kan bestaan. Als er geen tussenliggende gebieden zijn, wordt de waarde "." gebruikt.
Hier is een voorbeeld:
[capaths]
A.EXAMPLE.COM = {
B.EXAMPLE.COM = .
C.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = B.EXAMPLE.COM
D.EXAMPLE.COM = C.EXAMPLE.COM
}
In dit voorbeeld kunnen clienten in het
A.EXAMPLE.COM gebied cross-gebied legitimatie verkrijgen voor B.EXAMPLE.COM rechtstreeks van de A.EXAMPLE.COM KDC.
Als die clienten contact willen maken met een service in het
C.EXAMPLE.COM gebied, moeten ze eerst de benodigde legitimaties verkrijgen van het B.EXAMPLE.COM gebied (dit vereist dat krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM bestaat), en dan die legitimatie gebruiken om legitimaties te verkrijgen voor gebruik in het C.EXAMPLE.COM gebied (met gebruik van krbtgt/C.EXAMPLE.COM@B.EXAMPLE.COM).
Als die clienten contact willen maken met een service in het
D.EXAMPLE.COM gebied, moeten ze eerst de benodigde legitimatie verkrijgen van het B.EXAMPLE.COM gebied, en dan legitimaties van het C.EXAMPLE.COM gebied voordat ze tenslotte legitmaties voor gebruik met het D.EXAMPLE.COM gebied kunnen krijgen.
Opmerking
Zonder een capath regel die anders aangeeft, neemt Kerberos aan dat cross-gebieds vetrouwens relaties een heirarchie vormen.
Clienten in het
A.EXAMPLE.COM gebied kunnen rechtstreeks cross-gebieds legitimatie verkrijgen van B.EXAMPLE.COM. Zonder de "." die dit aangeeft, zou de client anders proberen het hierarchische pad te gebruiken, in dit geval:
A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM
2.6.10. Extra hulpbronnen
Voor meer informatie over Kerberos, refereer je naar de volgende hulpbronnen.
2.6.10.1. Geinstalleerde Kerberos documentatie
- De Kerberos V5 Installation Guide en de Kerberos V5 System Administrator's Guide in PostScript en HTML formaten. Deze kunnen gevonden worden in de
/usr/share/doc/krb5-server-map (waarin<versie-nummer>/<versie-nummer>het versie nummer is van hetkrb5-serverpakket geinstalleerd op je systeem). - De Kerberos V5 UNIX User's Guide in PostScript en HTML formaten. Deze kunnen gevonden worden in de
/usr/share/doc/krb5-workstation-map (waarin<versie-nummer>/<versie-nummer>het versie nummer is van hetkrb5-workstationpakket geinstalleerd op je systeem). - Kerberos manual pagina's — Er zijn een aantal manual . voor de verschillende toepassingen en configuratie bestanden betrokken bij een Kerberos implementatie. Het volgende is een lijst van een paar van de meest interessante maual pagina's
- Client toepassingen
man kerberos— Een inleiding voor het Kerberos systeem welke beschrijft hoe legitimaties werken en biedt aanbevelingen voor het verkrijgen en vernietigen van Kerberos kaartjes. Onderin refereert de manual pagina naar een aantal gerelateerde manual pagina's.man kinit— Beschrijf hoe je dit commando kunt gebruiken om een kaartjes-verlenend kaartje kunt verkrijgen en opslaan.man kdestroy— Beschrijft hoe je dit commando kunt gebruiken om Kerberos legitimaties te vernietigen.man klist— Beschrijft hoe je dit commando kunt gebruiken om de opgeslagen Kerberos legitimaties te tonen.
- Beheers toepassingen
man kadmin— Beschrijft hoe je dit commando kunt gebruiken om de Kerberos V5 database te beheren.man kdb5_util— Beschrijft hoe je dit commando kunt gebruiken voor het aanmaken en uitvoeren van beheersfuncties op laag niveau voor de Kerberos V5 database.
- Server toepassingen
man krb5kdc— Beschrijft beschikbare commandoregel opties voor de Kerberos V5 KDC.man kadmind— Beschrijft beschikbare commandoregel opties voor de Kerberos V5 beheersserver.
- Configuratie bestanden
man krb5.conf— Beschrijft het formaat en de opties beschikbaar in het configuratie bestand voor de Kerberos V5 bibliotheek.man kdc.conf— Beschrijft het formaat en de opties beschikbaar in het configuratie bestand voor de Kerberos V5 AS en KDC.
2.6.10.2. Nuttige Kerberos websites
- http://web.mit.edu/kerberos/www/ — Kerberos: The Network Authentication Protocol webpagina van MIT.
- http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html — De Kerberos vaak gestelde vragen (FAQ).
- ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS — De PostScript versie van Kerberos: An Authentication Service for Open Network Systems door Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schiller. Dit document is het orginele artikel dat Kerberos beschrijft.
- http://web.mit.edu/kerberos/www/dialogue.html — Designing an Authentication System: a Dialogue in Four Scenes origineel door Bill Bryant in 1988, veranderd door Theodore Ts'o in 1997. Dit document is een gesprek tussen twee ontwikkelaars die het denkproces van het maken van een authenticatie systeem lijkend op Kerberos doormaken. De gesprekstoon van de discussie maakt dit een goed startpunt voor iedereen die geheel onbekend is met Kerberos.
- http://www.ornl.gov/~jar/HowToKerb.html — How to Kerberize your site is een goede referentie voor het kerberizing van een netwerk.
- http://www.networkcomputing.com/netdesign/kerb1.html — Kerberos Network Design Manual is een gedegen overzicht van het Kerberos systeem.
2.7. Virtuele privé netwerken (VPN's)
Bedrijven met verscheidene satelliet kantoren verbinden vaak met elkaar met specifieke lijnen voor effectiviteit en bescherming van gevoelige data tijdens de overdracht. Bijvoorbeeld, veel bedrijven gebruiken frame relay of Asynchronous Transfer Mode (ATM) lijnen voor een eindpunt-naar-eindpunt oplossing om een kantoor met andere te verbinden. Dit kan een duur voorstel zijn, in het bijzonder voor bedrijven van gemiddelde grootte (SMB's) die uit willen breiden zonder de hoge kosten te betalen die behoren bij specifieke digitale circuits voor grote ondernemingen.
Om aan deze behoeft te voldoen, werden Virtuele privé netwerken (VPN's) ontwikkeld. Door het opvolgen van dezelfde functionele principes als specifieke circuits, staan VPN's beveiligde digitale communica toe tussen twee partijen (of netwerken), waarmee een Wide Area Network (WAN) gemaakt wordt van bestaande Local Area Networks (LAN's). Waarin het verschilt van frame relay of ATM is het transport medium. VPN's verzenden over IP met gebruik van datagrams als de transport laag, wat het een veilig kanaal door het Internet maakt naar een bedoelde bestemming. De meeste vrije VPN implementaties bevatten open standaard versleutelings methoden om de data tijdens de overdracht verder te maskeren.
Sommige bedrijven gebruiken hardware VPN oplossingen om de beveiliging te verbeteren, terwijl andere software gebruiken of op protocollen gebaseerde implementaties. Verschillende leveranciers bieden hardware VPN oplossingen, zoals Cisco, Nortel, IBM, en Checkpoint. Er is een vrije op software gebaseerde VPN oplossing voor Fedora met de naam FreeS/Wan die een standaard Internet Protocol Security (IPsec) implementatie gebruikt. Deze VPN oplossingen , onafhankelijk of ze op hardware of software gebaseerd zijn, werken als speciale routers die bestaan tussen de IP verbinding van een kantoor naar een ander.
2.7.1. Hoe werk een VPN?
Als een pakket wordt verzonden van een client, stuurt deze het door de VPN router of gateway, welke een Authenticatie header (AH) toevoegt voor de route en authenticatie. De data wordt dan versleuteld en, tenslotte, ingesloten binnen een Encapsulating Security Payload (ESP). Deze laatste vertegenwoordigt de versleuteling en afhandelings instructies.
De ontvangende VPN router stript de kop informatie, ontsleutelt de data, en verstuurt het naar de bedoelde bestemming (een werkstation of een andere node op een netwerk). Door gebruik van een netwerk-naar-netwerk verbinding ontvangt de ontvangende node op het locale netwerk de pakketten al ontsleuteld en klaar om verwerkt te worden. Het versleuteling/ontsleuteling proces in een netwerk-naar-netwerk VPN verbinding is transparant voor een locale node.
Met zo'n verbeterd niveau van beveiliging, moet een aanvaller niet alleen een pakket onderscheppen, maar het pakket ook ontsleutelen. Indringers die een man-in-het-midden aanval uitvoeren tussen een server en de client moeten ook toegang hebben tot tenminste een van de privé sleutels voor authenticatie van de sessies. Omdat zij verscheidene lagen van authenticatie en versleuteling gebruiken, zijn VPN's een veilig en effectief middel om te verbinden tussen meerdere node op afstand om te werken als een vereningd intranet.
2.7.2. VPN's and Fedora
Fedora biedt verschillende opties wat betreft de implementatie van software oplossingen voor een beveiligde verbinding naar een WAN. Internet Protocol Security (IPsec) is de ondersteunde VPN implementatie voor Fedora, en voldoet in voldoende mate aan de gebruikersbehoeften van bedrijven met buitenkantoren of gebruikers op afstand.
2.7.3. IPsec
Fedora ondersteunt IPsec voor het verbinden van hosts op afstand naar netwerken met gebruik van een beveiligde tunnel op een gemeenschappelijk dragers netwerk zoals het Internet. IPsec kan geimplementeerd worden door gebruik van een host-naar-host (een computer werkstation naar een ander) of netwerk-naar-netwerk (een LAN/WAN naar een ander) configuratie
De IPsec implementatie in Fedora gebruikt Internet Key Exchange (IKE), een protocol geimplementeerd door de Internet Engineering Task Force (IETF), gebruikt voor wederzijdse authenticatie en beveiligde samenwerking tussen verbindende systemen.
2.7.4. Een IPsec verbinding maken
Een IPsec verbinding is opgedeeld in twee logische fases. In fase 1 initialiseert een IPsec node de verbinding met de node of het netwerk op afstand. De node of het netwerk op afstand controleert de legitimaties van de aanvragende node en beide partijen onderhandelen over de authenticatie methode voor de verbinding.
Op Fedora systemen gebruikt een IPsec verbinding de pre-shared key methode van IPsec node authenticatie. In een pre-shared key IPsec verbinding, moeten beide hosts dezelfde sleutel gebruiken om verder te gaan naar fase 2 van de IPsec verbinding.
In fase 2 van de IPsec verbinding wordt de Security Association (SA) aangemaakt tussen de IPsec nodes. Deze fase maakt een SA database aan met configuratie informatie, zoals de versleutelings methode, geheime sessie sleutel uitwisselings parameters, en zo voort. Deze fase beheert de actuele IPsec verbinding tussen de nodes op afstand en netwerken.
De Fedora implementatie van IPsec gebruikt IKE voor het delen van sleutels tussen de hosts over het Internet. De
racoon keying daemon handelt de IKE sleutel distributie en uitwisseling af. Refereer naar de racoon manual pagina voor meer informatie over deze daemon.
2.7.5. IPsec installatie
Het implementeren van IPsec vereist dat het
ipsec-tools RPM pakket geinstalleerd wordt op alle IPsec hosts (als een host-naar-host configuratie gebruikt wordt) of routers (als een netwerk-naar-netwerk configuratie gebruikt wordt). Het RPM pakket bevat essentiele bibliotheken, daemons, en configuratie bestanden voor het instellen van de IPsec verbinding, inclusief:
/sbin/setkey— manipuleert het sleutel beheer en beveiligings attributen van IPsec in de kernel. Dit programma wordt gecontroleerd door deracoonsleutel beheers daemon. Refereer naar desetkey(8) manual pagina voor meer informatie./usr/sbin/racoon— de IKU sleutelbeheers daemon, gebruikt om voor het beheren en controleren van beveiligings samenwerking en sleuteldeling tussen systemen verbonden met IPsec./etc/racoon/racoon.conf— hetracoondaemon configuratie bestand gebruikt om verschillende aspecten van de IPsec verbinding in te stellen, inclusief authenticatie methodes en versleutelings algorithmes gebruikt in de verbinding. Refereer naar deracoon.conf(5) manual pagina voor een complete opsomming van de beschikbare instructies.
Om IPsec in te stellen op Fedora, kun je het Netwerkconfiguratie gereedschap gebruiken, of de netwerk en IPsec configuratie bestanden handmatig bewerken.
- Om twee netwerk-verbonden hosts met IPsec te verbinden, refereer je naar Paragraaf 2.7.6, “IPsec host-naar-host configuratie”.
- Om een LAN/WAN naar een ander te verbinden met IPsec, refereer je naar Paragraaf 2.7.7, “IPsec netwerk-naar-netwerk configuratie”.
2.7.6. IPsec host-naar-host configuratie
IPsec kan ingesteld worden om een bureaubald of werkstation (host) te verbinden met een andere door het gebruiken van een host-naar-host verbinding. Dit type verbinding gebruikt het netwerk waarmee iedere host verbonden is om een beveiligde tunnel tussen beide hosts te maken. De vereisten voor een host-naar-host verbinding zijn minimaal, evenals de instelling van IPsec op iedere host. De hosts hebben alleen een specifieke verbinding naar een draag netwerk nodig (zoals het Internet) en Fedora om de IPsec verbinding te maken.
2.7.6.1. Host-naar-host verbinding
Een host-naar-host IPsec verbinding is een versleutelde verbinding tussen twee systemen, welke beide IPsec draaien met dezelfde authenticatie sleutel. Als de IPsec verbinding actief is, wordt alle netwerkverkeer tussen de twee hosts versleuteld.
Om een host-naar-host IPsec verbinding in te stellen, gebruik je de volgende stappen op iedere host:
Opmerking
Je moet de volgende procedures uitvoeren op de actuele machine die je gaat instellen. Vermijd om te proberen IPsec verbindingen op afstand in te stellen en aan te maken.
- In een commando shell, type je
system-config-networkom het Netwerkconfiguratie gereedschap op te starten. - In de IPsec tab klik je op om de IPsec - instellingen helper op te starten.
- Klik op om de instelling van een host-naar-host IPsec verbinding te starten.
- Vul een unieke alias naam in voor de verbinding, bijvoorbeeld
ipsec0. Indien vereist, selecteer je het aanvinkhokje om de verbinding automatisch te activeren bij het opstarten van de computer. Klik op om verder te gaan. - Selecteert Host -naar-host encryptie als het verbindingstype, en klik op .
- Selecteer het type versleuteling om te gebruiken: handmatig of automatisch.Als je handmatige encryptie kiest, moet later in het proces een encryptie sleutel opgegeven worden. Als je automatische encryptie kiest, beheert de
racoondaemon de encryptie sleutel. Hetipsec-toolspakket moet geinstalleerd zijn als je automatische encryptie wilt gebruiken.Klik op om verder te gaan. - Vul het IP adres van de host op afstand in.Om het IP adres van de host op afstan te bepalen, gebruik je het volgende commando op de host op afstand
[root@myServer ~] # /sbin/ifconfig
<device>waarin<device>het Ethernet apparaat is dat je wilt gebruiken voor de VPN verbinding.Als je slechts een Ethernet kaart in het systeem hebt, is de apparaatnaam gewoonlijk eth0. Het volgende voorbeeld laat de relevante informatie van dit commando zien (merk op dat dit slechts een voorbeeld output is):eth0 Link encap:Ethernet HWaddr 00:0C:6E:E8:98:1D inet addr:172.16.44.192 Bcast:172.16.45.255 Mask:255.255.254.0Het IP adres is het nummer dat volgt op deinet addr:label.Opmerking
Voor host-naat-host verbindingen, moeten beide hosts een publieke, routable adres hebben. Aleternatief kunne beide hosts een privé, niet-routable adres hebben (bijvoorbeeld, uit de 10.x.x.x of 192.168.x.x reeksen) als ze maar ophetzelfde LAN zijn.Als de hosts op verschillende LAN's zijn, of een heeft een publiek adres terwijl de ander een privé adres heeft, refereer je naar Paragraaf 2.7.7, “IPsec netwerk-naar-netwerk configuratie”.Klik op om verder te gaan. - Als handmatige encryptie was geselecteerd in stap 6, geeft je de te gebruiken encryptie sleutel op, of klik op om er een te maken
- Geef een authenticatiesleutel op of klik op om er een te maken. Het kan elke combinatie van cijfers en letters zijn.
- Klik op om verder te gaan.
- Verifieer de informatie in de IPsec — Samenvatting pagina en klik dan op .
- Klik op => om de configuratie op te slaan.Je moet misschien het netwerk opnieuw opstarten om de veranderingen effect te laten hebben. Om het netwerk opnieuw op te starten, gebruik je het volgende commando:
[root@myServer ~]# service network restart
- Selecteer de IPsec verbinding in de lijst en klik op de knop.
- Herhaal de gehele procedure voor de andere host. Het is essentieel dat dezelfde sleutel van step 8 wordt gebruikt io de andere hosts. Anders zal IPsec niet werken.
Na het instellen van de IPsec verbinding, verschijnt het in de IPsec lijst zoals getoon in Figuur 2.10, “IPsec verbinding”.
IPsec verbinding
Figuur 2.10. IPsec verbinding
De volgende bestanden worden aangemaakt als de IPsec verbinding is ingesteld:
/etc/sysconfig/network-scripts/ifcfg-<nickname>/etc/sysconfig/network-scripts/keys-<nickname>/etc/racoon/<remote-ip>.conf/etc/racoon/psk.txt
Als automatische encryptie is geselecteerd, wordt
/etc/racoon/racoon.conf ook aangemaakt
Als de interface actief is, wordt
/etc/racoon/racoon.conf veranderd om <remote-ip>.conf2.7.6.2. Handmatige IPsec host-naar-host configuratie
De eerste stap voor het maken van een verbinding is het verzamelen van systeem en netwerk informatie voor ieder werkstation. Voor een host-naar-host verbinding heb je het volgende nodig:
- Het IP{ adres van elke host
- Een unieke naam, bijvoorbeeld,
ipsec1. Deze wordt gebruikt om de IPsec verbinding te identificeren en te onderscheiden van andere apparaten of verbindingen. - Een vast encryptiesleutel, of een automatisch aangemaakte door
racoon. - Een pre-gedeelde authenticatie sleutel die gebruikt wordt tijdens de initiele fase van de verbinding en om encryptiesleutels uit te wisselen tijdens de sessie.
Bijvoorbeeld, veronderstel dat Werkstation A en Werkstation B met elkaar willen verbinden met een IPsec tunnel. Ze willen verbinden met gebruik van een pre-gedeelde sleutel met de waarde
Key_Value01, en de gebruikers zijn erover eens om racoon te gebruiken voor het automatisch genereren en delen van een authenticatie sleutel tussen iedere host. Beide host gebruikers besluiten om hun verbinding ipsec1 te noemen.
Opmerking
Je moet een PSK kiezen die een mengeling gebruikt van hoofdletters, kleine letters, cijfers en leestekens. Een gemakkelijk raadbare PSK is een beveiligings risico.
Het is niet nodig om dezelfde verbindingsnaam re gebruiken voor iedere host. Je moet ee naam kiezen die handig is en betekenis heeft voor je installatie.
Het volgende is het IPsec configuratie bestand voor Werkstation A voor een host-naar-host IPsec verbinding met Werkstation B. De unieke naam om de verbinding te identificeren is in dit voorbeeld
ipsec1,. dus het resulterende bestand wordt /etc/sysconfig/network-scripts/ifcfg-ipsec1 genoemd.
DST=X.X.X.XTYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK
Voor Werkstation A, is
X.X.X.X het IP adres van Werkstation B. Voor Werkstsation B, is X.X.X.X het IP adres van Werkstation A. Deze verbinding is niet ingesteld om op te starten tijdens het opstarten van de computer (ONBOOT=no) en het gebruikt een pre-gedeelde sleutel methode voor authenticatie (IKE_METHOD=PSK).
Het volgende is de inhoud van het pre-gedeelde sleutel bestand (met de naam
/etc/sysconfig/network-scripts/keys-ipsec1) dat beide werkstations noddig hebben voor autenticatie van elkaar. De inhoud van dit bestand moet op beide werkstations identiek zijn, en alleen de root gebruiker moet in staat zijn dit bestand te lezen of te schrijven.
IKE_PSK=Key_Value01
Belangrijk
Om het
keys-ipsec1 bestand zodanig te veranderen dat alleen de root gebruiker dit bestand kan lezen of veranderen, voer je het volgende commando uit na het aanmaken van het bestand:
[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
Om op elk gewenst moment de authenticatie sleutel te veranderen, bewerk je het
keys-ipsec1 bestand op beide werkstations.Beide authenticatie sleutels moeten identiek zijn voor een juiste verbinding.
Het volgende voorbeeld laat de specifieke instelling voor de fase 1 verbinding naar de host op afstand zien. Het bestand wordt
X.X.X.X.confX.X.X.X het IP adres van de IPsec host op afstand is. Merk op dat dit bestand automatisch aangemaakt wordt als de IPsec tunnel actief is en moet niet direct bewerkt worden.
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
Het standaard fase 1 configuratie bestand wordt aangemaakt als een IPsec verbinding wordt opgezet, bevat de volgende instructies gebruikt door de Fedora implementatie van IPsec
- remote
X.X.X.X - Specificeert dat de volgende regels van dit configuratie bestand alleen van toepassing zijn voor de node op afstang geidentificeerd met het
X.X.X.XIP adres. - exchange_mode aggressive
- De standaard configuratie voor IPsec in Fedora gebruikt een aggressieve authenticatie methode, wat de verbindings overhead verlaagt terwijl het de instelling van verscheidene IPsec verbindingen met meerdere hosts toestaat.
- my_identifier address
- Specificeert de identificatie methode te gebruiken voor de authenticatie van nodes. Fedora gebruikt alleen IP adressen om nodes te identificeren.
- encryption_algorithm 3des
- Specificeert de encryptie code gebruikt tijdens de authenticatie. Standaard wordt Triple Data Encryption Standard (3DES) gebruikt.
- hash_algorithm sha1;
- Specificeert het hash algorithme gebruikt tijdens de fase 1 onderhandeling tussen nodes. Standaard wordt Secure Hash Algorithm versie 1 gebruikt.
- authentication_method pre_shared_key
- Specificeert de authenticatie methode die gebruikt wordt tijdens de node onderhandeling. Standaard gebruikt Fedora pre-gedeelde sleutels voor authenticatie.
- dh_group 2
- Specificeert het Diffie-Hellman groep getal voor het instellen van dynamisch aangemaakte sessie sleutels. Standaard wordt modp1024 (groep 2) gebruikt.
2.7.6.2.1. Het racoon configuratie bestand
De
/etc/racoon/racoon.conf bestanden moeten identiek zijn op alle IPsec nodes behalve voor de include "/etc/racoon/X.X.X.X.conf" instructie. Deze instructie (en het bestand waarnaar het verwijst) wordt aangemaakt als de IPsec tunnel actief wordt. Voor Werkstation A is de X.X.X.X in de include instructie het IP adres van Werkstation B. Het omgekeerde geldt voor Werkstation B. Het volgende toont een typisch racoon.conf bestand als de IPsec verbinding actief is.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";
Dit standaard
racoon.conf bestand bevat gedefinieerde paden voor IPsec configuratie, pre-gedeelde sleutel bestanden, en certificaten. De velden in sainfo anonymous beschrijven een fase 2 SA tussen IPsec nodes — het karakter van de IPsec verbinding (inclusief de ondersteunde encryptie algorithmes die gebruikt worden) en de methode voor het uitwisselen van sleutels. De volgende lijst definieert de velden van fase 2:
- sainfo anonymous
- Geeft aan dat SA anoniem kan initialiseren met iedere gelijke mits de IPsec legitimaties overeen komen.
- pfs_group 2
- Definieert het Diffie-Hellman sleutel uitwisselings protocol, welke de methode bepaalt waarmee de IPsec nodes een gemeenschappelijke tijdelijke sessie sleutel vaststellen voor de tweede fase van de IPsec verbinding. Standaard gebruikt de Fedora implementatie van IPsec groep 2 (of
modp1024) van de Diffie-Hellman cryptografische sleutel uitwisselings groepen. Groep 2 gebruikt een 1024-bit modulair machtverheffen dat aanvallers belet om vorige IPsec overdrachten te ontsleutelen zelfs als de privé sleutel in gevaar is gebracht. - lifetime time 1 hour
- Deze parameter specificeert de levenduur van een SA en kan opgegeven worden met tijd of data bytes. De standaard Fedora implementatie van IPsec specificeert een uur levenduur.
- encryption_algorithm 3des, blowfish 448, rijndael
- Specificeert de ondersteunde encryptoe codes voor fase 2. Fedora onderstent 3DES, 448-bit Blowfish, en Rijndael (de code gebruikt in de Advanced Encryption Standard, of AES).
- authentication_algorithm hmac_sha1, hmac_md5
- Laat de ondersteunde hash algorithmes voor authenticatie zien. Ondersteunde modes zijn sha1 en md5 hash boodschap authenticatie codes (HMAC).
- compression_algorithm deflate
- Definieert het Deflate compressie algorithme voor IP Payload Compression (IPCOMP) ondersteuning, die een potentieel sneller transport van IP datagrams over langzame verbindingen toestaat.
Om de verbinding te starten gebruik je het volgende commando op iedere host:
[root@myServer ~]# /sbin/ifup <nickname>
waarin <nickname> de naam is die je opgegeven hebt voor de IPsec verbinding.
Om de IPsec verbinding te testen, voer je het
tcpdump commando uit om de netwerkpakketten te zien die tussen de hosts uitgewisseld wordt en verifieer dat ze versleuteld zijn met IPsec. Het pakket moet een AH koptekst bevatten en moet getoond worden als ESP pakkettern. ESP betekent dat het versleuteld is. Bijvoorbeeld:
[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem> IP 172.16.45.107 > 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)
2.7.7. IPsec netwerk-naar-netwerk configuratie
IPsec kan ook ingesteld worden om een geheel netwerk (zoals een LAN of WAN) te verbinden met een netwerk op afstand met gebruik van een netwerk-naar-netwerk verbinding. Een netwerk-naar-netwerk verbinding vereist het instellen van IPsec routers aan iedere kant van de verbindende netwerken voor het transparant bewerken en doorgeven van informatie van een node op een LAN naar een node op een LAN op afstand. Figuur 2.11, “Een netwerk-naar-netwerk IPsec verbinding met tunnel” laat een netwerk-naar-netwerk IPsec verbinding met tunnel zien.
Een netwerk-naar-netwerk IPsec verbinding met tunnel
Figuur 2.11. Een netwerk-naar-netwerk IPsec verbinding met tunnel
Deze illustratie laat twee aparte LAN's zien gescheiden door het Internet. Deze LAN's gebruiken IPsec routers voor authenticatie en initiatie van een verbinding met gebruik van een beveiligde tunnel door het Internet. Pakketten die in de overdracht onderschept worden zullen brute-kracht ontsleuteling vereisen om de code te kraken die de pakketten tussen deze LAN's beschermd. Het proces van communicatie van een node in de 192.168.1.0/24 IP reeks naar een andere in de 92.168.2.0/24 reeks is geheel transparant voor de nodes omdat het verwerken, versleutelen/ontsleutelen, en omleiden van de IPsec pakketten geheel afgehandeld wordt door de IPsec router.
De informatie nodig voor een netwerk-naar-netwerk verbinding omvat:
- De extern toegankelijke IP adressen van de specifieke IPsec routers
- De netwerk adres reeksen van de LAN/WAN bedient door de IPsec routers (zoals 192.168.1.0/24 of 10.0.1.0/24)
- Het IP adres van de gateway apparaten die de data van de netwerk nodes omleiden naar het Internat
- Een unieke naam, bijvoorbeeld,
ipsec1. Deze wordt gebruikt om de IPsec verbinding te identificeren en te onderscheiden van andere apparaten of verbindingen. - Een vaste enctyptie sleutel of een automatisch aangemaakte door
racoon - Een pre-gedeelde authenticatie sleutel die gebruikt wordt tijdens de initiele fase van de verbinding en om encryptiesleutels uit te wisselen tijdens de sessie.
2.7.7.1. Netwerk-naar-netwerk (VPN) verbinding
Een netwerk-naar-netwerk IPsec verbinding gebruikt twee IPsec routers, een voor ieder netwerk, waarmee het netwerkverkeer voor de privé subnetten omgeleid wordt.
Bijvoorbeeld, zoals getoond in Figuur 2.12, “Netwerk-naar-netwerk IPsec”, als het 192.168.1.0/24 privé netwerk netwerkverkeer verstuurt naar het 192.168.2.0/24 privé netwerk, gaan de pakketten door gateway0, naar ipsec0, door het Internet, naar ipsec1, naar gateway1, en naar het 192.168.2.0/24 subnet.
IPsec routers vereisen publiek adresseerbare IP adressen en een tweede Ethernet apparaat verbonden met hun respectievelijke privé netwerken. Verkeer gaat alleen door een IPsec router als het bedoeld is voor een andere IPsec router waarme het een versleutelde verbinding heeft.
Netwerk-naar-netwerk IPsec
Figuur 2.12. Netwerk-naar-netwerk IPsec
Alternatieve netwerk configuratie opties zijn een firewall tussen elke IP router en het Internet, en een intranet firewall tussen elke IPsec router en subnet gateway. De IPsec router en de gateway voor het subnet kunnen een systeem zijn met twee Ethernet apparaten: een met een publiek IP adres dat werkt als de IPsec router; en een met een privé IP adres dat werkt als de gateway voor het privé subnet. Iedere IPsec router kan de gateway gebruiken voor zijn privé netwerk of een publieke gateway om de pakketten naar de andere IPsec router te sturen.
Gebruik de volgende procedure om een netwerk-naar-netwerk IPsec verbinding in te stellen:
- In een commando shell, type je
system-config-networkom het Netwerkconfiguratie gereedschap op te starten. - In de IPsec tab klik je op om de IPsec - instellingen helper op te starten.
- Klik op om de netwerk-naar-netwerk IPsec verbinding in te stellen.
- Vul een unieke naam in voor de verbinding, bijvoorbeeld,
ipsec0. Indien nodig selecteer je het aanvinkhokje om de verbinding outomatisch op te starten als de computer opgestart wordt. Klik op om verder te gaan. - Selecteer Netwerk-naar-netwerk encryptie (VPN) als het connectie type, en klik dan op .
- Selecteer het type versleuteling om te gebruiken: handmatig of automatisch.Als je handmatige encryptie kiest, moet later in het proces een encryptie sleutel opgegeven worden. Als je automatische encryptie kiest, beheert de
racoondaemon de encryptie sleutel. Hetipsec-toolspakket moet geinstalleerd zijn als je automatische encryptie wilt gebruiken.Klik op om verder te gaan. - Op de Lokaal netwerk pagina vul je de volgende informatie in:
- Lokaal netwerkadres — Het IP adres van het apparaat op de IPsec router verbonden met het privé netwerk.
- Lokaal subnetmasker — Het subnetmasker van het lokale netwerk IP adres.
- Lokaal netwerk gateway — De gateway voor het privé subnet.
Klik op om verder te gaan.
Lokaal netwerk informationFiguur 2.13. Lokaal netwerk information
- Op de Netwerk op afstand pagina vul je de volgende informatie in:
- IP-adres op afstand — Het publiek adresseerbare IP adres van de IPsec router voor het andere privé netwerk. In ons voorbeeld, voor ipsec0, vul je het publiek adresseerbare IP adres van ipsec1 in, en omgekeerd.
- Netwerkadres op afstand — Het netwerk adres van het privé subnet achter de andere IPsec router. In ons voorbeeld, vul je
192.168.1.0in voor het instellen van ipsec1, en vul je192.168.2.0in voor het instellen van ipsec0. - Subnetmasker op afstand — Het subnet maker van het IP adres op afstand.
- Netwerk gateway op afstand — Het IP adres van de gateway voor het netwerk adres op afstand.
- Als handmatige encryptie was geselecteerd in stap 6, specificeer je de te gebruiken encryptie sleutel of je klikt op om een aan te maken.Specificeer een authenticatie sleutel of klik op om een aan te maken. Deze sleutel kan een willekeurige combinatie kan cijfers en letters zijn.
Klik op om verder te gaan.
Netwerk op afstand informationFiguur 2.14. Netwerk op afstand information
- Verifieer de informatie in de IPsec — Samenvatting pagina en klik dan op .
- Selecteer => om de instelling op te slaan.
- Selecteer de IPsec verbinding in de lijst en klik dan op om de verbinding te activeren.
- Zet IP forwarding aan:
- Bewerk
/etc/sysctl.confen zetnet.ipv4.ip_forwardop1. - Gebruik het volgende commando om de verandering aan te zetten:
[root@myServer ~]# /sbin/sysctl -p /etc/sysctl.conf
Het netwerk script om de IPsec verbinding te activeren maakt automatisch netwerkroutes om pakketten te versturen door de IPsec router indien nodig.
2.7.7.2. Handmatige IPsec netwerk-naar-netwerk configurtie
Veronderstel dat LAN A (lana.example.com) en LAN B (lanb.example.com) met elkaar verbinden willen via een IPsec tunnel. Het netwerk adres voor LAN A is in de 192.168.1.0/24 reeks, terwijl LAN B de 192.168.2.0/24 reeks gebruikt. Het gateway IP adres is 192.168.1.254 voor LAN A en 192.168.2.254 voor LAN B. De IPsec routers zijn apart van iedere LAN gateway en gebruiken twee netwerkapparaten: eth0 is toegekend an een extern toegankelijk statisch IP adres die toegang geeft tot het Internet, terwijl eth1 werkt als een routing punt voor het bewerken en verzenden van LAN pakketten van een netwerk node naar netwerk nodes op afstand.
De IPsec verbinding tussen elk netwerk gebruikt een pre-gedeelde sleutel met de waarde
r3dh4tl1nux, en de beheerders van A en B komen overeen om racoon te gebruiken voor het automatisch genereren en delen van authenticatie sleutels tussen elke IPsec router. De beheerder van LAN A besluit de IPsec verbinding ipsec0 te noemen, terwijl de beheerder van LAN B de IPsec verbinding ipsec1 noemt.
Het volgende voorbeeld laat de inhoud van het
ifcfg bestand voor een netwerk-naar-netwerk IPsec verbinding voor LAN A zien. De unieke naam om de verbinding in dit voorbeeld te identificeren is ipsec0, dus het resulterende bestand wordt /etc/sysconfig/network-scripts/ifcfg-ipsec0 genoemd.
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X
De volgende lijst beschrijft de inhoud van dit bestand:
- TYPE=IPSEC
- Specificeert het type verbinding.
- ONBOOT=yes
- Specificeert dat de verbinding opgezet moet worden bij het opstarten van de computer.
- IKE_METHOD=PSK
- Specificeert dat de verbinding de pre-gedeelde sleutel methode voor authenticatie gebruikt.
- SRCGW=192.168.1.254
- Het IP adres voor de bron gateway. Voor LAN A, is dit de LAN A gateway, en voor LAN B, de LAN B gateway.
- DSTGW=192.168.2.254
- Het IP adres voor de bestemmings gateway. Voor LAN A, is dit de LAN B gateway, en voor LAN B, de LAN A gateway.
- SRCNET=192.168.1.0/24
- Specificeert het bron netwerk voor de IPsec verbinding, welle in dit voorbeeld de netwerk reeks voor LAN A is.
- DSTNET=192.168.2.0/24
- Specificeert het bestemmings netwerk voor de IPsec verbinding, welke in dit voorbeeld de netwerk reeks voor LAN B is
- DST=X.X.X.X
- Het extern toegankelijke IP adres van LAN B.
Het volgende voorbeeld is de inhoud van het pre-gedeelde sleutel bestand met de naam
/etc/sysconfig/network-scripts/keys-ipsecX (waarin X 0 is voor LAN A en 1 voor LAN B) dat beide netwerken gebruiken voor authenticatie van elkaar. De inhoud van dit bestand moet identiek zijn en alleen de root gebruiker moet in staat zijn dit bestand te lezen of te schrijven.
IKE_PSK=r3dh4tl1nux
Belangrijk
Om het
keys-ipsecX bestand te veranderen zodat alleen de root gebruiker dit bestand kan lezen of schrijven, gebruik je het volgende commando na het aanmaken van het bestand:
chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1
Om op een willekeurig moment de authenticatie sleutel te veranderen, bewerk je het
keys-ipsecX bestand op beide IPsec routers. Beide sleutels moeten identiek zijn voor een juiste verbinding.
Het volgende voorbeeld is de inhoud van het
/etc/racoon/racoon.conf configuratie bestand voor de IPsec verbinding. Merk op dat de include regel onder in het bestand automatisch gegenereerd wordt en alleen verschijnt als de IPsec tunnel actief is.
# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"
Het volgende is de specifieke configuratie voor de verbinding naar het netwerk op afstand. Het gbestand wordt
X.X.X.X.confX.X.X.X het IP adres is van de IPsec router op afstand). Merk op dat dit bestand automatisch gegenereerd wordt als de IPsec tunnel actief is en moet niet direct bewerkt worden.
remote X.X.X.X{
exchange_mode aggressive, main;
my_identifier address;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2 ;
}
}
Voor het opstarten van de IPsec verbinding, moet IP forwarding aangezet worden in de kernel. Om IP forwarding aan te zetten:
- Bewerk
/etc/sysctl.confen zetnet.ipv4.ip_forwardop1. - Gebruik het volgende commando om de verandering aan te zetten:
[root@myServer ~] # sysctl -p /etc/sysctl.conf
Om de IPsec verbinding te starten gebruik je het volgende commando op elke router:
[root@myServer ~] # /sbin/ifup ipsec0
De verbindingen zijn geactiveerd en zowel LAN A als LAN B zijn in staat om met elkaar te communiceren. De routes worden automatisch aangemaakt via het initialisatie script aangeroepen door het uitvoeren van
ifup op de IPsec verbinding. Om een lijst van routes voor het netwerk te zien, gebruik je het volgende commando:
[root@myServer ~] # /sbin/ip route list
Om de IPsec verbinding te testen, voer je het
tcpdump commando uit op het extern-routable apparaat (eth0 in dit geval) om de netwerkpakketten te zien die verstuurd worden tussen de kosts (of netwerken), en verifieer dat ze versleuteld zijn met IPsec. Bijvoorbeeld, om de IPsec verbinding van LAN A te controleren, gebruik je het volgende commando:
[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com
Het pakket moet een AH koptekst bevatten en moet getoond worden als ESP pakketten. ESP betekent dat het versleuteld is. Bijvoorbeeld ( back slashes (\) geven het vervolgen van een regel aan):
12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
(ipip-proto-4)
2.7.8. Het starten en stoppen van een IPsec verbinding
Als de IPsec verbinding niet ingesteld is om op te starten tijdens het opstarten van de computer, kun je het besturen vanaf de commandoregel.
Om de verbinding te starten, gebruik je het volgende commando voor elke host voor host-naar-host IPsec, of iedere IPsec router voor netwerk-naar-netwerk IPsec:
[root@myServer ~] # /sbin/ifup <nickname>
waarin
<nickname> de naam is die je eerder hebt ingestled, zoals ipsec0.
Om de verbinding te stoppen, bebruik je het volgende commando:
[root@myServer ~] # /sbin/ifdown <nickname>
2.8. Firewalls
Informatie beveiliging wordt meestal beschouwd als een proces en niet als een product. Standaard beveiligings implementaties gebruiken gewoonlijk echter een specifiek mechanisme om de toegangsrechten te controleren en netwerkhulpbronnen te beperken tot gebruikers die gemachtigd, identificeerbaar en traceerbaar zijn. Fedora bevat verscheidene gereedschappen om beheerders en beveiligings ingenieurs te helpen met toegangscontrole zaken op netwerk niveau.
Firewalls zijn een van de kernonderdelen van een netwerkbeveiligings implementatie. Verscheidene leveranciers brengen firewall oplossingen op de markt die zich richten op alle niveau's van de markt: van thuisgebruikers die een PC beschermen tot datacentrum oplossingen die vitale bedrijfsinformatie beschermen. Firewalls kunnen op zichzelf staande hardware oplossingen zijn, zoals firewall apparaten van Cisco, Nokia, en Sonicwall. Leveranciers zoals Checkpoint, McAfee, en Symantec hebben ook eigendomsmatige software firewall oplossingen ontwikkeld voor thuis en zakelijke markten.
Naast het verschil tussen hardware en software firewalls, zijn er ook verschillen in de manier waarop firewalls werken die de ene oplossing onderscheidt van een andere. Tabel 2.2, “Firewall types” geeft details van drie veel voorkomende types van firewalls en hoe ze werken: