services - IPs in hosts.deny only block ssh

08
2014-07
  • Tik0

    I am running a small server where I want to block some special IPs using /etc/hosts.deny. If I make an entry like

    ALL: <IP>
    

    only the ssh service will be blocked for IP. All the others services like ftp, http etc. are still reachable by IP. Doesn't the host.deny file define global rules?

  • Answers
  • JdeBP

    /etc/hosts.deny and /etc/hosts.allow are part of TCP-Wrapper, a program developed to deny access to hackers by Wietse Venema in the nineties.

    TCP wrappers controls TCP access of processes run from /etc/inetd.conf. Most modern Linux distros (all Debian-based, Arch Linux,...) do not have inetd any longer.

    Some applications are yet controlled by TCPwrapper, because they are compiled with the libwrap library, and are thus tcpwrapper-aware even if they are not run from /etc/inetd.conf. These applications include, to the best of my knowledge, telnet, ssh, sendmail, pop3, and stunnel.

    You can check whether your application is tcp-wrapper-aware by means of the strings command:

     # strings /usr/sbin/sshd|grep hosts_access
     hosts_access
    

    or by means of ldd:

     # ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f7059e7a000)
    

    The correct way, nowadays, to bar intruders from accessing your system, is to use iptables:

      iptables -A INPUT -s 11.22.33.44 -j DROP
    
  • arco444

    From memory hosts.allow / hosts.deny are only read by sshd. You'll need to set up a firewall to restrict other services.

  • Chris S

    Only services that use the tcpd wrapper or sshd, itself, pay attention to hosts.deny and hosts.allow. Most services utilize either their own TCP wrapper or the x?inetd wrapper.

    Soure: http://its.virginia.edu/unixsys/sec/hosts.html

    P.S., Some time ago I came across a note saying xinitd can be compiled to support libwrap (or something that that affect) which uses hosts.deny/allow.


  • Related Question

    connection - ssh - no route to host
  • cupakob

    I have 3 machines (A, B and C) behind WLAN Router. From B i can make ssh to A and from A to B also. Ssh between C and A is also working (both destination, C->A and A->C). But when i try to connect B to C or C to B i get always

    ssh: connect to host <HOST> port 22: No route to host
    

    What can be the reason for this error?

    edit: I've made small mistake - machine A has wired connection to the router!

    @ Marnix A. van Ammers: Here the three ifconfig outputs:

    Machine A:

    $ ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:74:b8  
              inet addr:192.168.0.9  Bcast:192.168.0.255  Mask:255.255.255.0
              inet6 addr: fe80::211:95ff:fe1c:74b8/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:4602075 errors:0 dropped:0 overruns:0 frame:0
              TX packets:8746230 errors:0 dropped:0 overruns:13 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:816857533 (816.8 MB)  TX bytes:2974068829 (2.9 GB)
              Interrupt:11 Base address:0x1800 
    

    Machine B:

    $ ifconfig wlan0
    wlan0     Link encap:Ethernet  Hardware Adresse XX:XX:XX:XX:f8:7a  
              inet Adresse:192.168.0.5  Bcast:192.168.0.255  Maske:255.255.255.0
              inet6-Adresse: fe80::21b:77ff:feb6:f87a/64 Gültigkeitsbereich:Verbindung
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
              RX packets:39449 errors:0 dropped:0 overruns:0 frame:0
              TX packets:36805 errors:0 dropped:0 overruns:0 carrier:0
              Kollisionen:0 Sendewarteschlangenlänge:1000 
              RX bytes:28118658 (28.1 MB)  TX bytes:5681482 (5.6 MB)
    

    Machine C:

    $ ifconfig wlan0
    wlan0     Link encap:Ethernet  Hardware Adresse XX:XX:XX:XX:a7:b5 
              inet Adresse:192.168.0.8  Bcast:192.168.0.255  Maske:255.255.255.0
              inet6-Adresse: fe80::226:b6ff:fe4e:a7b5/64 Gültigkeitsbereich:Verbindung
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
              RX packets:12 errors:0 dropped:0 overruns:0 frame:0
              TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
              Kollisionen:0 Sendewarteschlangenlänge:1000
              RX bytes:1611 (1.6 KB)  TX bytes:5613 (5.6 KB)
    

    The netstat outputs:

    Machine A:

    $ netstat -nr
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
    0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
    

    Machine B:

    $ netstat -nr
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
    192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
    169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 wlan0
    0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlan0
    

    Machine C:

    $ netstat -nr
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface
    192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
    169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 wlan0
    0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlan0
    

  • Related Answers
  • Spiff

    It seems likely that multicast is not working reliably on your wireless network, and that's breaking ARP. Look at your ARP tables on B and C to see if either host is missing an ARP mapping for the other. Try adding it manually and see if the problem goes away. Then you can troubleshoot your wireless network's multicast problems later.

  • dad

    As original poster didn't explain what "router settings caused the problem", I do it:

    Some wireless routers have settings to keep stations connected wirelessly isolated.

    Let's take TP-LINK TL-WR740N (V1 or V2) as an example.

    On the "Wireless Advanced" page of the web-based management that model has checkbox "Enable AP Isolation" explained as:

    Enable AP Isolation - Isolate all connected wireless stations so that wireless stations cannot access each other through WLAN.

  • Mox

    Check the network settings for machine C.

    If you are using DHCP (dynamically assigned IP addresses) for machines A and B, then you probably want to configure machine C to use DHCP also.

    If you are using static IP addressing, make sure that machine C has a proper IP address (most likely, this means an IP address on the same subnet as machine A and machine B, since you haven't mentioned any other complexities in your network).