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

Настройка аутентификации на оборудовании 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]

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

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

Теперь необходимо задать политики для транзитного трафика между зонами (по умолчанию не передается, но локальный трафик внутри зоны разрешен); при этом надо помнить, что 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 <

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]

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

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

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

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

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

[edit system services]

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

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

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

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

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

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

[edit access profile –radius--]

authentication-order [radius password];

ip-address secret radius-secret;

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

Инструкция по пробросу портов на Juniper SRX

Этой статьей я планирую открыть серию мануалов по Juniper серии SRX. Если это кому-то будет полезно – буду очень рад. И не стесняйтесь задавать вопросы.

Отмечу, что все ниженаписанное, скорее всего, будет подходить и к любой другой модели маршрутизаторов от Juniper (вследствие их слогана «One Junos», то есть одна операционка на все железяки). Данная статья основана на официальном англоязычном мануале по настройке NAT, взятом отсюда: www.juniper.net/us/en/local/pdf/app-notes/3500151-en.pdf .

Итак, проброс портов. Или по-научному, destination NAT. Тут надо сделать одно небольшое замечание. Некоторые админы привыкли под словом NAT понимать source NAT, со всеми вытекающими. И даже не source NAT, а одну из его разновидностей — PAT. Но надо понимать отличия между разными видами ната. Здесь я не буду вдаваться в теорию, на википедии все достаточно понятно написано. Я хочу сделать лишь одно пояснение: NAT – это всего лишь подмена адресов, ничего больше. Если вы понимаете суть этой технологии по-другому, вы неправы. Ничего больше, чем замена одного адреса в заголовке IP-пакета другим, эта технология не делает. И ничего изначально страшного и ужасного в ней нет. Соответственно, если мы говорим о destination NAT, то речь идет о подмене адреса назначения. Рассмотрим пример:

Допустим, у нас есть внутренний сервис (веб-сервер, адрес 10.1.1.100), который мы хотим сделать доступным извне по нашему внешнему адресу (1.2.3.4 порт 80). Пишем:

root@jsrx# edit security nat destination

Этим самым мы попали в раздел конфигурации destination NAT. Сперва необходимо создать адресную запись (pool) нашего веб-сервера.

root@jsrx# set pool web-server address 10.1.1.100 port 80

Далее создаем rule-set, т.е. свод правил дестинейшн ната:

root@jsrx# set rule-set DNAT from zone untrust

Этим самым мы говорим, что данный свод правил работает для пакетов, пришедших из зоны untrust, т.е. в нашем случае из Интернета. В данном примере все хорошо, но иногда может потребоваться указать, с какого конкретно интерфейса должны приходить пакеты для данного свода правил. В этом случае фразу from zone untrust нужно заменить на from interface ge-0/0/0 (как в нашем примере). Можно также указать источником пакетов routing-instance. но это более редкий случай, мы не будем о нем думать.
Данный rule-set надо наполнить нужными правилами:

root@jsrx# set rule-set DNAT rule dnat_for_web match destination-address 1.2.3.4
root@jsrx# set rule-set DNAT rule dnat_for_web match destination-port 80
root@jsrx# set rule-set DNAT rule dnat_for_web then destination-nat pool web-server

В первой строке мы указываем наш внешний IP-адрес, на который будут стучаться клиенты. Во второй строке мы указываем внешний порт, а в третьей – собственно сам пул, который мы описали вначале.
Если все оставить так, как есть, то ничего не будет работать. Потому как надо создать политику доступа к нашему веб-серверу:

root@jsrx# top edit security address-book global
root@jsrx# set address web_server 10.1.1.100
root@jsrx# top edit security policies from-zone untrust to-zone trust
root@jsrx# set policy web_access match source-address any
root@jsrx# set policy web_access match destionation-address web_server
root@jsrx# set policy web_access match application any
root@jsrx# set policy web_access then permit

Делаем commit check. затем, если все прошло нормально – commit
На этом настройка destination NAT’a завершена, все достаточно просто. Итоговый конфиг приведен ниже:

Несколько ценных дополнений.
1. Для каждого пробрасываемого порта необходимо писать данные правила (политики нужно писать только для новых добавляемых серверов). Невозможно пробросить диапазон портов одной командой. А жаль, порой хочется.
Если вам позарез необходимо пробросить дофига и больше портов, может быть стоит посмотреть в сторону Static NAT.
2. Имена правил не должны повторяться в пределах всей конфигурации NAT. Если вы станете повторяться, то commit check ругнется на имена правил.
3. Имена правил, сводов правил, пулов и т.д. можно писать любыми на ваше усмотрение. В моем случае это DNAT, web-server, dnat_for_web и т.д.
4. Посмотреть счетчик срабатываний проброса можно из операционного режима командой:

root@jsrx> show security nat destination rule имя_правила

В строке Translation hits будет показано количество срабатываний данного проброса. Очень удобный инструмент диагностики ната.
5. Если вас смущает строка match application any в конфиге политики, то вы правы. По-хорошему, в целях безопасности сюда стоит вписать имя конкретного приложения (т.е. порта), которое будет использоваться внешними клиентами, для веб-сервера можно написать match application junos-http. Подробнее о приложениях в Junos OS я буду писать позже.

Как видите, процедура создания проброса довольна проста, но и в ней есть свои нюансы. Спасибо всем за внимание, буду очень рад любым вопросам.

Настройка Juniper SRX 210H

Для этого необходимо зайти по ssh на SRX, зайти в командную строку CLI
(ввести команду cli) зайти в режим конфигурирования - команда conf

удалить старый шлюз по умолчанию:
delete routing-option static route 0.0.0.0/0 next-hop IP_адрес
и прописать новый шлюз по умолчанию
set routing-option static route 0.0.0.0/0 next-hop IP_адрес_альтернативного_оператора
и дать команду commit
(Посмотреть таблицу маршрутизации show routing-option)

(посмотреть какой адрес назначен на какой интерфейс - show interfaces)
Пример, на интерфейс ge-0/0/0.0 назначен адрес 95.79.xxx.xxx/24

Интересующие нас настройки туннеля указаны в разделе Security ike (можно вывести командой show security ike)
Пример, текущий удаленный адрес, на который строится туннель 95.79.yy.yy, а локальный интерфейс, с которого строится туннель ge-0/0/0.0

Команды по редактированию настроек туннеля:
Удаляем старые параметры:

Прописываем новые параметры:

Сменить настройки туннеля на другой стороне:
root@SRX1# show security

delete security ike gateway G1 address <пишем текущий адрес>
set security ike gateway G1 address <пишем новый адрес>

Чтобы применить настройки нужно выполнить команду commit

Макаров Василий (11:24:20 5/02/2014)root@srx> show log jsrpd

gamil@SRX1> show interfaces fe-2/0/2

show security flow session source-prefix 95.79.54.254/26 | match In
address 95.79.100.225/28;
address 95.79.103.1/25;
address 95.79.103.129/29;
95.79.54.254/26 - ограничение по этой сети ничего не дало. Сейчас зарезал для 95.79.103.0/25

gamil@SRX1# show firewall
создаем правило, в котором говорим, что будем резать трафик до скорости 10М
policer 10M

Далее создаем фильтр, в котором описываем сетку, откуда мы режем трафик и вешаем для этой сети полисер

gamil@SRX1# show interfaces reth2redundant-ether-options < redundancy-group 1;>unit 0 < family inet < filter < input Filter10Mbps; > address 95.79.54.254/26; address 95.79.100.225/28; address 95.79.103.1/25; address 95.79.103.129/29; >> Макаров Василий (15:52:53 5/02/2014)я сейчас уберу резалку трафика и вешаю ограничение для этого IP адреса Макаров Василий (15:56:06 5/02/2014)сейчас буду применять конфигgamil@SRX1# show interfaces reth2redundant-ether-options < redundancy-group 1;>unit 0 < family inet < filter < input Filter_reth2_input; > address 95.79.54.254/26; address 95.79.100.225/28; address 95.79.103.1/25; address 95.79.103.129/29; >>gamil@SRX1# show firewall filter Filter_reth2_inputterm a < from < source-address < 95.79.103.61/32; > destination-port 25; > then < discard; >>term b < then accept;>

В случае сбоя в файловой системы, подключается резервная часть и появляется такое сообщение.
Необходимо выполнить следующую команду. Команда будет выполняться в течении 10-15 минут

root> request system snapshot slice alternate
Formatting alternate root (/dev/da0s1a).
Copying '/dev/da0s2a' to '/dev/da0s1a'. (this may take a few minutes)
The following filesystems were archived: /

Резервное копирование конфигурации JUNIPER (Часть 1)

2 февраля 2016 г. 12:56:00

В этой статье я постараюсь максимально полно описать все известные мне способы резервного копирования и восстановления конфигурации сетевых устройств, работающих под управлением операционной системы JunOS. В частности, речь пойдет о девайсах семейства Juniper SRX (т.к. на данный момент их есть у меня :), но в целом материал может быть с успехом применен к некоторым другим семействам маршрутизаторов и коммутаторов.

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

Итак, начнем с оглавления:

1. Методы резервного копирования конфигурации (Часть 1)

2. Автоматизация резервного копирования конфигурации (Часть 2)

2.1. Встроенный механизм автоматического резервного копирования конфигурации

2.2. Копирование по расписанию листинга команды «show configuration | display set»

2.3. Централизованное резервное копирование конфигураций

Администратор сетевого устройства может сохранить проверенную активную конфигурацию в качестве аварийной. Это устраняет необходимость запоминать номера rollback-конфигураций или сравнивать внесенные изменения и позволяет легко восстановить работу оборудования в случае сбоя или даже в случае когда активная и резервные конфигурации повреждены.

Для создания аварийной копии конфигурации можно воспользоваться командой операционного режима:

root@SRX-01> request system configuration rescue save

Для загрузки аварийной конфигурации используется команда конфигурационного режима:

[edit]
root@SRX-01# rollback rescue

Чтобы изменения вступили в силу нужно сделать commit

На сетевых устройствах SRX-серии также есь возможность быстро вернуться к аварийной конфигурации кратковременно нажав утопленную кнопку "reset config", в этом случае аварийная конфигурация будет загруженна и сразу применена. В процессе применения изменений индикатор статуса будет светиться оранжевым цветом.

Если зажать и держать эту кнопку пока индикатор статуса не начнет светиться оранжевым цветом (

15 секунд), то все конфигурации на устройстве (в том числе аварийная) будут удалены, а на устройство будет загружена и применена заводская конфигурация по умолчанию.

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

Вывести листинг активной конфигурации в окне терминального клиента можно с помощью команды операционного режима:

root@SRX-01> show configuration

как видите расширения команд можно комбинировать.

Результат выполнения этих команд будет выглядеть приблизительно так:

set version 11.4R4.4
set system autoinstallation delete-upon-commit
set system autoinstallation traceoptions level verbose
set system autoinstallation traceoptions flag all
set system autoinstallation interfaces ge-0/0/0 bootp
set system name-server 208.67.222.222
set system name-server 208.67.220.220

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

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

Скопировать конфигурацию из текстового файла обратно в консоль можно с помощью следующих команд конфигурационного режима:

[edit]
root# load override terminal