Назад | Перейти на главную страницу

BIND9: объединение ключа и ACL для разрешения-обновления

Я установил сервер BIND 9 и настроил криптографические ключи, чтобы разрешить обновления от клиента. Теперь в моем named.conf, Я установил следующее:

allow-update { key dns1.example.org.; };

Это работает, и я могу выполнять обновления (добавлять, удалять записи зоны) с моего клиента (nsupdate команда).

Мне интересно, могу ли я объединить его с ACL. В основном я хочу, чтобы клиенту нужен был правильный ключ, но он также должен исходить из определенной подсети или IP-адреса. Могу я как-нибудь это сделать? Я не нашел ничего об этом сценарии в документации.

Alcs - первый матч. Если вы исключите нужные адреса, вы можете отклонить все несовпадающие адреса, используя любые; затем проверьте соответствие ключа.

   allow-update { !{ !allowed; any; }; key keyname; };

Уродливый ответ # 1

Вы можете сделать это только в том случае, если хотите быть творческими, уродливыми и грубыми.

Разрешить обновления только с 1.2.3.0/24 с ключом dns1.example.com.

acl “mix-match” {
! 128.0.0.0/1;
! 64.0.0.0/2
! 32.0.0.0/3
! 16.0.0.0/4
! 8.0.0.0/5
! 4.0.0.0/6
! 2.0.0.0/7
! 0.0.0.0/8     //0 instead of 1 since bit is set in the desired network
! 1.128.0.0/9
! 1.64.0.0/10
! 1.32.0.0/11
! 1.16.0.0/12
! 1.8.0.0/13
! 1.4.0.0/14
! 1.0.0.0/15    //0 instead of 2 since bit is set in the desired network
! 1.3.0.0/16    //1-st bit = 1: we DENY hosts with 1.3.0.0/16 but allow 1.2.0.0/16
! 1.2.128.0/17
! 1.2.64.0/18
! 1.2.32.0/19
! 1.2.16.0/20
! 1.2.8.0/21
! 1.2.4.0/22
! 1.2.0.0/23    //0 instead of 2 since bit is set in the desired network
! 1.2.2.0/24    //1-st bit = 9: we DENY hosts with 1.2.2.0/24 but allow 1.2.3.0/24

key dns1.example.com.;
};

Как выполнить побитовую математику:

  1. Для подсети / X вам нужно X строк.
  2. Преобразуйте IP подсети в двоичную форму.
  3. Вы начинаете с 1-го бита - если в разрешенной подсети установлен этот бит, вы запрещаете правило, оно будет очищено, а если в разрешенной подсети бит равен 0, тогда ваше правило будет отклонять этот бит.
  4. Для правила №N первые биты N-1 такие же, как в желаемой маске подсети, бит N соответствует описанию в шаге 3.

На самом деле я не пробовал, но должно работать.

Если у вас несколько разрешенных подсетей, желаю вам удачи.

В связи с этим я рад, что IPv6 еще не получил широкого распространения. :)

Уродливый ответ # 2

Установить отдельно скрытность (т.е. не указан как NS) основной главный сервер имен, в его правилах брандмауэра разрешены пакеты только из "разрешенной" подсети и с его подчиненных серверов имен. В этом режиме разрешите обновления только с помощью ключа. Настройте ведомые устройства для получения данных зоны через AXFR / IXFR и NOTIFY. И не забудьте отключить пересылку обновлений на ведомых устройствах.

Однажды вы сделали это ужасно, имейте в виду, что кто-нибудь из везде может подменить адрес источника в этом пакете обновления UDP DNS, что делает все эти усилия совершенно бессмысленными. (Хотя вы можете отключить UDP, чтобы сделать усилия немного менее бессмысленными).

Я знаю, что вы можете определить match_list, но я не уверен, что вы можете объединить ключ и список совпадений. 

allow-update { address_match_list };

например:

options {
    allow-update { !192.168.2.7;192.168.2/24;};
};

Я не пробовал это, но, насколько я понимаю, определения следующие:

address_match_list = element ; [ element; ... ]
element = [!] (ip [/prefix] | key key-name | "acl_name" | { address_match_list } )

и поэтому вы можете делать такие вещи, как

acl “mix-match” {
“two-subnets”;
! 10.10.30.101;
10.10.30.0/24;
key dns1-dns2.example.com;
};
zone "abc.def.example.com" in {
        type master;
        file "named.abc.data";
        allow-update{ mix-match };
};

и поэтому передача зон теперь ограничена теми, у которых есть ключ (вне списка совпадений).