Debian 9 ProFTPD iptables configuration

Я попытался привязать mount для решения проблемы при установке некоторых пакетов с помощью pacman (archlinux, подробнее об этом здесь ) в системе, где / var ( а также / home и / usr / local ) были символическими ссылками (между файловыми системами: от SSD к SATA).

Сначала это выглядело великолепно, но, как заметил Жиль, locate всегда давал несколько результатов для одного файла, несмотря на строку PRUNE_BIND_MOUNTS = "yes" в /etc/updatedb.conf.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Копнув немного дальше, я обнаружил, что более сложные привязки монтирования могут быть обрезаны правильно:

$ sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Без параметра PRUNE_BIND_MOUNT я бы получил 3 результата:

$ sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Другая проблема с привязками:

. Конечно, можно вручную добавить привязку (mounpoint или target) к PRUNEPATHS в /etc/updatedb.conf .

Кроме того, точка монтирования и различные команды или функции stat могут использоваться в инструментах для улучшения обхода файловой системы , как предлагается здесь

0
06.07.2018, 08:37
1 ответ

На самом деле, ваш набор правил должен подойти для исходящих пакетов. :Проблема в том, что входящие ответы на эти пакеты отклоняются.

Основная проблема в этой строчке:

-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 20:65535 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Например, когда вы пытаетесь запустить обновление пакета, инструмент aptотправит соединение с зеркальным сервером Debian, обычно через порт назначения 80 для HTTP. Исходный порт будет случайным старшим портом (, определенно выше 1024, скажем, 12345 ).

Ответ на этот пакет будет возвращен с зеркала Debian с перевернутыми номерами портов источника и получателя :номер порта источника ответа будет 80, а номер порта назначения будет 12345.

Но ваше входящее правило не будет соответствовать входящим пакетам с исходным портом ниже 1024, независимо от того, являются ли они новыми или уже -установленными соединениями. В результате вы отправляете запросы на подключение к порту 80, но глухи к любым ответам, приходящим с него.

В качестве первых двух правил ввода я бы рекомендовал следующее:

-A INPUT -i lo -j ACCEPT    # accept anything from the loopback interface
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

Вторая строка принимает любые допустимые входящие ответы на любые исходящие соединения и все, что с ними связано (, например. пакет ошибок ICMP, сообщающий вам, что не так с конкретной попыткой подключения ). Если активирован соответствующий специальный помощник по отслеживанию соединений для FTP, эта строка также позаботится о FTP-соединениях для передачи данных, как активных, так и пассивных. Читайте дальше...

(Используемое вами соответствие -m stateустарело и становится устаревшим; мой -m conntrack --ctstate ESTABLISHED,RELATEDв основном является его обновленной версией.)

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

Итак, сообщите системе, что мы ожидаем, что любые входящие подключения из вашей сети к вашему TCP-порту 21 будут действительными контрольными соединениями FTP:

-t raw -A PREROUTING -p tcp -s yyy.yyy.yyy.yyy/25 --dport 21 -j CT --helper ftp

Когда установлено входящее управляющее FTP-соединение, помощник FTP conntrack будет отслеживать любые команды передачи файлов, выданные в нем, и автоматически информирует подсистему conntrack о любых связанных FTP-соединениях для передачи данных, так что ранее «УСТАНОВЛЕНО, СВЯЗАННО» правило будет принимать их и только их :больше нет необходимости держать широкий диапазон портов открытыми для потенциальных FTP-соединений!

Когда используется помощник FTP conntrack, вам больше не нужны ни правила для порта 20, ни правила с --sport 1024:65535или --dport 20:65535.

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

Если вы используете FTP-зеркала для обновлений Debian,вам понадобится аналогичная обработка для любых исходящих FTP-соединений. Это можно сделать с помощью:

-t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp
0
28.01.2020, 04:18

Теги

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