Troubleshooting Access Issues

It is possible to have too much security. Any security measure that is keeping users from needed services is probably doing more harm than good.

If your users need a service and your security measures block the use of that service, you need to make a choice. You can either provide an acceptable substitute, or you can relax your security measures in some way.

Sometimes, users may tell you that something is not working when it is really an issue with your security. For example, the iptables DROP option can lead to output that is confusing to users.

Too Much Security

Security is not helpful if it keeps users from getting their work done. However, some services are sufficiently dangerous that you need to provide your users with alternatives.

For example, if a user wants to connect to a remote computer via Telnet, it s probably in your best interest to help that user learn about the Secure Shell utilities described in Chapter 23 . You generally don t want users sending their user passwords in clear text over the network.

Another example is with the Network File System (NFS), which is detailed in Chapter 28 . NFS requires access to several different TCP/IP services: nfs , portmap , rpc. mountd , and rpc.nfsd . While NFS uses TCP/IP port 2049, standard Red Hat Linux firewalls also block port 111, which is associated with the RPC daemon.

Denial or Rejection

When users try to access a prohibited service, what they see depends on iptables , specifically the DROP or the REJECT option. For example, you could implement either of the following chains to stop users on the 192.168.0.0/24 network from connecting via Telnet:

 # iptables -A INPUT -s 192.168.0.0/24 -p tcp -dport 23 -j DROP # iptables -A INPUT -s 192.168.0.0/24 -p tcp -dport 23 -j REJECT 

Tip  

Port 23 is the TCP/IP port for Telnet service. You can look up standard TCP/IP ports in /etc/services .

Now compare what a user on the 192.168.0.0/24 network sees when she tries to connect via Telnet to a server that is set to DROP a request:

 #  telnet RHL9  Trying 192.168.0.34 

A user who sees this output may complain to you that Telnet is not working. Now contrast that with the output for someone who is trying to connect to a server that is set to REJECT a request:

 #  telnet RHL9  Trying 192.168.0.34 telnet: connect to address 192.168.0.34: Connection refused 

A user who sees this is more likely to understand that Telnet connections aren t allowed on server RHL9. When the user asks you why, you have an opportunity to educate your user about alternatives such as SSH.