[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.
Differences
This shows you the differences between two versions of the page.
Last revisionBoth sides next revision | |||
howtos:security:inetd [2012/09/22 21:09 (UTC)] – moved the page from security:inetd namspace mfillpot | howtos:security:inetd [2012/09/22 21:14 (UTC)] – missed content in the copy and corrected headings to create index mfillpot | ||
---|---|---|---|
Line 1: | Line 1: | ||
<!-- Add your text below. We strongly advise to start with a Headline (see button bar above). --> | <!-- Add your text below. We strongly advise to start with a Headline (see button bar above). --> | ||
- | ====Contents==== | + | ====== hosts.allow, |
+ | |||
+ | |||
+ | These two files in **/etc** are a common place for storing rules about who you want to allow to connect to the services on your machine. | ||
+ | |||
+ | While a firewall can be considered as hiding a door, these files control who is allowed to open the door. | ||
+ | |||
+ | Used in combination, | ||
+ | * default open with exclusions (ban list) | ||
+ | * default closed with allowances (invite list) | ||
+ | |||
+ | By default Slackware ships with both these files empty, this means the door is unlocked with no-one banned. | ||
+ | |||
+ | This document will guide you through changing that default open to a more secure default closed setup. | ||
+ | |||
+ | ===== Contents | ||
- Making sure you have a key yourself | - Making sure you have a key yourself | ||
- Locking the door | - Locking the door | ||
Line 11: | Line 26: | ||
- See also | - See also | ||
- | === Making sure you have a key yourself === | + | ===== Making sure you have a key yourself |
Line 23: | Line 38: | ||
</ | </ | ||
- | ===Locking the door=== | + | ===== Locking the door ===== |
This is simply done by editing **/ | This is simply done by editing **/ | ||
Line 31: | Line 46: | ||
Connections which are in use will still be usable, only new connections via ssh from 192.168.0.10 will be allowed. | Connections which are in use will still be usable, only new connections via ssh from 192.168.0.10 will be allowed. | ||
- | === Writing the guest list === | + | ===== Writing the guest list ===== |
- | == Adding a second host == | + | ==== Adding a second host ==== |
We have already allowed connections only to the sshd server from 192.168.0.10, | We have already allowed connections only to the sshd server from 192.168.0.10, | ||
Line 44: | Line 59: | ||
You may have just a space between them or add a comma for clarity. | You may have just a space between them or add a comma for clarity. | ||
- | == Adding lots of hosts == | + | ===== Adding lots of hosts ===== |
It is possible to allow blocks of addresses to connect by either shortening the address or using a netmask. | It is possible to allow blocks of addresses to connect by either shortening the address or using a netmask. | ||
< | < | ||
Line 59: | Line 74: | ||
</ | </ | ||
- | == Adding other services == | + | ===== Adding other services |
In the main, the name of the service you are connecting **TO** eg sshd, in.telnetd, vstfpd, proftpd should be placed in hosts.allow, | In the main, the name of the service you are connecting **TO** eg sshd, in.telnetd, vstfpd, proftpd should be placed in hosts.allow, | ||
Line 73: | Line 88: | ||
</ | </ | ||
- | === Talking to yourself === | + | ===== Talking to yourself |
Sometimes it's not a bad idea, for example the rndc process for reloading bind might be on the same machine running named, in this case we want to allow connections from the same machine we are on. | Sometimes it's not a bad idea, for example the rndc process for reloading bind might be on the same machine running named, in this case we want to allow connections from the same machine we are on. | ||
< | < | ||
Line 81: | Line 96: | ||
- | === Notes === | + | ===== Notes ===== |
This does not cover all the variations in grammar of these two files nor will it secure all services that open ports but should hopefully give you a taste of what can be done. | This does not cover all the variations in grammar of these two files nor will it secure all services that open ports but should hopefully give you a taste of what can be done. | ||
- | === See also === | + | ===== See also ===== |
man (5) hosts_access | man (5) hosts_access | ||
+ | |||
+ | |||
+ | <!-- Please do not add anything below, except additional tags.--> | ||
+ | <!-- However we request that you remove the tag-word " | ||
+ | |||
+ | <!-- Do not remove this line and the text below. Thanks! slackdocs@--> | ||
+ | {{tag> | ||
+ | |||
====== Sources ====== | ====== Sources ====== |