Ubuntu принимает соединение SSH, когда это должно отклонить его (неправильный IP для интерфейса)

РЕЗЮМЕ

Мой VM Ubuntu (имя хоста fubar) делает IP-адрес (eth0 169.254.32.15) одного интерфейса видимый к хостам достижимый другим интерфейсом (eth1 10.3.17.129/23).

Я хочу "ssh, чтобы user@169.254.32.15" от машин на 10.3.16.0/23 не соединился с fubar.

Подробнее

интерфейсы на моем VM Ubuntu:

root@fubar:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 4e:12:0f:0b:48:91  
      inet addr:169.254.32.15  Bcast:169.254.63.255  Mask:255.255.224.0
      inet6 addr: fe80::4c12:fff:fe0b:4891/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:648 (648.0 B)

eth1      Link encap:Ethernet  HWaddr 92:fe:57:11:bd:6c  
      inet addr:10.3.17.129  Bcast:10.3.17.255  Mask:255.255.254.0
      inet6 addr: fe80::90fe:57ff:fe11:bd6c/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:2471362 errors:0 dropped:0 overruns:0 frame:0
      TX packets:71144 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:337482223 (337.4 MB)  TX bytes:5136143 (5.1 MB)

lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:16 errors:0 dropped:0 overruns:0 frame:0
      TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:1184 (1.1 KB)  TX bytes:1184 (1.1 KB)

root@fubar:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.3.16.1       0.0.0.0         UG    0      0        0 eth1
10.3.16.0       0.0.0.0         255.255.254.0   U     0      0        0 eth1
169.254.32.0    0.0.0.0         255.255.224.0   U     0      0        0 eth0
root@fubar:~# uname -a
Linux fubar 3.19.0-80-generic #88~14.04.1-Ubuntu SMP Fri Jan 13 14:54:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

root@fubar:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:5617            0.0.0.0:*               LISTEN     
tcp        0      0 169.254.32.15:5617      10.3.17.28:50841        ESTABLISHED
tcp        0      0 10.3.17.129:5617        10.3.16.65:38753        ESTABLISHED
tcp6       0      0 :::5617                 :::*                    LISTEN     
udp        0      0 0.0.0.0:9797            0.0.0.0:*                          
udp        0      0 0.0.0.0:68              0.0.0.0:*                          
udp6       0      0 :::1269                 :::*                               

eth1 предназначается для внешнего направления. Eth0 подключен к другому VM (и ничто иное) через виртуальный мост.

Нежелательное поведение состоит в том что, когда я ssh от другого VM (10.3.17.28) к 169.254.32.15 это успешно соединяется с fubar (см. вывод netstat выше). Как я могу мешать этому произойти?

Интерфейсная статистика показывает, что пакеты для этого SSH на самом деле пробегаются через eth1. Очевидно, fubar делает 169.254.32.15 видимых к 10.3.16/23 сети, но я не знаю почему.

Почему это происходит? Как я могу мешать ему произойти?

EDIT1: данные iptables собраны согласно просьбе

root@fubar:~# iptables -v -x -n -L 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         
root@fubar:~# iptables -t nat -v -x -n -L 
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts      bytes target     prot opt in     out     source               destination         
root@fubar:~#
0
задан 3 September 2018 в 17:26

1 ответ

Кажется от Вашего вопроса, что sshd слушает во всех интерфейсах на порте TCP/5617. Таким образом, я рекомендовал бы редактировать Ваш/etc/ssh/sshd_config. SSHD может быть настроен для слушания на определенных IP-адресах, которые, если они статичны, можно трудно кодировать в/etc/ssh/sshd_config файл. Если существует строка, которая читает

listenAddress 0.0.0.0

измените его на ниже. Если это не существует, просто добавляют ниже:

listenAddress 10.3.17.129

При использовании ipv6 Вы могли бы хотеть также измениться

ListenAddress ::

кому:

ListenAddress fe80::90fe:57ff:fe11:bd6c

Однако, если бы этот сервер настроен для DHCP, и Вы предпочитаете его тот путь, затем я, вероятно, обратился бы к iptables, как Doug рекомендовал. Существует пара способов выполнить это в зависимости от того, что Вы на самом деле хотите заблокировать.

Если Вы хотите заблокировать ssh, прибывающий из 10.3.16.0/23 сети в интерфейс eth0 (ОТКЛОНЕНИЕ изменения, чтобы ОТБРОСИТЬ, если Вы волнуетесь по поводу тайных нападений/сканирований, иначе ОТКЛОНЯЕТЕ сбои быстрее):

iptables -A INPUT -i eth0 -m tcp -p tcp --dport 5617 -s 10.3.16.0/23 -j REJECT

Если Вы хотите заблокировать весь трафик из этой сети, входя в этот интерфейс:

iptables -A INPUT -i eth0 -s 10.3.16.0/23 -j REJECT

После того как Вы добавляете правило своего выбора, тест, чтобы удостовериться, что это имеет желаемый эффект, если это, сделайте это постоянным с:

service iptables save

Та команда может варьироваться в зависимости от того, какую версию Ubuntu Вы выполняете.

Я все еще не знаю, почему это произошло бы без более глубокого поиска и устранения неисправностей, я предложу проверить вывод

cat /proc/sys/net/ipv4/ip_forward

И удостоверяясь это - нуль, если Вы не намереваетесь для этого VM направить между этими сетями. Для фиксации этого добавьте следующую строку к нижней части/etc/sysctl.d/99-sysctl.conf

net.ipv4.ip_forward=0
0
ответ дан 28 October 2019 в 02:55

Другие вопросы по тегам:

Похожие вопросы: