15.6. TCP Wrappers
Terug | Hoofdstuk 15. Beveiliging | Volgende

## 15.6. TCP Wrappers

Geschreven door Tom Rhodes.

Iedereen die bekend is met inetd(8) heeft waarschijnlijk wel eens van TCP Wrappers gehoord. Maar slechts weinigen lijken volledig te begrijpen hoe ze in een netwerkomgeving toegepast kunnen worden. Het schijnt dat iedereen een firewall wil hebben om netwerkverbindingen af te handelen. Ondanks dat een firewall veel kan, zijn er toch dingen die het niet kan, zoals tekst terugsturen naar de bron van een verbinding. De TCP Wrappers software kan dat en nog veel meer. In dit onderdeel worden de mogelijkheden van TCP Wrappers besproken en, waar dat van toepassing is, worden ook voorbeelden voor implementatie gegeven.

De TCP Wrappers software vergroot de mogelijkheden van inetd door de mogelijkheid al zijn serverdaemons te controleren. Met deze methode is het mogelijk om te loggen, berichten te zenden naar verbindingen, een daemon toe te staan alleen interne verbindingen te accepteren, etc. Hoewel een aantal van deze mogelijkheden ook ingesteld kunnen worden met een firewall, geeft deze manier niet alleen een extra laag beveiliging, maar gaat dit ook verder dan wat een firewall kan bieden.

De toegevoegde waarde van TCP Wrappers is niet dat het een goede firewall vervangt. TCP Wrappers kunnen samen met een firewall en andere beveiligingsinstellingen gebruikt worden om een extra laag van beveiliging voor het systeem te bieden.

Omdat dit een uitbreiding is op de instellingen van inetd, wordt aangenomen dat de lezer het onderdeel inetd configuratie heeft gelezen.

### Opmerking:

Hoewel programma's die onder inetd(8) draaien niet echt “daemons” zijn, heten ze traditioneel wel zo. Deze term wordt hier dus ook gebruikt.

### 15.6.1. Voor het eerst instellen

De enige voorwaarde voor het gebruiken van TCP Wrappers in FreeBSD is ervoor te zorgen dat de server inetd gestart wordt vanuit `rc.conf` met de optie `-Ww`; dit is de standaardinstelling. Er wordt vanuit gegaan dat `/etc/hosts.allow` juist is ingesteld, maar als dat niet zo is, dan zal syslogd(8) dat melden.

### Opmerking:

In tegenstelling tot bij andere implementaties van TCP Wrappers is het gebruik van `hosts.deny` niet langer mogelijk. Alle instellingen moeten in `/etc/hosts.allow` staan.

In de meest eenvoudige instelling worden verbindingen naar daemons toegestaan of geweigerd afhankelijk van de opties in `/etc/hosts.allow`. De standaardinstelling in FreeBSD is verbindingen toe te staan naar iedere daemon die met inetd is gestart. Na de basisinstelling wordt aangegeven hoe dit gewijzigd kan worden.

De basisinstelling heeft meestal de vorm `daemon : adres : actie`. `daemon` is de daemonnaam die `inetd` heeft gestart. Het `adres` kan een geldige hostnaam, een IP-adres of een IPv6-adres tussen blokhaken ([ ]) zijn. Het veld `actie` kan `allow` of `deny` zijn, afhankelijk van of toegang toegestaan of geweigerd moet worden. De instellingen werken zo dat ze worden doorlopen van onder naar boven om te kijken welke regel als eerste van toepassing is. Als een regel van toepassing is gevonden, dan stop het zoekproces.

Er zijn nog andere mogelijkheden, maar die worden elders toegelicht. Een eenvoudige instelling kan al van met deze informatie worden gemaakt. Om bijvoorbeeld POP3 verbindingen toe te staan via de mail/qpopper daemon, zouden de volgende instellingen moeten worden toegevoegd aan `hosts.allow`:

    # Deze regel is nodig voor POP3-verbindingen
    qpopper : ALL : allow

Nadat deze regel is toegevoegd moet inetd herstart worden door gebruik te maken van service(8):

    # service inetd restart

### 15.6.2. Gevorderde instellingen

TCP Wrappers hebben ook gevorderde instellingen. Daarmee komt meer controle over de wijze waarop er met verbindingen wordt omgegaan. Soms is het een goed idee om commentaar te sturen naar bepaalde hosts of daemonverbindingen. In andere gevallen moet misschien iets in een logboekbestand geschreven worden of een email naar de beheerder gestuurd worden. Dit kan allemaal met instellingen die `wildcards`, uitbreidingskarakters (expansion characters) en het uitvoeren van externe commando's heten. De volgende twee paragrafen beschrijven deze mogelijkheden.

#### 15.6.2.1. Externe commando's

Stel dat zich de situatie voordoet waar een verbinding geweigerd moet worden, maar er een reden gestuurd moet worden naar het individu dat die verbinding probeerde op te zetten. Hoe gaat dat? Dat is mogelijk door gebruik te maken van de optie `twist`. Als er een poging tot verbinding wordt gedaan, wordt er met `twist` een shellcommando of script uitgevoerd. Er staat al een voorbeeld in `hosts.allow`:

    # De andere daemons zijn beschermd.
    ALL : ALL \
    	: severity auth.info \
    	: twist /bin/echo "You are not welcome to use %d from %h."

Dit voorbeeld geeft aan dat het bericht “You are not allowed to use `daemon` from `hostname`.” wordt teruggestuurd voor iedere daemon die niet al is ingesteld in het toegangsbestand. Het is erg handig om een antwoord terug te sturen naar degene die een verbinding op heeft willen zetten meteen nadat een tot stand gekomen verbinding is verbroken. Let wel dat alle berichten die gezonden worden moeten staan tussen `"` karakters. Hier zijn geen uitzonderingen op.

### Waarschuwing:

Het is mogelijk een ontzegging van dienst aanval uit te voeren op de server als een aanvaller, of een groep aanvallers, deze daemons kan overstromen met verzoeken om verbindingen te maken.

Het is ook mogelijk hier de optie `spawn` te gebruiken. Net als `twist` weigert de optie `spawn` impliciet de verbinding en kan het gebruikt worden om shellcommando's of scripts uit te voeren. Anders dan bij `twist` stuurt `spawn` geen bericht aan degene die de verbinding wilde maken. Zie bijvoorbeeld de volgende instelling:

    # Geen verbindingen van example.com:
    ALL : .example.com \
    	: spawn (/bin/echo %a from %h attempted to access %d >> \
    	  /var/log/connections.log) \
    	: deny

Hiermee worden alle verbindingen van het domein `*.example.com` geweigerd. Tegelijkertijd worden ook hostnaam, IP adres en de daemon waarmee verbinding werd gemaakt naar `/var/log/connections.log` geschreven.

Naast de vervangingskarakters die al zijn toegelicht, zoals `%a`, bestaan er nog een paar andere. In de handleiding van hosts_access(5) staat een volledige lijst.

#### 15.6.2.2. Wildcardopties

Tot nu toe is in ieder voorbeeld `ALL` gebruikt. Er bestaan nog andere opties waarmee de mogelijkheden nog verder gaan. Zo kan `ALL` gebruikt worden om van toepassing te zijn op iedere instantie van een daemon, domein of een IP adres. Een andere wildcard die gebruikt kan worden is `PARANOID`. Daarmee wordt iedere host die een IP-adres geeft dat gefingeerd kan zijn aangeduid. Met andere woorden: `PARANOID` kan gebruikt worden om een actie aan te geven als er een IP-adres gebruikt wordt dat verschilt van de hostnaam. Het volgende voorbeeld kan wat verheldering brengen:

    # Weiger mogelijke gespoofte verzoeken aan sendmail:
    sendmail : PARANOID : deny

In het voorgaande voorbeeld worden alle verbindingsverzoeken aan `sendmail` met een IP-adres dat verschilt van de hostnaam geweigerd.

### Let op:

Het gebruik van de wildcard `PARANOID` kan nogal wat schade aanrichten als de cliënt of de server kapotte DNS-instellingen heeft. Voorzichtigheid van de beheerder is geboden.

De handleiding van hosts_access(5) geeft meer uitleg over wildcards en de mogelijkheden die ze bieden.

Voordat de bovenstaande instellingen werken, dient de eerste regels in `hosts.allow` als commentaar gemarkeerd te worden.

Terug | Omhoog | Volgende
15.5. Eenmalige wachtwoorden | Begin | 15.7. Kerberos5