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.
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. Dit gaat met het commando kill(1) of met de
parameter restart met /etc/rc.d/inetd.
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.
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.
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 opHet 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.