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.
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.
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
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.
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.
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.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.