Настройка аутентификации на оборудовании Juniper SRX

Значительный рост функционала современных мобильных устройств с одновременным увеличением их доступности, открывает замечательные возможности для гибкого ведения бизнеса. Поэтому неудивительно, что при построении IT-инфраструктуры компании  учет концепции BYOD (Bring Your Own Device) становится стандартом индустрии. 

При этом важно не только обеспечить  качественную Wi-Fi инфраструктуру, которая способна эффективно обслуживать маломощные мобильные устройства, но и качественно решить вопросы, связанные с безопасностью.

Обеспечение аутентификации пользователей – один из них. Необходимо аутентифицировать именно пользователей (а не конкретное устройство), с возможностью применения к ним различных политик в зависимости от точки входа в сеть. При этом аутентификация не должна вызывать неудобств у пользователей и лишней головной боли у администраторов. Оборудование линейки SRX компании Juniper Networks позволяет решить эту задачу гибко и  без привлечения сторонних средств (но при желании, можно подключать и сторонние службы – поддерживается RADIUS, LDAP и SecurID). В сегодняшней статье мы покажем, как это сделать.

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

В JunOS зоны конфигурируются путем объединения интерфейсов SRX (необходимо помнить, что нельзя объединять интерфейсы, находящиеся в различных routing-instances) и создания адресной книги для подсетей/хостов внутри зоны (понадобятся при настройки политик, так что названия не должны пересекаться). Так же при создании зон, если это необходимо, указывается host-inbound-traffic, – т.е. тип трафика, по которому будет доступен наш SRX в пределах зоны или интерфейса в ней. Конфигурация зон на примере Workgroup зоны:

[edit security zones]

security-zone Workgroup_Zone {

address-book {

address --Decktops-- X.X.X.X/mask;   "пулы адресов для устройств"

address --IP_Phones-- X.X.X.X/mask;

}

host-inbound-traffic {

system-services {

dhcp;

                                   }

                        }         

interfaces {

ge0/0/2.0;

 }

}         

Теперь необходимо задать политики для транзитного трафика между зонами (по умолчанию не передается, но локальный трафик внутри зоны разрешен); при этом надо помнить, что SRX использует flow-based forwarding, т.е. политика описывает не явно передаваемый трафик, а возможность открыть сессию для его передачи.

Пусть политики описаны следующим образом:

Workgroup -> Serv разрешен весь трафик;

Workgroup -> Management – только snmp;

Workgroup -> Internet & WiFi весь трафик запрещен – просто не описываем политику.

WiFi -> Internet разрешен ftp и http трафик (вопрос web-фильтрации нас сегодня не интересует);

WiFi -> Management – только snmp;

WiFi -> Serv – разрешен только трафик на ftp- и mail-сервера;

WiFi -> Workgroup – трафик запрещен – не описываем политику;

Из зоны Management разрешен весь исходящий трафик;

Из зоны internet все запрещено – не описываем политику.

В качестве примера приведу конфиг политик для WiFi зоны:

[edit security policies]

from-zone WiFi_Zone to-zone Serv_Zone {

            policy num1 {

                                   match {

                                   source-address any;

                                   destination-address  --ftp_server--;

                                   application junos-ftp;

                        }

                        then {

                                   permit ;

                                   log {

                                       session-init;

                                               session-close;

                                   }

}

from-zone WiFi_Zone to-zone Internet_Zone {

            policy num1 {

                                   match {

                                   source-address any;

                                   destination-address  any;

                                   application {

junos-ftp;

junos-http;

                                   }

                        then {

                                   permit ;

                                   log {

                                       session-init;

                                               session-close;

                                   }

}

from-zone WiFi_Zone to-zone Management_Zone {

            policy num1 {

                                   match {

                                   source-address any;

                                   destination-address  --snmp_serv--;

                                   application {

junos-snmp;

                                   }

                        then {

                                   permit ;

}

 

Далее приступим к аутентификации. Очевидно, что необходимо создать базу учетных записей сотрудников компании, а так же гостевую запись для зоны WiFi (для нее необходимо ужесточить политику, но этот вопрос мы здесь не рассматриваем). Например:

[edit access]

 profile employee {

client Ivan_Ivanovich {

client-group [group1 group2];

firewall-user {

password ….;

}

}

client Petr_Petrovich {

client-group [group1];

firewall-user {

password ….;

}

}

client guest {

client-group [group2];

firewall-user {

password ….;

}

Client-group в JunOS служит для определения точек входа в сеть клиентов и задания при этом специфичных политик. В нашем случае group1 соответствует Workgroup, а group2 – WiFi зоне, т.о. Иван Ивановичу можно пользоваться сетью как с рабочего места, так и через  WiFi со своих мобильных устройств, Петру Петровичу запрещено использование WiFi, гостевая учетная запись сработает только в WiFi зоне. Идентификатор client-group должен быть уникален.

В качестве метода аутентификации используем web-redirect-authentication - при попытке передать трафик, пользователь будет переадресован на web-интерфейс SRX и должен будет ввести учетные данные. По умолчанию hold-time сессий составляет 30 минут. Web-redirect требует наличия web-authentication:

[edit access firewall-authentication]

web- authentication {

default-profile employee;      "база учеток сотрудников"

 banner {

Success “rock-and-roll!”;

Fail “sorry((”;

}

,и конфигурируется внутри существующих политик. Например для доступа в Internet с рабочих станций и через WiFi:

[edit security policies from-zone WiFi_Zone to-zone Internet_Zone policy num1]

                        then {

                                   permit  {

firewall-authentication {

pass-throught {

clent-match group2;

            web-redirect;

}

                                   log {

                                       session-init;

                                               session-close;

                                   }

}

 

[edit security policies from-zone Workgroup_Zone to-zone Internet_Zone policy num1]

                        then {

                                   permit  {

firewall-authentication {

pass-throught {

clent-match group1;

            web-redirect;

}

}

}

                                   log {

                                       session-init;

                                               session-close;

                                   }

Чтобы включить web-интерфейс SRX необходимо глобально подключить http сервис и, желательно, задать дополнительный адрес для http доступа на интерфейсе в сторону клиента:

[edit system services]

web-management {

http;

}

[edit interfaces ge-0/0/2 unit 0]

family inet {

address 10.210.14.171/28 {

preferred;

}

address 10.210.14.168/28 {

web-authentication http;

}

Далее не забываем сделать commit. Все, аутентификация настроена.

Команды для мониторинга:

>show security firewall-authentic users    "покажет текущие сессии аутентифицированных пользователей"

>show security firewall-authentic history  "покажет всю историю аутентификаций"

Скажу пару слов о способах внешней аутентификации. Например, существует необходимость подключить RADIUS. Для этого просто создаем новый client-profile, где указанием адреса сервера и пароля доступа к нему, а также «запасного» метода аутентификации в случае недоступности внешнего сервера:

[edit access profile –radius--]

authentication-order [radius password];

radius-server {

ip-address secret radius-secret;

}

JunOS невероятно гибок и все его возможности, даже по такой небольшой теме, как аутентификация, описать внутри одной статьи просто нереально! Поэтому, если у вас возникли вопросы по решениям Juniper Networks в области безопасности и их конфигурировании, обращайтесь на Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра. , наши специалисты всегда придут на помощь!