0

First of all, my sshd has got libwrap.so in it, here is the checking result:

root@FS9000:~# ldd sshd | grep libwrap
libwrap.so.0 => /usr/lib/libwrap.so.0 (0x000000555e3fa000)
  1. When I configured /etc/hosts.deny like this (there's no /etc/hosts.allow):

    sshd: ALL
    

    Then any IP will be blocked when try to access the server, it took effect obviously.

  2. When I configured /etc/hosts.deny like this:

    sshd: 192.168.1.30
    

    I tried to access the server from 192.168.1.30, and login succeeded without any block!

It seems that it cannot block the specified IP, which is very strange. What could the problem be?

PS: I tried it in embedded system, using busybox(v1.22.1), sshd is from openssh-6.3p1.


  1. All the test is base in the local network, here is the details for the connections by sshd. 192.168.1.30 is one linux client, 192.168.1.212 is the embedded system.

    root@FS9000:~# cat /etc/hosts.deny ALL: 192.168.1.30

    root@FS9000:~# env | grep SSH SSH_CLIENT=192.168.1.30 36425 22 SSH_TTY=/dev/pts/0 SSH_CONNECTION=192.168.1.30 36425 192.168.1.212 22

    root@FS9000:~# netstat -antp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1726/portmap tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 1770/vsftpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2359/sshd tcp 0 0 192.168.1.212:22 192.168.1.30:36425 ESTABLISHED 3256/0 tcp 0 0 :::22 :::* LISTEN 2359/sshd tcp 0 0 :::23 :::* LISTEN 2148/telnetd

4.When configure /etc/hosts.deny like this:

root@FS9000:~# cat /etc/hosts.deny
ALL:  ALL :\
       spawn (/bin/echo "%d connection to %N from %n[%a] denied" > /dev/pts/1)

pts/1 is one telnetd connection,telnetd doesn't support libwrap,so all telnetd connections won't be blocked. Then I tried access 1.212 from 1.30, it prints this(and of course it blocked successfully):

sshd connection to unknown from unknown[0.0.0.0] denied

When configure /etc/hosts.deny like this:

sshd: 192.168.0.0/24 127.0.0.1  [ffe0::]/10 [::1]

It still cannot block any IP in 192.168.0.0/24, 192.168.1.30 can also access it.

  • On what interfaces does SSHD listen to? How exactly did you try to connect to the SSH daemon? Are you sure the connection was made to the interface that receives connections from 192.168.1.30? – Tero Kilkanen Oct 12 '14 at 13:22
  • @Tero Kilkanen,please refer to my following reply for more connetions details. – Ryan.Xin Oct 13 '14 at 5:15
1

Perhaps you're not connecting to the sshd using the IP address 192.168.1.30.

You can make (some) ssh programs use a specific interface using -b

-b bind_address Use bind_address on the local machine as the source address of the connection. Only useful on systems with more than one address.

So try

ssh -b 192.168.1.30 user@remote.tld 
  • Please refer to my following answer for more details. – Ryan.Xin Oct 13 '14 at 2:40
0

If you are not connecting to a host on your local network, the address seen by sshd won't be 192.168.1.30 which can not be routed over the Internet. If you are connecting between hosts on a local network, most systems will try IPv6 first. IPv6 is not as easy to block on a per host basis, as hosts often are configured to use privacy extensions and change their IP address periodically.

If this is a host you have access to, then after connecting using ssh and check the IP address you are connecting from. sshd exports information about the connection to the environment. You can view this with the command env | grep SSH.

You may want to implement a mostly closed configuration. Keep a connection open while testing Configure /etc/hosts.deny to block all connections with a like this.

ALL:  ALL :\
       spawn (/bin/echo "%d connection to %N from %n[%a] denied" | \
      /usr/bin/mailx -s "Access Denied - %d" root@localhost)

Then allow access by service and/or network addresses. You can block by names returned by DNS PTR record look-ups as well as by addresses ranges. The following allows access from the local network only, but blocks the router from access.

sshd:   192.168.0.0/24 127.0.0.1 \
        [ffe0::]/10 [::1] \
        EXCEPT 192.168.0.1

You can add the email notification to accept rules as well. If you don't want the notifications, you can remove them. If your service does not log accesses, you can use a similar rule to log access by sending a message to the log daemon.

  • 1. I test it in the local network. – Ryan.Xin Oct 13 '14 at 3:18
  • @user248725 You addition shows the connection came from the address you are trying to block. However, tcp_wrappers won't drop existing connections. Can you create new connections with the rule in place? If so, it appears there may be a bug in the ssh daemon or tcp_wrappers you have installed. – BillThor Oct 13 '14 at 3:54
  • Of course, I always disconnect it and then change the /etc/hosts.deny(operate through telnetd, which won't be blocked anyway), and then create new connections. sshd version: openssh-6.3p1 libwrap version:/usr/lib/libwrap.so.0 -> libwrap.so.0.7.6 – Ryan.Xin Oct 13 '14 at 4:24
  • @Ryan.Xin Don't run telnetd, it is extremely insecure. Do the changes over SSH and keep that connection open. Test with a second connection. It appears there is a problem with the libwrap version installed. Try installing an older or newer version of libwrap. Check the bug reports for your distribution, this issue may have been reported already. You may try blocking 192.168.1.130/32 and watching the syslog as login. – BillThor Oct 13 '14 at 16:38
  • thanks for your reply. I tried 192.168.1.30/32, it didn't work, the log warn that the format is bad: warning: /etc/hosts.deny, line 1: bad net/mask expression: 192.168.1.30/32 I tried 192.168.1.30 or 192.168.1.0/255.255.255.0, nither of them can block 192.168.1.30, I will try another version of openssh. – Ryan.Xin Oct 14 '14 at 1:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.