[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.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
howtos:security:inetd [2012/09/22 21:09 (UTC)] – moved the page from security:inetd namspace mfillpothowtos:security:inetd [2012/09/23 03:25 (UTC)] (current) – removed excess tags 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, hosts.deny ====== 
 + 
 + 
 +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, these two files can be used to create either  
 +  * 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:
 </code> </code>
  
-===Locking the door===+===== Locking the door =====
  
 This is simply done by editing **/etc/hosts.deny** and adding the line This is simply done by editing **/etc/hosts.deny** and adding the line
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, if we want to allow a second host to connect, it is as simple as We have already allowed connections only to the sshd server from 192.168.0.10, if we want to allow a second host to connect, it is as simple as
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.
 <code> <code>
Line 59: Line 74:
 </code> </code>
  
-== 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, but as with all things there are exceptions... NFS, with NFS we are making rules for what services we are allowing connections **FROM**. In the main, the name of the service you are connecting **TO** eg sshd, in.telnetd, vstfpd, proftpd should be placed in hosts.allow, but as with all things there are exceptions... NFS, with NFS we are making rules for what services we are allowing connections **FROM**.
  
Line 73: Line 88:
 </code> </code>
  
-=== 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.
 <code> <code>
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
 +
  
 ====== Sources ====== ====== Sources ======
 howtos:security:inetd ()