Михаил Флёнов - Linux глазами хакера
- Название:Linux глазами хакера
- Автор:
- Жанр:
- Издательство:БХВ-Петербург
- Год:2005
- Город:Санкт-Петербург
- ISBN:5-94157-635-8
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Михаил Флёнов - Linux глазами хакера краткое содержание
Рассмотрены вопросы настройки ОС Linux на максимальную производительность и безопасность. Описаны потенциальные уязвимости и рекомендации по предотвращению возможных атак. Дается подробное описание настройки прав доступа и конфигурирования сетевого экрана. Показано, как действовать при атаке или взломе системы, чтобы максимально быстро восстановить ее работоспособность и предотвратить потерю данных.
Для пользователей, администраторов и специалистов по безопасности
Linux глазами хакера - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
□
miss_access разрешение имя
— описывает разрешение на получение ответа MISSES. В следующем примере только локальным пользователям дано право получать ответ MISSES, а все остальные могут принимать только HITS:
acl localclients src 172.16.0.0/16
miss_access allow localclients
miss_access deny !localclients
9.4.3. Аутентификация
Защита по IP-адресу не гарантирует от его подделки злоумышленником. К тому же, остается вероятность, что кто-то получит физический доступ к компьютеру, имеющему выход во всемирную сеть, и сделает нечто недозволенное.
Мне довелось работать в фирме, где каждому сотруднику было разрешено скачивать из сети определенное количество мегабайт. Проверка проходила через IP-адрес, и при превышении лимита руководство требовало от работника покрыть расходы за сверхнормативный трафик. Это нормальная ситуация, потому что работодатель не должен оплачивать бессмысленные прогулки сотрудника в Интернете. На работу приходят, чтобы выполнять свои обязанности, а не подыскивать обои для собственного компьютера.
Внимание!
Аутентификация не работает, если squid настроен на работу в прозрачном режиме.
Однажды у некоторых работников оказалось большое превышение трафика. Вроде бы ничего удивительного, но настораживало то, что эти товарищи были в отпуске. Кто-то подделывал чужой адрес и использовал служебный Интернет в своих целях.
Чтобы вы не столкнулись с подобной ситуацией, необходимо привязываться не только к IP-адресу, но и строить дополнительную защиту через проверку имени пользователя и пароля. Для аутентификации необходимо определить следующие директивы:
□
authenticate_program программа файл
— задает программу аутентификации (по умолчанию не устанавливается) и файл паролей. Если вы хотите использовать традиционную программу аутентификации proxy, то можно указать следующую строку:
authenticate_program /usr/lib/squid/ncsa_auth /usr/etc/passwd
Путь к программе ncsa_auth в вашей системе может отличаться.
Чтобы использовать возможности аутентификации прокси-сервера, у вас должна присутствовать хотя бы одна ACL-запись типа proxy_auth;
□
authenticate_children n
— определяет количество параллельно работающих процессов аутентификации. Один процесс не сможет производить проверку нескольких клиентов, поэтому если какой-либо пользователь проходит аутентификацию, то другие не смогут получить доступ к Интернету через сервер squid;
□
authenticate_ttl n hour
— срок (в часах) хранения в кэше результата аутентификации. В течение этого времени пользователь может работать без повторной проверки. По умолчанию установлен 1 час, но если введен неправильный пароль, то запись удаляется из кэша;
□
authenticate_ip_ttl 0 second
— связывает IP-адрес с аутентификацией. Необходимо установить 0, чтобы пользователи не могли воспользоваться одним и тем же паролем с разных IP-адресов. Некоторые клиенты считают, что можно делиться паролем с друзьями. Не стоит этого делать, потому что за это отвечает администратор. Если в вашей сети есть dialup-пользователи, подключающиеся с помощью модема, то это значение можно увеличить до 60 секунд, чтобы при разрыве связи была возможность перезвонить. Но обычно при подключении Dial-up используются динамические IP-адреса, которые выдаются при каждом соединении, и нет гарантии, что после повторного звонка адрес сохранится;
□
authenticate_ip_ttl_is_strict параметр
— если параметр равен on
, то доступ с других IP-адресов запрещен, пока время, указанное в authenticate_ip_ttl
, не выйдет.
9.5. Замечания по работе squid
Сейчас нам предстоит немного поговорить о некоторых вопросах безопасности сервиса squid и дополнительных возможностях, которые могут ускорить работу в Интернете.
9.5.1. Безопасность сервиса
Когда я впервые знакомился с документацией на squid, то мне очень понравились следующие два параметра:
cache_effective_user
и cache_effective_group
. Если squid запущен от имени администратора root, то идентификаторы пользователя и группы будут заменены на указанные в этих параметрах. По умолчанию установлено значение идентификатора squid для пользователя и для группы:
cache_effective_user squid
cache_effective_group squid
Таким образом, squid не будет работать с правами root, и при попытке сделать это сервис сам понизит свои права до squid. Не стоит вмешиваться. Сервису squid не имеет смысла давать большего, потому что ему достаточно прав только на директорию с кэшем.
9.5.2. Ускорение сайта
Сервис squid может ускорить работу определенного сайта, функционируя как httpd-акселератор. Для этого необходимо указать, как минимум, три параметра: адрес форсируемого сервера, который надо кэшировать, его порт и атрибуты сервера, который надо ускорять. Это задается с помощью следующих директив:
□
httpd_accel_host адрес
— адрес реального сервера;
□
httpd_accel_port порт
— порт Web-сервера. Чаще всего это порт по умолчанию (он равен 80), если не указан другой;
□
httpd_accel_uses_host_header параметр
— HTTP-заголовок включает в себя поле Host, не проверяемое сервером squid, и это может оказаться большой дырой в безопасности. Разработчики рекомендуют отключать эту директиву, указав в качестве параметра значение off
. Включать ее необходимо, если squid работает в прозрачном режиме;
□
httpd_accel_with_proxy параметр
— флаг использования кэширования страницы для дополнительного повышения скорости ( on
/ off
).
9.5.3. Маленький секрет User Agent
Многие статистические системы не учитывают или не пускают к себе пользователей, запросы которых содержат пустое значение в поле User Agent. Именно так определяется, что вы работаете через proxy.
Опять случай из собственной практики. Я снова вспоминаю фирму, где мне пришлось работать 4 года, и защита была организована по IP-адресу. Мой отдел занимался автоматизацией производства, и в нем работали электронщики, а я был единственный программист и администратор в одном лице. Доступ в Интернет был разрешен только мне, начальнику отдела и его заместителю. Через несколько часов доступ имели все сотрудники отдела. Как это произошло? Решение очень простое — я поставил на свой компьютер прокси-сервер, к которому могли подключаться без аутентификации мои сослуживцы, а он уже переправлял эти запросы корпоративному proxy. Так как все запросы шли от меня, то главный proxy ничего не заметил.
На первый взгляд решение идеальное, но тут есть один изъян. Да, это поле User Agent, которое становится пустым при прохождении пакетов через мой squid-сервис. Но поле можно задать вручную в конфигурационном файле. Для этого существует директива
fake_user_agent
. Например, следующая строка может эмулировать запросы, как будто они идут от браузера Netscape:
Интервал:
Закладка: