Авторизация пользователей на Cisco ASA5510

Классическая авторизация пользователей. Пример конфигурации Cisco ASA5510.

Предисловие

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

Конфигурация

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

[cc lang=»bash»]
!
hostname firewall1
!
! — Список серверов —
names
name 192.168.1.100 FTP_server_1
name 192.168.1.101 FTP_server_2
name 192.168.1.102 TS_server
name 192.168.1.103 DMZ_DB_server
name 10.1.1.10 OUT_DB_server
!
!
interface Management0/0
shutdown
nameif management
security-level 100
management-only
no ip address
!
interface Ethernet0/0
description OUT
speed 100
duplex full
nameif outside
security-level 0
ip address 10.1.1.250 255.255.255.0
no shutdown
!
interface Ethernet0/1
description DMZ
speed 100
duplex full
nameif DMZ
security-level 50
ip address 192.168.1.254 255.255.255.0
no shutdown
!
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
!
!
! — Список сетевых групп —
object-group network DMZ_net
network-object 192.168.1.0 255.255.255.0
object-group network FTP_servers
network-object host FTP_server_1
network-object host FTP_server_2
!
!
access-list OUT_IN remark ***OUT->DMZ***
access-list OUT_IN remark ***ftp traffic to FTP servers***
access-list OUT_IN extended permit tcp any object-group FTP_servers eq ftp
access-list OUT_IN extended permit tcp any object-group FTP_servers eq ftp-data
access-list OUT_IN remark ***RDP traffic to DMZ servers***
access-list OUT_IN extended permit tcp any object-group DMZ_net eq 3389
access-list OUT_IN remark ***DB traffic between DB servers***
access-list OUT_IN extended permit tcp host OUT_DB_server host DMZ_DB_server eq 1526
access-list OUT_IN remark ***Virtual Telnet for Authentication*** access-list OUT_IN extended permit tcp any host 10.2.2.2 eq https
access-list OUT_IN extended deny ip any any log
!
!
access-list DMZ_IN remark ***DMZ->OUT***
access-list DMZ_IN remark ***ftp traffic from FTP servers***
access-list DMZ_IN extended permit tcp object-group FTP_servers eq ftp any
access-list DMZ_IN extended permit tcp object-group FTP_servers eq ftp-data any
access-list DMZ_IN remark ***RDP traffic from DMZ servers***
access-list DMZ_IN extended permit tcp object-group DMZ_net eq 3389 any
access-list DMZ_IN remark ***DB traffic between DB servers***
access-list DMZ_IN extended permit tcp host DMZ_DB_server eq 1526 host OUT_DB_server
access-list DMZ_IN remark ***Virtual Telnet for Authentication*** access-list DMZ_IN extended permit tcp host 10.2.2.2 eq https any
access-list DMZ_IN extended deny ip any any log
!
!
logging enable
logging buffered informational
!
!
! — NAT не используем, —
! — адреса транслируются сами в себя —
nat (DMZ) 0 192.168.1.0 255.255.255.0
static (outside,DMZ) 10.1.1.0 10.1.1.0 netmask 255.255.255.0
! — Без этой строки WEB страница аутентификации не откроется —
static (outside,DMZ) 10.2.2.2 10.2.2.2 netmask 255.255.255.255
!
!
access-group OUT_IN in interface outside
access-group DMZ_IN in interface DMZ
route outside 0.0.0.0 0.0.0.0 10.1.1.254 1
timeout xlate 4:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
! — Определяем таймаут аутентификации —
timeout uauth 4:00:00 absolute
!
!
! — Указываем TACACS+ сервер —
aaa-server ACS_1 protocol tacacs+
aaa-server ACS_1 (DMZ) host 192.168.1.4
key test
!
! — Для управления фаерволом потребуется —
! — аутентифицироваться на TACACS+ сервере. —
! — Если TACACS+ сервер не доступен, —
! — можно зайти локальным пользователем. —
aaa authentication serial console ACS_1 LOCAL
aaa authentication enable console ACS_1 LOCAL
aaa authentication ssh console ACS_1 LOCAL
!
!
! — Говорим, что весь входящий с наружи трафик —
! — требует аутентификации. —
aaa authentication include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1
! — Исключение для трафика серверов БД —
aaa authentication exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1
!
!
! — Говорим, что весь входящий с наружи трафик —
! — требует авторизации. —
aaa authorization include ip outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ACS_1
! — Исключение для трафика серверов БД —
aaa authorization exclude tcp/1526 outside DMZ_DB_server 255.255.255.255 OUT_DB_server 255.255.255.255 ACS_1
!
!
! — Без этой строки WEB страница аутентификации не откроется —
aaa authentication include https outside 10.2.2.2 255.255.255.255 0.0.0.0 0.0.0.0 ACS_1
aaa proxy-limit 128
!
! — Без этой строки WEB страница аутентификации —
! — будет иметь намного худший вид —
aaa authentication listener https outside port 1443 redirect
! — Указываем виртуальный адрес WEB страницы аутентификации —
virtual telnet 10.2.2.2
telnet timeout 5
ssh 10.1.1.0 255.255.255.0 outside
ssh timeout 5
ssh version 2
console timeout 5
!
no threat-detection basic-threat
no threat-detection statistics access-list
ssl encryption des-sha1 rc4-md5
!
! — Локальный пользователь для управления —
! — фаерволом на случай, когда —
! — TACACS+ сервер не доступен, —
username admin1 password test privilege 15
!
!
[/cc]
Комментарий к конфигурации

Этими строками мы говорим фаерволу, что AAA сервером является TACACS+ сервер, указываем его ip адрес и ключ.

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

Делаем исключение для трафика серверов БД. Этот трафик должен проходить без аутентификации и авторизации.

Virtual Telnet

Вы, наверное, заметили, что почти половина выделенных строк связана с ip адресом 10.2.2.2. Это виртуальный адрес WEB страницы, с помощью которой пользователь проходит аутентификацию и авторизацию. Разберемся с этим поподробнее.

Когда пользователь открывает HTTP, HTTPS, FTP и Telnet сессию, требующую аутентификации или авторизации, у него в браузере или в окне FTP или Telnet сессии появляется приглашение для ввода логина и пароля. Когда пользователь пытается открыть сессию по другим портам, например RDP соединение, предложение для ввода пароля не появляется, сессия закрывается по таймауту, а в логе фаервола появится запись “User must authenticate before using this service”.

Прежде чем открывать RDP сессию, пользователь должен авторизоваться на фаерволе. Но как это сделать? Где вводить логин и пароль? Для этого и нужен Virtual Telnet.

Несмотря на название, это совсем не telnet. Это дополнительная https сессия. Для пользователя процесс аутентификации выглядит следующим образом:

Пользователь запускает браузер и набирает в строке адреса https://10.2.2.2.

После подтверждения доверия сертификату, откроется следующее окно.

Обратите внимание, что изначально открывалась страница с адресом 10.2.2.2. А теперь ASA перенаправила пользователя на реальный ip адрес — 10.1.1.250. Подробнее об этом — чуть ниже.

Для продолжения надо нажать кнопку «Log in now».

В следующем окне надо ввести логин и пароль и нажать кнопку «Continue».

Если на фаерволе и ACS сервере все настроено корректно, и пользователь верно ввел логин с паролем, откроется страница как на следующем рисунке.

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

Явно разлогиниваться не обязательно. Если в течении определенного времени все соединения открытые пользователем простаивают, фаервол сам закроет авторизацию.

Тайм аут определяется командой :

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

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

Здесь указан виртуальный ip адрес страницы аутентификации. Именно его пользователи набирают в адресной строке браузера. Точнее они должны набрать https://10.2.2.2. Https страница загружается с фаервола. Для повышения безопасности используется не реальный ip адрес интерфейса фаервола, а виртуальный.

Это адрес надо указать в нескольких местах в конфигурации фаервола. В аксес листах должен быть открыт https трафик на виртуальный адрес страницы аутентификации.

Кроме того, для этого адреса надо явно прописать команду :

Это надо сделать обязательно, даже не смотря на то, что есть команда

покрывающая все адресное пространство.

Ну и последняя строка:

Она просто улучшает внешний вид WEB станицы аутентификации. Попробуйте убрать ее из конфигурации и посмотрите, что изменилось. В разных версиях ios эта команда выглядит по-разному.

Использование авторизации пользователей на Cisco ASA для ограничения доступа к сетевым ресурсам

Использование авторизации пользователей на фаерволе Cisco ASA для ограничения доступа к сетевым ресурсам.

Предисловие

Иногда возникает необходимость ограничить доступ к выборочным сетевым ресурсам и сервисам для определенных пользователей. Особенностью такой задачи является то, пользователи используют динамически меняющиеся ip адреса. Следовательно, нужно контролировать не ip адрес компьютера, с которого выполняется соединение, а идентификатор самого пользователя. О том, как это сделать с помощью Cisco ASA и Cisco Secure ACS рассказано в этой статье.

Общая информация

Для решения задачи требуется AAA сервер и фаервол Cisco ASA.

AAA сервер это программа, предоставляющая сервисы аутентификации (Authentication), авторизации (Authorization) и учёта использования ресурсов (Accounting).

Аутентификация – это процесс проверки подлинность пользователя. Система спрашивает у пользователя: “Кто ты?”

При авторизации система проверяет, что пользователю разрешено делать, а что нет, доступ к каким ресурсам позволен, к каким — нет. Система определят “Куда ты идешь?” и решает пропустить или нет.

Таким образом, аутентификация вполне самодостаточна, то есть может существовать без авторизации. Авторизация же без аутентификации работать не может.

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

Есть два способа реализации авторизации.

Первый – это классическая авторизация пользователей.

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

Классическая авторизация поддерживается только TACACS+ сервером.

Второй способ реализации авторизации – это динамически загружаемые списки доступа (access lists). На AAA сервере создаются аксес листы. Они привязываются к определенным пользователям или группам. В момент, когда пользователь проходит аутентификацию на фаерволе, ASA загружает с AAA сервера нужные аксес листы. При этом в качестве ip адреса источника соединения прописывается ip адрес аутентифицировавшегося пользователя. Клода пользователь разлогинивается, его аксес листы удаляются из памяти фаервола.

Этот вариант авторизации поддерживается только RADIUS сервером.

Пример настройки классической авторизации.

Здесь мы рассмотрим пример реализации классической авторизации. В качестве AAA сервера будем использовать Cisco Secure ACS v4.0, а в качестве фаервола — ASA5510 с ios Cisco Adaptive Security Appliance Software Version 8.0(3).

На рисунке Вы видите схему тестовой сети.

В нашем примере за фаерволом есть небольшая сеть, включающая в себя несколько серверов. Двум группам пользователей нужен доступ к внутренней сети. Первая группа – это обычные пользователи. Им надо открыть ftp трафик к двум FTP серверам и RDP трафик к терминальному серверу. Вторая группа – это администраторы серверов. Им так же требуется ftp трафик к FTP серверам и RDP трафик ко всем серверам внутренней сети (точнее сказать, надо открыть RDP ко всей внутренней сети 192.168.1.0/24). Если бы пользователи имели статические ip адреса, достаточно было бы написать аксес листы на фаерволе. Но так как пользователи используют динамические ip адреса, без аутентификации не обойтись. Более того, пользователям нужен разный доступ к разным ресурсам. Следовательно, аутентификации не достаточно, нужна еще и авторизация.

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

 

Безопасный метод авторизации на PHP

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

1. Модель (клиент) 
Регистрация
— логин (a-z0-9)
— пароль
Вход
— логин
— пароль
Cookie
— уникальный идентификатор юзера
— хэш
Модель (сервер) MySQL
Таблица users
user_id (int(11))
user_login (Varchar(30))
user_password (varchar(32))
user_hash (varchar(32))
user_ip (int(10)) по умолчанию 0При регистрации в базу данных записываеться логин пользователя и пароль(в двойном md5 шифровании)

При авторизация, сравниваеться логин и пароль, если они верны, то генерируеться случайная строка, которая хешируеться и добавляеться в БД в строку user_hash. Также записываеться IP адрес пользователя(но это у нас будет опциональным, так как кто-то сидит через Proxy, а у кого-то IP динамический… тут уже пользователь сам будет выбирать безопасность или удобство). В куки пользователя мы записываем его уникальный индетификатор и сгенерированный hash.

Почему надо хранить в куках хеш случайно сгенерированной строки, а не хеш пароля?
1. Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным. В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру, так как расшифровать он его не сможет(теоретически это возможно, но на это он потратит не один месяц, а может быть и год) а воспользоваться этим хешем ему негде, ведь у нас при авторизации свой уникальный хеш прикрепленный к IP пользователя.
2. Если злоумышленик вытащит трояном у пользователя уникальный хеш, воспользовать им он также не сможет(разве если только, пользователь решил принебречь своей безопастностью и выключил привязку к IP при авторизации).

2. Практика
--
— Структура таблицы users

CREATE TABLE users (
user_id int(11) unsigned NOT NULL auto_increment,
user_login varchar(30) NOT NULL,
user_password varchar(32) NOT NULL,
user_hash varchar(32) NOT NULL,
user_ip int(10) unsigned NOT NULL default '0',
PRIMARY KEY (user_id)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1 ;

register.php 
<?
// Страница регситрации нового пользователя

# Соединямся с БД
mysql_connect(«localhost»«myhost»«myhost»);
mysql_select_db(«testtable»);

if(isset($_POST[‘submit’]))
{
$err = array();

# проверям логин
if(!preg_match(«/^[a-zA-Z0-9]+$/»,$_POST[‘login’]))
{
$err[] = «Логин может состоять только из букв английского алфавита и цифр»;
}

if(strlen($_POST[‘login’]) < or strlen($_POST[‘login’]) > 30)
{
$err[] = «Логин должен быть не меньше 3-х символов и не больше 30»;
}

# проверяем, не сущестует ли пользователя с таким именем
$query mysql_query(«SELECT COUNT(user_id) FROM users WHERE user_login='».mysql_real_escape_string($_POST[‘login’]).«‘»);
if(
mysql_result($query0) > 0)
{
$err[] = «Пользователь с таким логином уже существует в базе данных»;
}

# Если нет ошибок, то добавляем в БД нового пользователя
if(count($err) == 0)
{

$login $_POST[‘login’];

# Убераем лишние пробелы и делаем двойное шифрование
$password md5(md5(trim($_POST[‘password’])));

mysql_query(«INSERT INTO users SET user_login='».$login.«‘, user_password='».$password.«‘»);
header(«Location: login.php»); exit();
}
else
{
print 
«<b>При регистрации произошли следующие ошибки:</b><br>»;
foreach(
$err AS $error)
{
print 
$error.«<br>»;
}
}
}
?>

<form method=»POST»>
Логин <input name=»login» type=»text»><br>
Пароль <input name=»password» type=»password»><br>
<input name=»submit» type=»submit» value=»Зарегистрироваться»>
</form>

login.php

<?
// Страница авторизации

# Функция для генерации случайной строки
function generateCode($length=6) {
$chars «abcdefghijklmnopqrstuvwxyzABCDEFGHI JKLMNOPRQSTUVWXYZ0123456789»;
$code «»;
$clen strlen($chars) — 1;  
while (strlen($code) < $length) {
$code .= $chars[mt_rand(0,$clen)];  
}
return 
$code;
}

# Соединямся с БД
mysql_connect(«localhost»«myhost»«myhost»);
mysql_select_db(«testtable»);

if(isset($_POST[‘submit’]))
{
# Вытаскиваем из БД запись, у которой логин равняеться введенному
$query mysql_query(«SELECT user_id, user_password FROM users WHERE user_login='».mysql_real_escape_string($_POST[‘login’]).«‘ LIMIT 1»);
$data mysql_fetch_assoc($query);

# Соавниваем пароли
if($data[‘user_password’] === md5(md5($_POST[‘password’])))
{
# Генерируем случайное число и шифруем его
$hash md5(generateCode(10));

if(!@$_POST[‘not_attach_ip’])
{
# Если пользователя выбрал привязку к IP
# Переводим IP в строку
$insip «, user_ip=INET_ATON(‘».$_SERVER[‘REMOTE_ADDR’].«‘)»;
}

# Записываем в БД новый хеш авторизации и IP
mysql_query(«UPDATE users SET user_hash='».$hash.«‘ «.$insip.» WHERE user_id='».$data[‘user_id’].«‘»);

# Ставим куки
setcookie(«id»$data[‘user_id’], time()+60*60*24*30);
setcookie(«hash»$hashtime()+60*60*24*30);

# Переадресовываем браузер на страницу проверки нашего скрипта
header(«Location: check.php»); exit();
}
else
{
print 
«Вы ввели неправильный логин/пароль»;
}
}
?>
<form method=»POST»>
Логин <input name=»login» type=»text»><br>
Пароль <input name=»password» type=»password»><br>
Не прикреплять к IP(не безопасно) <input type=»checkbox» name=»not_attach_ip»><br>
<input name=»submit» type=»submit» value=»Войти»>
</form>

check.php

<?
// Скрипт проверки

# Соединямся с БД
mysql_connect(«localhost»«myhost»«myhost»);
mysql_select_db(«testtable»);

if (isset($_COOKIE[‘id’]) and isset($_COOKIE[‘hash’]))
{
$query mysql_query(«SELECT *,INET_NTOA(user_ip) FROM users WHERE user_id = ‘».intval($_COOKIE[‘id’]).«‘ LIMIT 1»);
$userdata mysql_fetch_assoc($query);

if(($userdata[‘user_hash’] !== $_COOKIE[‘hash’]) or ($userdata[‘user_id’] !== $_COOKIE[‘id’])
or ((
$userdata[‘user_ip’] !== $_SERVER[‘REMOTE_ADDR’])  and ($userdata[‘user_ip’] !== «0»)))
{
setcookie(«id»«»time() — 3600*24*30*12«/»);
setcookie(«hash»«»time() — 3600*24*30*12«/»);
print 
«Хм, что-то не получилось»;
}
else
{
print 
«Привет, «.$userdata[‘user_login’].«. Всё работает!»;
}
}
else
{
print 
«Включите куки»;
}
?>

Для защиты формы логина от перебора, можно использовать капчу.

Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies, не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.

Примечания:
1. mysql_select_db(«testtable»); // нелогичное название базы, testdb лучше
2. Нужно использовать mysql_real_escape_string()
3. Убирать лишние пробелы нет смысла, так как их не пропустит вот эта строка:
if(!preg_match(«/^[a-zA-Z0-9]+$/»,$_POST[‘login’]))