UFW - порты открываются, хотя и закрыты по умолчанию Deny
Я абсолютно Newbee до Ubuntu и UFW. Я хочу закрыть все, кроме модифицированного порта SSH. Поэтому я настроил UFW, как это:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
и ...
sudo ufw status verbose
дает:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
2222/tcp ALLOW IN Anywhere
2222/tcp (v6) ALLOW IN Anywhere (v6)
Для моего удивления я все еще могу получить доступ к контейнерам Docker со случайными номерами портов?! Я что-то пропустил? Для моего понимания «входящий» трафик означает доступ к порту веб-серверов снаружи?
Система также была перезапущена после настройки UFW.
Другой чек с ...
nmap -p8888 example.com
дает этот вывод:
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-05 20:48 CET
Nmap scan report for example.com (XXX.XXX.XXX.XXX)
Host is up (0.10s latency).
PORT STATE SERVICE
8888/tcp filtered hosts2-ns
Nmap done: 1 IP address (1 host up) scanned in 1.20 seconds
Спасибо за вашу помощь.
1 ответ
Это по дизайну.
Когда вы тестируете на локальной машине, система будет напрямую отправлять на «интерфейс» сетевой трафик.
Например, это моя система с контейнерами LXD в подсети под названием «InternalDHCP»:
2: wlp59s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 172.18.1.0/16 brd 172.18.255.255 scope global dynamic noprefixroute wlp59s0
5: InternalDHCP: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.73.252.1/24 scope global InternalDHCP
valid_lft forever preferred_lft forever
, если я отправляю любой трафик в подсеть LXD здесь 10.73.252.1, и у меня нет правил капель в Цепь ввода, чтобы заблокировать трафик к этой подсети, то маршруты подчиняются. Таблица маршрутизации выглядит так, чтобы эти два интерфейса:
default via 172.18.0.1 dev wlp59s0 proto dhcp metric 600
10.73.252.0/24 dev InternalDHCP proto kernel scope link src 10.73.252.1
172.18.0.0/16 dev wlp59s0 proto kernel scope link src 172.18.1.0 metric 600
в основном, что это означает, что в первую очередь речь:
- , если входные и выходные сети не имеют никаких правил, отпускающих трафик на IP-адрес назначения, подчиняются правилам маршрутизации.
- Если пункт назначения находится в подсети 172.18.0.0/16: Отправьте напрямую через ссылку устройства
WLP59S0 - , если пункт назначения составляет 10.73.252.0/24 подсети: отправьте непосредственно через
InternaldHCPУстройство ссылки - Для всего другого трафика маршрут трафика до назначения через 172.18.0.1 (маршрутизатор).
Итак, если я пинга 10.73.252.25 (который является контейнером в моей системе, запущенном изображение системы Debian), то, поскольку у меня нет правила, запрещающего передачу или получателя из этой подсети в выходе и входных правилах в iPtables , он берет пакет пинга и падает непосредственно на устройстве / мосту InternalDHCP на моем компьютере и обходит все другое поведение.
Это было бы аналогично моему Pinging 127.0.0.1 (localhost) в том, что он никогда не покидает систему и по умолчанию UFW установка, вы не будете запрещены, чтобы добраться до местных подсюда (будь то физически на вашем Network / WiFi или ли они виртуальные и существуют исключительно на вашем компьютере) и как таковой никогда не заблокирован.
Правило входящего ufw ufw uf neny предназначено для пакетов, происходящих из-за пределов прямых сетевых подключений вашего устройства, в котором не было добавлено никаких правил разрешений - но какой докер использует правила UFW, чтобы позволить вашему устройству общаться с Контейнеры, не влияющие на ваш трафик (прозрачно!) И именно поэтому вы все еще можете добраться до вашего внутреннего устройства (и почему при отправке выводов на другие устройства вы получаете сообщения обратно, установленный трафик разрешен под капотом). (LXD делает подобное поведение, позволяющее общаться с мостами на моем компьютере)