Безопасность Windows XP. Часть 2
Обновлено: 13.09.2025Пришло время познакомиться со второй частью материала, рассказывающего о том, как повысить безопасность персонального компьютера, работающего под управлением операционной системы Windows XP.
Перед тем, как приступить к чтению, мы рекомендуем ознакомиться с первой частью материала, расположенной по следующему адресу.
Shared-ресурсы
Shared-ресурсы, в народе называемые просто "шары", всегда были и будут одной из главных головных болей пользователей Windows XP. Изначально задуманный как неоценимая помощь для пользователей, находящихся в локальных сетях, проект содержал множество багов, которыми непременно и пользовались злоумышленники при захвате удаленной машины.
Но, не удержавшись, дам совет пользователям локальных сетей. Если при работе вам столь необходимо часто обмениваться файлами, для этого есть более безопасные методы.
Как пример - создание ftp-сервера. Скажу по секрету, что такого рода материал планируется для написания, так что ждите анонсов и чаще заходите на www.3dnews.ru! Но вернемся к делу. Наша задача - отключить расшаренные ресурсы, к чему и приступим. Заглянем в свойства диска C, затем на вкладку "Sharing".
Взглянув на скриншот, мы видим, что у нас имеется расшаренный диск. И его немедленно нужно отключить. Это нужно сделать, отметив опцию "Do not share This Folder". Так нужно сделать со всеми логическими дисками, имеющими место у вас в системе.
Еще одна особенность Windows XP - появление папки Shared Documents (Общие документы). Перемещаем в папку любой файл, и вуаля - он доступен по сети. Чтобы прекратить данное безобразие, в который раз воспользуемся услугами редактора системного реестра. Пройдем сюда - HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Explorer MyComputer NameSpace DelegateFolders {59031a47-3f72-44a7-89c5-5595fe6b30ee}, удалим в пух и прах этот раздел реестра, после чего папка станет недоступна.
Все бы хорошо, но расслабляться еще рано. В системе присутствует протокол под названием NetBIOS, который также следует удалить от греха подальше. Суть протокола заключается в том, что он предоставляет удаленный доступ к файлам и папкам и может раскрыть нежелательную информацию о компьютере. Сомнений не осталось? Тогда в свойствах используемого соединения, во вкладке "свойства протокола TCP/IP" -> "дополнительно" выбираем пункт "отключить NetBIOS через TCP/IP". Там же убираем галочку напротив сервиса "Доступ к файлам и принтерам сети Microsoft".
Автозагрузка
Часто пользователи персональных компьютеров не интересуются тем, какие программные продукты стартуют при загрузке системы. Этим фактом и пользуются злоумышленники, подсаживая трояны и прочую нечисть в автозагрузку.
Поэтому хотя бы раз в неделю запускайте программу msconfig (Пуск-Выполнить), чтобы проверить, какие утилиты загружаются при старте. Помимо автозагрузки, вирусописатели любят засовывать старт своих детищ в следующие ветки реестра:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersion WindowsRun.
Выходов, как обычно, имеется множество. К примеру, можно проводить аудит данных ветвей на предмет новых записей самостоятельно. А можно для этого использовать программный продукт, такой как RegMon.
Удаление неиспользуемых аккаунтов
А зачем вам нужны пользователи, учетными записями которых вы никогда и не воспользуетесь? Компания Microsoft, помимо стандартных записей, успела запихать "секретные" учетные записи по типу SUPPORT_586975a0, которая, кстати, предназначена для получения удаленной помощи от службы технической поддержки. Вы себе это представляете? Я - нет. И именно по этому берите в руки пилу, двигайтесь по направлению к Панель Управления - Администрирование - Управление компьютером - Локальные пользователи и группы - Пользователи и начинайте пилить всех, кто попадется под горячую руку.
Популярная брешь в IE
Вообще, следуя советам различных IT-экспертов, использовать Internet Explorer в качестве основного браузера для путешествий по сети нецелесообразно. Виной тому огромное количество уязвимостей, каждодневно находимых в коде. К примеру, разберем одну достаточно серьезную уязвимость, позволяющую запускать любые приложения, имеющиеся на жестком диске. Для этого наберем в блокноте следующий html-код:
Сохранив код как exploit.html, запустите его в браузере.
Если у вас произошло такое же событие, как и показано на скриншоте, то используемый IE уязвим. Проявив чуточку фантазии, вы, несомненно, сможете придумать, как злоумышленник может использовать данную дырку в системе безопасности. И поверьте мне, таких дыр будет еще много. Но, а пока пройдите по данному пути - HKEY_CURRENT_USER SOFTWARE Microsoft Windows CurrentVersion Internet Settings Zones и присвойте значение dword:00000001 параметру "104".
Автор: Ярослав Дмитриев
Источник: http://www.3dnews.ru/
Безопасность Windows XP. Часть 1
Обновлено: 13.09.2025Операционная система Microsoft Windows XP вышла на рынок 25-го ноября 2001-го года. Сотрудники компании возлагали на неё большие надежды и, как оказалось, не прогадали. По заявлению самих разработчиков, новоиспеченная на тот момент XP включала в себе опыт, накопленный за многие годы построения операционных систем.
Как и ожидалось, перед выходом, пользователям было дано множество обещаний (к примеру, непробиваемую защиту от несанкционированного доступа, невиданную ранее стабильность и "багоустойчивость"), но не все оказалось настолько уж гладко.
Но довольно лирических отступлений, сегодня на повестке дня - повышение безопасности операционной системы. Пошаговый формат выбран не с проста - так наиболее просто выполнять инструкции, описанные в статье.
Шаг 1. Отключение автоматического запуска CD
Купили вы диск, доверху набитый полезным программным обеспечением. Принесли домой, вставили в дисковод, автоматически запустился диск, а там - вирус. Чтобы этого не произошло, вам нужно пройти по следующему адресу в реестре - HKEY_LOCAL_MACHINESYSTEMControlSet001ServicesCdrom, и параметру AutoRun присвоить значение 0. Для редактирования реестра вам нужно запустить программу RegEdit, которая запускается так: Пуск - Выполнить - regedit.
Шаг 2. Автоматическое обновление системы
Как каждому из нас известно, достаточно часто в операционных системах Windows находятся ошибки и критические огрехи в безопасности, исправить которые следует сразу же после выхода патча. Ушедший 2004-ый год лишний раз это доказал, явив миру несколько глобальных вирусных эпидемий.
Поэтому кликаем правой кнопкой мыши по иконке Мой Компьютер, а затем направляемся по пути Свойства - Автоматическое Обновление. Перед нами возникает дилемма - либо остановить свой выбор на опции "Автоматически", либо сделать активной опцию "Уведомлять, но не загружать и не устанавливать их автоматически".
Дам несколько рекомендаций. Если вы владелец выделенного интернет-канала, и закачивать каждый день в фоновом режиме (а именно так происходит обновление системы через Windows Update) файла приличного размера не составляет большой проблемы, то однозначно ваш выбор - Автоматически.
Другим же пользователям, а в особенности модемным, советую выбрать "Уведомлять, но не загружать и не устанавливать их автоматически", где качать и устанавливать файлы вы будете, предварительно оценив их важность, дабы не захламлять итак слабый интернет-канал.
Шаг 3. Отключение ненужных сервисов
Не знаю зачем, но Билл Гейтс и сотоварищи нагородили в Windows XP такое огромное количество ненужных служб, запускающихся автоматически, что не отключить их - грех. Но так как разговор мы ведем о безопасности операционной системы, обратим наше внимание на системные сервисы, подрывающие наши старания. Для этого пройдем по пути Панель управления - Администрирование - Службы и займемся работой.
Напомню, как работать со службами. Кликнув на одну из них, перед собой вы увидите окно с четырьмя закладками: Общие, Вход в систему, Восстановление, Зависимости. По сути дела, наиболее важными являются две: первая и последняя. На первой вкладке, "Общие", вы можете прочитать название службы, ее функции, исполняемый файл, а также выставить тип запуска: авто, вручную, отключено. Так как нам предстоит деактивировать ненужные системные сервисы, мы будет выставлять тип "отключено". На последней вкладке, "Зависимости", вы можете увидеть, с какими из служб выбранный вами сервис находится в зависимости, то есть если служба отключена или неправильно работает, это может отразиться на зависимых от нее сервисах.
Внимание: прежде чем начать резкое удаление ненужных служб, я советую сохранить первоначальные настройки, чтобы избежать возможных конфликтов. Для этого нужно пройти по HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiсes и кликнув правой кнопкой, выбрать пункт "Экспортировать". Далее сохраняем данные в *.reg-файл.
Служба удаленного управления реестром (Remote Registry Service) - позволяет удаленно управлять системным реестром. Если служба остановлена, то редактировать реестр может только локальный пользователь. Надеюсь, лишних вопросов не возникает. Режем.
Служба сообщений (Messenger) - данная служба позволяет получать и отправлять сообщения. Часто используется для розыгрышей и спама. Оно вам нужно? Режем.
Служба терминалов (Terminal Service) - одной из функций службы является предоставление услуг Remote Desktop. Несомненно, данный сервис не является безопасным, поэтому нуждается в отключении, что и делаем.
NetMeeting Remote Desktop Sharing - служба позволяет определенным пользователям получать доступ к рабочему столу Windows. Давно вы пользовались Windows NetMeeting? И пользовались ли вообще? Режем.
Telnet - позволяет удаленным пользователям работать с машиной по протоколу Telnet. Если вы не пользуетесь данными услугами, отключение произойдет незаметно. Режем.
Шаг 4. Установка фаервола
Согласно статистике, большинство злоумышленников, существующих в сети, ломают не определенные системы, а путем сканирования выявляют слабые точки и делают свои "грязные" дела. Чтобы не стать их жертвой, вам обязательно нужно установить брандмауэр. В комплекте с XP идет встроенный фаервол, но он не отвечает тем требованиям, которые предъявляются хорошим программным продуктам.
К сожалению, тема и формат статьи не позволяет нам провести сравнительное тестирование n-го количества программ (что мы обязательно сделаем в будущем), но, основываясь на своем опыте, я могу посоветовать вам остановить свой выбор либо на Outpost Firewall Free от Agnitum Limited, либо на Zone Labs' ZoneAlarm. По своей функциональности - это схожие продукты, поэтому выбор за вами.
Шаг 5. Пароли и все о них
По мнению большинства IT-экспертов, именно халатность пользователей при составлении паролей во многом предопределяет ход событий при взломе. Пароли на пользовательские аккаунты хранятся в файле .sam в директории systemrootsystem32config. Но доступ к файлу во время работы компьютера не имеет даже пользователь с правами администратора.
Локально получить доступ не составляет никакого труда. Мне видится два варианта. Первый - загрузить на дискету альтернативную ось (Trinux, PicoBSD), способную читать из раздела NTFS, и прочитать файл. Второй - достаточно распространенная связка Win9x + WinXP, где первая система ставится для игр, а вторая для работы. И, естественно, чтобы избежать лишних манипуляций, пользователи охотно ставит WinXP на файловую систему FAT32 для получения доступа к рабочим файлам. Что из этого выйдет - огромная дыра в безопасности.
Пароли в Windows XP шифруется сразу по двум алгоритмам. Первый - LM-Hash, существующий для аутентификации в сетях LanMan, второй - NT-Hash. Алгоритм LM-Hash работает довольно глупо, чем и пользуются программы расшифровки паролей, хранящихся в файле .sam. LM-Hash разделяет полученный пароль на части по 7 символов (например, если пароль из 10 символов, то пароль будет разделен на две части - 7 символов и 3), переводит все символы в верхний регистр, шифрует каждую часть отдельно, и два полученных хэша объединяет в LM-Hash.
Стоит ли говорить о том, что пароль из десяти символом расшифровать сложнее, чем два, состоящих из 7 и 3 символов? Этой огрехой и пользуются программы для взлома. Быстро расшифровав вторую часть, можно составить общее впечатление о пароле, что, согласитесь, плохо. Учитывая вышесказанное, пароль из 7 символом будет надежнее 8,9 или 10. Но бороться с этой проблемой можно. Для этого пройдем по пути Панель Управления - Администрирование - Локальные параметры Безопасности, далее Локальные политики - Параметры безопасности, и ищем в появившемся списке опцию "Сетевая безопасность: уровень проверки подлинности LAN Manager".
В выпадающем списке выбираем "Отправлять только NTLM ответ" и нажимаем на ok. Одной проблемой стало меньше.
Шаг 6. Теория составления паролей
Для начала ответьте на вопрос: вы когда-нибудь задумывались о том, насколько легко можно угадать ваш пароль? Если да, то хорошо. А если нет, то плохо. Своей халатностью вы только упростите работу взломщика, поставивший цель уложить на лопатки вашу систему. В сети Интернет существует огромное количество программ, подбирающих пароль методом bruteforce (или же "в лоб"). Подбор может вестись как по словарю, так и по определенным правилам, установленным взломщиком. Во-первых, никогда не используйте в качестве паролей ФИО, дату рождения, кличку любимой собаки и т.д.
Этой информацией очень легко завладеть, следуя обычной логике. Если человек без ума от собак, то почему бы ему не назначить паролем для доступа к e-mail имя своего любимого пса? Злоумышленник же, узнав это, легко представится в ICQ таким же собаководом, и начнет тщательный опрос. А вы, того не подозревая, в чистую выложите всю информацию о себе и своем питомце.
Пароль нужно придумать. И для этого есть свой алгоритм, которым я спешу поделиться с вами. Возьмите бумажку и напишите любое слово. Затем добавьте две цифры между букв. Приобщите к делу знак пунктуации, вставив его в самое неожиданное место. Из легко угадываемого пароля password мы получили pass2w!ord. Крепкий орешек, согласны? То-то.
Шаг 7. Аккаунт "Администратор"
По настоянию компании Microsoft, сменим логин администратора на что-нибудь более звучное и одновременно менее бросающее в глаза. Поэтому пройдем по Панель Управления - Администрирование - Локальная политика безопасности. В выпавшем списке выберем опцию "Локальная политика", далее Параметры безопасности, и после ищем в открывшемся списке "Учетные записи: Переименование учетной записи администратора". Придумываем логин, и соответственно, вписываем в открывшемся окне. И еще - никогда не используйте аккаунт Администратора при каждодневных делах. Для этого создайте другой пользовательский аккаунт, и именно с него путешествуйте в сети, работайте и развлекайтесь.
Шаг 8. Опасная заставка
Безобидный на первый взгляд файл заставки несет в себе большую опасность, так как внутри файла может быть все что угодно. Для исправления бага нужно пройти по следующему ключу в реестре - HKEY_USERS.DEFAULTControl PanelDesktop и найдя параметр ScreenSaveActive, присвоить значение 0.
Шаг 9. Реестр, друг наш!
Реестр очень полезная вещь. Полазив, можно настроить систему так, что работа будет только в удовольствие. Чтобы не занимать много места, разбивая по шагам, я решил представить вашему вниманию подборку ключей в системном реестре, пройти мимо которых невозможно.
Очистка файла PageFile - HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Session Manager Memory Management - присвоив значение 1 параметру ClearPageFileAtShutdown, тем самым вы активируете возможность удалять при завершении работы все данные, которые могли сохраниться в системном файле. Автоматические удаление трэшевых файлов после работы в сети Интернет - HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Internet Settings Cache - присвоив 0 значению Persistent, вы больше не будете вынуждены собственноручно стирать остатки путешествий по сети Интернет. Internet Explorer будет делать это за вас. Удобно.
Установка минимального количества символов в паролях - HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Policies Network - чтобы отбить у вас охоту каждый раз вписывать пароль меньше 6-ти символов, присвойте значение hex:6 параметру MinPwdLen. Отныне все пароли в вашей системе будут больше 6 символов.
Требовать пароли только из букв и цифр - HKEY_LOCAL_MACHINE Software Microsoft Windows CurrentVersion Policies Network - предыдущий ключ отбил охоту придумывать пароль меньше 6-ти символов. Данная опция заставит вас комбинировать при составлении пароля как буквы, так и цифры. Активировать опцию можно присвоив значение 1 параметру AlphanumPwds.
Шаг 10. Проводник
И последнее, что мы сегодня исправим, будет касаться программы Проводник. Мало кто знает, что в реестре можно указать путь, где физически располагается Проводник, чтобы избежать несанкционированной замены. Для этого пройдем по _LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon и укажем полный путь до Проводника.
На этом наш сегодняшний экскурс в мир безопасности закончен. Но мы не остановимся на достигнутом, а постоянно будет подпитывать вас новой информацией. Оставайтесь на нашей волне!
Источник: http://www.3dnews.ru/
Настройка 3proxy для чайников
Обновлено: 18.03.2020
Пара ремарок перед началом чтения:
- Несмотря на то, что на сайте 3proxy.ru гордо отображается сообщение о том, что антивирусы могут воспринимать 3proxy как вирус, я с таким не сталкивался. Возможно, это относится к исходникам и компиляции, а не к бинарникам. Все же современные антивирусы могут собрать статистику, что файл с такой-то контрольной суммой скачан 100500 раз и не начинают голосить почем зря. Кто знает...
- Несмотря на то, что оригинал статьи не новый (в оригинале речь идет про версию 0.5.2, а на текущий момент стабильная версия 0.8.13), все подойдет и будет работать. Начинайте читать и совсем скоро вы увидите, что этот proxy действительно может быть простым.
Что это вообще такое?
3proxy - это прокси сервер (proxy, socks, pop3proxy) для Windows, Linux, Unix. Исходники открыты, бинарники скомпилировны, инструкции по компиляции указаны. Много лет развития. Что еще надо? Вперед!
Проще некуда
Для затравки, если уж "для чайников", да простят меня читатели, то вот простой конфиг 3proxy.cfg:
auth none
log
proxy
Куда уж проще... Вообще, 3proxy хорош тем, что он может быть и очень простым и лаконичным. Да и запуск его не сложен вовсе.
Скачали с сайта архив, распаковали в c:\3proxy, создали тектовый файл 3proxy.cfg и положили его в папку с exe-файлом, запустили cmd:
C:\Users\>cd "C:\3proxy\bin"
C:\3proxy\bin>3proxy.exe 3proxy.cfg
200318221136.662 3128 00000 - 0.0.0.0:0 0.0.0.0:0 0 0 0 Accepting connections [8996/8360]
Все, ничего не устанавливая, мы запустили proxy сервер, который принимает соединения на порт 3128. Можно прописать даже у себя в браузере, 127.0.0.1 3128 и все уже начинает работать, вы сразу увидите, как в консоли побегут строчки лога.
В этом конфиге:
logбез параметров означает выводить лог на stdout (на экран, в общем)proxy- запускаем именно прокси, а не socks, на стандартном порту 3128auth none- не запрашивать авторизацию, открытый прокси.
Оригинал с правками
Автор статьи: Kurmaeff Halit
halit_at_mail_dot_ru
Хочу поделиться своим опытом по настройке замечательного прокси-сервера от Заразы - 3proxy. Долгое время пользовался другим интересным прокси-сервером ES Proxy http://esproxy.org.ua от Георгия Павленко - маленького (всего один exe-шник на 300 кБ), довольно простого в настройке и очень нетребовательного к ресурсам - по крайней мере, при почти сотне пользователей он умудрялся работать на старинном P133, почти не затыкаясь. И только вот это <почти> - иногда все же проксик самопроизвольно пожирал 100% процессора, хотя и продолжал частично или полностью справляться со своими обязанностями - а также то, что автор уже почти 2 года как не подает никаких признаков жизни, то есть продукт замер в развитии - привели к поискам другого подходящего сервера. Скажу сразу - прокси-сервера с красивыми GUI меня привлекали мало, я сторонник принципа <Мне чтобы ехать>, а красивый интерфейс - это, конечно, хорошо, но не в ущерб производительности. Перепробовав не от хорошей жизни 5-6 разных продуктов (среди них Usergate, Proxy+, Lan4net....) и не оставшись довольным получаемыми результатами (должен заметить, что известный продукт от Майкрософт я решительно отмел ввиду его высокой стоимости), решил попробовать таки 3proxy, тем паче слышал в основном хорошие отклики. Если кто и жаловался на него, то только на сложность настройки, в чем, должен скачать, немного забегая вперед, я и имел возможность убедиться.
Безопасность сервера FreeBSD
Обновлено: 13.09.2025
Каждый компьютер, подключенный к Интернет, является потенциальным объектом хакерских атак. Если компьютер подключается к сети через модем, да и то на 10 минут в день, то единственным достоянием хакера может стать только Ваш пароль на вход в Интернет (и, естественно, деньги, лежащие на счету у провайдера). Так как Ваш сервер, очевидно, имеет постоянное высокоскоростное соединение с Интернет, он является очень лакомым куском для хакера, и в том, что рано или поздно (скорее - рано) он подвергнется атаке - можно не сомневаться. Поэтому, прежде чем описвать дальнейшую настройку таких служб, как DHCP, DNS, VPN и др., необходимо защитить сервер от возможных непрятностей. В этой главе будут даны только начальные сведения по защите, и предложена настройка, способная отбить большинство непрофессиональных атак, и некоторые общие правила работы. Данная глава не предендует на статус полного руководства по защите, но на первое время хватит и этих данных. В дальнейшем Вам будет необходимо изучить вопросы безопасности более плотно, причем не откладывая этого дела в долгий ящик (практически на каждой из доступных мне машин, имеющих постоянное подключение к Интернет периодически (не реже раза в месяц) обнаруживаются следы попыток незконного проникновения...)
Чтобы защитить свою систему от хакеров, нужно изучить своего врага - его возможности, его оружие, его стандартные приемы. Для этого нужно рассмотреть типовые атаки (и методы защиты или уменьшения ущерба от каждой из них).
Вот тут то и самая большая сложность, которая возникла у меня при написании этой главы: каждый, кто пишет книги, статьи и руководства по защите, придумывает свою классификацию, основываясь на разных признаках атак. Поэтому я пойду другим путем, и не буду говорить что все атаки разделяются на 3 (5,7,19 или 244) класса, а опишу, по каким характеристикам их можно классифицировать.
Итак, у каждой хакерской атаки есть:
- Цель. Целью хакера может быть получение какой-то секретной информации, изменение информации (например, 10 баксов к себе на счет) или ее уничтожение, использование мощностей атакуемого объекта в личных целях (рассылка спама, экономия на "российском" и "зарубежном" трафике, использование "захваченной" машины в качестве плацдарма для атаки на другие машины), вывод объекта из строя (например, "подвесить" веб-сервер конкурента), для тренировки, самоудовлетворения и т.д.
- Используемые "дыры". Для атаки на компьютер хакер может использовать ошибки в программном обеспечении, ошибки администрирования (например, случайно доступная простому пользователю возможность изменения конфигурационных файлов операционной системы), незащищенность среды и протоколов передачи данных (например, "подслушивание" паролей пользователей, находящихся в одной сети с хакером), социальный инжениринг (например, подбор пароля администратора последовательным перебором имен всех его бывших любовниц и их номеров телефонов), метод "грубой силы" (подбор пароля простым перебором всех возможных комбинаций или по словарю), человеческие ошибки. Хакер, так-же, может использовать несколько "дыр" для одной атаки (например, используя сетевой снифер получить зашифрованный пароль администратора, и расшифровать его методом грубой силы).
- Направаление. Атака может быть как активно инициирована хакером (например, прямой перебор паролей или прослушивание сети), так и произведена с помощью какой-либо ловушки (например, "хитрый" JavaScript на веб-странице, зайдя на которую пользователь "поделится" с хакером какой-нибудь нужной информацией).
- Характер воздействия. Атака может быть активной (хакер непосредственно обращается к атакуемому компьютеру или тесно связвнным с ним системами) или пассивной (например, прослушивание сетевого трафика атакуемой системы). Пассивные атаки почти невозможно обнаружить.
- Количество атакующих. Атаковать систему может один хакер, группа хакеров, или один хакер с использованием нескольких компьютеров в сети. Групповые атаки обычно направлены на выведение системы из строя (DDoS).
- Местонахождение атакующего. Хакер может атаковать систему, находясь к по отношению к ней в разных зонах доверия. В нашем случае (сервер доступа для домашней сети) это следующие зоны: интернет, обслуживаемая домашняя сеть, доверенная зона (компьютер администратора, дополнительные сервера (файловый, баз данных), при общении с которыми защизаемый сервер использует более "мягкие" правила безопасности), внутри самой системы (например, хакер имеет права доступа обычного пользователя, и атакует учетную записть сисадмина).
Естественно, атаки можно классифициорвать и по другим признакам - данный список не претендует на полноту.
Для защиты от хакерских атак необходимо знать и понимать методы, используемые хакерами. Далее предлагаю рассмотреть несколько наиболее распоcтраненных (впрочем, я могу и ошибаться) типов атак и методов защиты от них.
Атака "переполнение буфера"
Атаки данного типа эксплуатируют "неявные" ошибки в прграммном обеспечении, обычно не влияющие на нормальную работу программы, но способные привести к взлому системы, или выведению ее из строя.
Предположим, существует некоторая программа, выпоняющаяся на атакуемой машине, и принимающая некоторые данные от пользователей (не важно, что она с ними потом делает). Пусть это будет, к примеру... web-сервер. Итак, Web-сервер позволяет пользователю подключиться к определенному порту, передать свой запрос, состоящий из нескольких полей, и передающий некоторые данные в ответ на запрос. Формат запроса к Web-серверу:
GET /название/страницы.html HTTP/1.1
Параметр: значение
Параметр: значение
...и так далее. В "параметрах" броузер может передать, например, желаемую им кодировку текста, содержимое Cookie и т.д. Пусть сервер обрабатывает запрос следующим участком программы на языке C:
int ReadParam()
{
static char* s;
static int c;
char namebuf[256]; // область памяти для записи имени параметра
char namevalue[1024]; // область пямяти для записи значение параметра
s=namebuf;
while( (c=NetReadChar()) != ':' && !NetworkError() ) *s++=c;
.... далее что-то с этим делаем ...
Что делает этот участок кода: выделяет в стеке некоторый объем памяти для сохранения названия параметра и его значения, читает из пользовательского запроса символы до первого появления символа двоеточия и последовательно записывает их в предназначенную для этого область памяти. Здесь уже есть ошибка! Программист при написании программы точно знал, что наименование параметра никогда не будет длинее, чем 30-40 символов, и отвел 256 байт с запасом, чтобы не мучаться с дополнительной обработкой ошибок - "влезет" строка в память или нет, и что потом делать дальше. При этом количество реально записанных в память символов он уже не проверяет.
Казалось бы, что случится, если название параметра будет длинее, чем 256 символов? Ну не обслужит сервер такой запрос - а нечего слать непредусмотренные запросы... однако, точно зная структуру программы хакер может загнать в качестве названия параметра строку, содержащую выполняемый машинный код. Казалось бы - ну и пусть, ведь его-же никто не выполнит. Ну "повиснет" сервер, делов-то... Однако, адрес возврата из процедуры чтения параметров в основную программу тоже хранится в стеке (т.е. в той-же области памяти, из которой программист выделил место под хранение названия параметра), и хакер имеет все возможности изменить его (опять же, точно зная структуру программы), и заставить программу веб-сервера выполнить его код.
Рассмотренный пример очень прост, и ошибка в нем видна со всех сторон. В реальности в одну и ту же облась памяти может последовательно записываться множество данных в различных частях программ. Заметить такую ошибку в этом случае может только человек, который специально ее ищет.
Бороться с такими атаками практически невозможно. Большинство специалистов по безопасности предлагают отключить все ненужные сервисы (ну зачем, скажите, на вашем сервере доступа, например, NIS?) и устанавливать все свежие патчи. От себя могу посоветовать затруднить хакеру возможность правильного определения версии вашего программного обеспечения: большинство сетевых программ вставляют в свои ответы еще и подпись - "Ответ сгенерирован программой такой-то, версия такая-то". Например, сервер www.hub.ru (очевидно, вы читаете этот текст именно с этого сайта) в свой ответ вставляет следующую информацию:
Server: Apache/1.3.26 (Unix) PHP/4.2.2 mod_deflate/1.0.12 rus/PL30.14
Исходя из этой информации хакер может начать поиск либо готовых экспоитов для данной версии, либо самостоятельно начать анализировать исходные коды Apache. Чтобы помешать хакеру определить версию программного обеспечения, нужно заставить сервер выдавать вместо своего "паспорта" что-либо другое. С системой FreeBSD поставляются исходные коды практически всех используемых в ней программ, а многие программы вообще позволяют настраивать свой "паспорт", только этим никто не пользуется. Хакер же, увидев вместо вышеприведенной строки что-нибудь вроде "Server: SmartW3Daemon/0.3.12beta" будет вынужден сначала поискать этот SmartW3Daemon, а потом, когда поймет, что его надули, ему придется долго определять настоящую версию сервера по косвенным признакам.
Прослушивание сетевого трафика
Существует множество протоколов (таких как POP3, telnet, ftp и др.), передающих по сети незашифрованные данные, в том числе и пароли. Принцип же действия сети Ethernet таков, что любой посланный системой пакет доступен для просмотра всем членам домена коллизий, из которого послан пакет, а так-же всем членам доменов коллизий, через которые пакет пройдет на пути к адресу назначения.
Программное или аппаратное средство, позволяющее просматривать все проходящие мимо пакеты данных называется снифер. Программные сниферы существуют под любую операционную систему, и способны работать с практически любыми сетевыми картами. К счастью, в последнее время в сетях перестал встречаться коаксиальный кабель, а хабы (просто ретранслирующие пакеты на все порты) стали заменяться на коммутаторы, переправляющие пакет только адресату, однако и коммутаторы небезгрешны - если коммутатор специально не защищен от подобного рода атак, его можно за несколько секунд превратить в хаб, забив его внутренние таблицы коммутации большим количеством пакетов с сотен и тысяч фиктивных MAC-адресов. К сожалению, при разработке оборудования производители меньше всего думают о безопасности.
Если ваша сеть построена с использованием хабов, Вы сможете сами попробовать перехватить трафик ваших соседей, установив на свой компьютер, например, триальную версию пакета CommView компании TamoSoft (Для Windows).
К счастью, присутствие в сети большинства программных сниферов можно обнаружить с помощью специальных программных средств, провоцирующих такие компьютеры отвечать на запросы, на которые они бы не ответили в обычном режиме.
Атака "Фальшивый Сервер"
Предположим (для простоты описания) что хакер находится в одной сети с администратором и сервером, а администратор предпочитает "рулить" сервером не непосредственно с его консоли, а делает это через сеть (и я его понимаю :)).
Итак, администратор набирает в командной строке ssh server.home.net, и надеется, что через несколько секунд он окажется на сервере. Ничего подобного! Умный хакер, использовав весь арсенал из предыдущего способа атаки, перехватывает запрос к серверу DNS, который посылает система администратора для получения IP-адреса компьютера с именем server.home.net. Хакеру остается только успеть раньше настоящего сервера DNS отправить системе администратора фальшивый ответ, указав в качестве адреса свою, заранее подготовленную систему, и понаблюдать, как администратор вводит свой пароль. Грамотный хакер может даже самостоятельно установить соединение ssh с сервером, и передавать введенные администратором данные на сервер (а администратору, соответственно, ответы), так что администратор ничего не заметит.
В данной атаке самое важное - успеть ответить на запрос раньше, чем это сделает настоящий сервер, а здесь у хакера есть все преимущества: перед тем, как дать ответ, сервер должен просмотреть свою базу данных, на что ему требуется некоторе время. Хакер же может держать "фальшивый" пакет уже наготове, и съэкономить на этом драгоценные миллисекунды. Кроме того, у хакера есть возможность предварительно загрузить сервер большим количеством запросов (легкая DoS-атака), что значительно увеличит время, требуемое серверу для выдачи ответа.
Ошибки в программах и скриптах
Пожалуй, больше всего ошибок, связанных с безопасностью, допускают web-программисты в cgi-скриптах. Особенно часто такие ошибки гнездятся в скриптах, посылающих почтовые сообщения по адресу, указанному пользователем. Вот примерный код такого скрипта на языке perl:
$email=param('email');
open(MAIL,"| sendmail $email");
print MAIL "......"
Этот скрипт в первой строчке получает введенный пользователем адрес, после чего организуют конвейер (или пайп - механизм, принятый в unix и DOS, позволяющий "вывод" одной программы переправить на "ввод" другой). "Хитрый" хакер может вместе с адресом электронной почты ввести символы, "продожающие" конвейр, например cool@hacker.ru | rm -Rf /bin. Результатом подстановки такого адреса во вторую строку будет двойной конвейр: open(MAIL,"| sendmail cool@hacker.ru | rm -Rf /bin"). При выполнении этой команды текст письма будет перенаправлен на ввод команде sendmail, а вот ее вывод будет перенаправлен на ввод команде rm, которая в данном случае (если у процесса, исполняющего скрипт, хватит полномочий), удалит из системы все основные программы, расположенные в каталоге /bin.
Внутрисистемная атака
Нижеописанным способом практически при мне (но без моего участия) студентами был взломан компьютер института, и получены полномочия root. Эта атака весьма похожа не предыдущую, с той только разницей, чтохакер уже имел права обычного пользователя в системе.
В операционных системах семейства UNIX процессы выполняются от имени и с полномочиями пользователя, их запустившего. Исключение составляют программы, на который установлен аттрибут SETUID, заставляющий систему выполнить программу от имени и с полномочиями владельца программы.
Администратором институтского компьютера была написана такая программа (выпоняющая какие-то административные действия, сейчас это уже не важно). При этом администратор допустил целых три ошибки: оставил возможность запуска этой программы всем подряд (она, собственно, ничего опасного не делала), оставил на всеобщем обозрении исходный код программы, и сделал маленькую незаметную ошибочку в программе.
Ошибочка состояла в следующем: в своей программе администратор пользовался услугами другой программы (ну, предположим, passwd - изменение пользовательского пароля), и запускал ее функций execlp. В отличие от обычного execl, функции execlp не нужно передавать полный путь к программе (/bin/passwd), а достаточно передать только имя файла - passwd. Путь к программе execlp находит сама, пользуясь для этого переменной окружения PATH... казалось бы - ничего страшного, PATH то обычно и начинается с этого самого /bin... однако, пользователь имеет право менять свою собственную переменную PATH, которую и получит программа.
Юными хакерами была написана собственная программа, названа passwd, выложена в собственном каталоге. Переменная PATH была соответсвенным образом изменена, в результате чего программа администратора вместо /bin/passwd запустила на выполнение /home/.../passwd с правами администратора. К счастью для института, и несчастью для хакеров, взлом был довольно быстро обнаружен сиситемой слежения (хакерам не хватило опыта), но система после этого не работала неделю - искали оставленные хакерами "закладки".
Как видим, арсенал хакеров достаточно богат, и строится, в основном, на непродуманностях отдельных программ и базовых протоколов. Аминистраторам же приходится становиться параноиками, и подозревать всё и всех. Абсолютной защиты пока никто не создал, да и ошибки в программах выявляются каждый день пачками, но, тем не менее, в силах администратора отбить большую часть атак и снизить потенциальный ущерб от атак успешных.
Предотвращение атак
Во-первых, необходимо отказаться от использование не необходимых служб на сервере. Если Вам необходим какой-то сервис, но его можно вынести на другую машину - сделайте это. Естественно, эти машины должны быть как можно меньше логически связаны между собой - на каждой из них должна быть собственная система авторизации, пароли администраторов и пользователей, имеющих какие-либо административные привелегии не должны совпадать. Машины не должны "слепо" доверять друг-другу только потому, что они стоят в одной комнате - любое общение между ними должно быть защищено. Если какой-то сервис необходимо оставить на одной машине с критично-важными данными - попробуйте поискать информацию про известные уязвимости, и про более защищенные альтернативные реализации. Для самостоятельного изучения оставлю так-же такие средства безопасности отдельных приложений, как chroot и jail.
Если сервис не тербует для работы административных полномочий - не давайте их ему только потому, что Вам так проще. Сделайте для каждого сервиса отдельного пользователя, который будет иметь доступ только к необходимым для работы файлам - этим Вы предотвратите полный захват системы, если хакер сможет найти уязвимость в данном сервисе.
Вот примерный спикок сервисов, которые могут оказаться запущеными на Вашем сервере, и которые желательно "пристрелить", если в них нет необходимости:
|
Не менее важно для безопасности системы и само поведение администратора в системе. Учетная запись root - самый лакомый кусочек для хакера, и задача администратора - постараться не дать хакеру возможности ее заполучить, даже если хакер уже пробился в систему с пользовательскими правами, или имеет возможность перехвата сетевого трафика. Чем меньше администратор совершает действий с привилегиями учетной записи root, тем меньше риск ошибки. Вот пример того, как администратор (правда, системы Windows NT) "подарил" хакеру свой пароль. А все только потому, что воспользовался браузером из под административной учетной записи.
Хорошим правилом является заведение себе отдельной учетной записи, не обладающей административными привелегиями. Обычных пользовательских прав хватает для выяснения причин возникновения проблемы, а для ее исправления обычно достаточно выполнения всего одной-двух команд с привелениями root - для этого удобно воспользоваться командой su, которая временно даст Вам полномочия root (естественно, только после ввода пароля. Кроме того, для возможности запуска команды su пользователь должен быть членом встроенной группы wheel).
Весьма желательно не пользоваться административными правами при подключении к серверу через сеть. Даже в случае подключения по защищенному каналу ssh или VPN риск перехвата значительно возрастает по сравнению с непосредственной работой за консолью сервера. Кроме того, в этом случае приходится заботиться еще и о безопасности той машины, с которой производится подключение.
Обнаружение и нейтрализация атак
Наравне с задачей защиты системы от взлома стоит и задача своевременного обнаружения атаки и уменьшения ущерба от взлома. Ущерб, и способы его уменьшения зависят больше от функций, выполняемых системой, поэтому какие-то рекомендации, кроме набившей уже оскомину "делайте резервные копии", дать сложно. А вот обнаружение атаки на разных стадиях - дело вполне алгоритмируемое.
Одним из первых инструментов хакера при атаке на систему является сканер портов - некая программа, пытающаяся подключиться к удаленной системе по множеству известных ей протоколов для выяснения дальнейших возможных путей взлома. Функции этих программ могут быть весьма продвинутыми, а могут ограничиваться и последовательным перебором всех портов протоколов TCP и UDP, но в любом случае процесс сканирования портов можно засечь и принять соответствующие меры. Понятно, что постоянно сидеть и следить за системой администратор не будет, поэтому существуют программные средства, способные самомтоятельно засекать такие атаки, и отбивать их. Одна из таких программ - portsentry.
Установить PortSentry можно из набора портов - /usr/ports/security/portsentry (для установки программы подключитесь к сети Интернет, перейдите в этот каталог, и введите команду make install - программа будет скачана с сайта производителя и автоматически установлена в системе). После установки программы ее необходимо будет сконфигурировать, отредактировав файл /usr/local/etc/portsentry.conf.
Для начала нужно составить списки портов, попытка подключения к которым будет расцениваться, как криминал. Для этого нужно создать собственные строки TCP_PORTS и UDP_PORTS, или воспользоваться одной из имеющихся. Естественно, в список "криминальных" портов не следует включать те, на которых в Вашей системе существуют "легальные" сервисы. После создания списка "криминальных" портов необходимо настроить действие, предпринимаемое portsentry для отбивания атаки. Если в вашей системе установлен файрвол, то найдите и раскомментируйте (удалите начальный значек '#' ) строку:
KILL_ROUTE="/sbin/ipfw add 1 deny all from $TARGET$:255.255.255.255 to any"
При данной настройке portsentry запретит прохождение любых пакетов с атакующего хоста добавлением правила в файрвол. Если файрвол на вашей машине не установлен - найдите и раскомментируйте строчку:
KILL_ROUTE="route add -net $TARGET$ -netmask 255.255.255.255 127.0.0.1 -blackhole"
При данной настройке пакеты от атакующего хоста по-прежнему смогут достигать Вашего сервера, но ответные пакеты будут направлены в "черную дыру" (blackhole), и уничтожены. Это почти так-же эффективно, как и запрещение входящих пакетов с помощью firewall, но не помогает от DoS-атак.
Внимание! После перезагрузки все добавленные в файрвол правила, и добавленные в таблицу роутинга маршруты будут забыты, поэтому хакер опять сможет получить доступ к Вашей машине до первой попытки сделать что-либо запрещенное. Если Ваш сервер перезагружется достаточно часто - напишите собственный скрипт, который будет не только вносить правило в firewall, но и приписывать его к файлу настройки firewall, исполняемому при загруке системы.
К сожалению, в поставке portsentry пока не идет скрипт автоматической загрузки программы при старте системы, поэтому Вам самостоятельно придется создать файл /usr/local/etc/rc.d/portsentry.sh со следующим содержимым:
#!/bin/sh
PSENTRY="/usr/local/bin/portsentry"
case "$1" in
start)
${PSENTRY} -tcp
${PSENTRY} -udp
echo " PortSentry "
;;
stop)
killall portsentry
;;
*)
echo " "
echo "start or stop parameter required."
echo " "
;;
esac
После установки portsentry будьте крайне осторожны при администрировании сервера через сеть - при неверных действия Вы можете оказаться отключенным.
Следующая полезная утилита - tripwire, которую Вы можете установить из /usr/ports/security/tripwire. Не забудьте обновить дерево портов - из того порта, что идет вместе с FreeBSD 4.7 tripwire не устанавливается (по крайней мере, на моей машине не установилось). Самый простой вариант обновления - скачать содержимое каталога ftp4.ru.freebsd.org/pub/FreeBSD/ports/ports-stable/security/tripwire к себе в /usr/ports/security/tripwire. Более сложный, но гораздо более правильный метод - использовать CVSUpdate, но это отдельная большая тема.
Эта утилита (tripwire) предназначена для отслеживания состояния системных файлов. Хакер, проникший в систему, скорее всего попытается оставить для себя "закладки на будущее" - программы, или настройки стандартых программ, обеспечивающие хакеру более простые способы добраться до системы в следующий раз. Таких мин может быть раскидано достаточно много, в расчете на то, что администратор сервера, заметив взлом, найдет не все закладки. Tripwire облегчает поиск таких закладок, сообщая администратору о всех изменениях в потенциально опасных каталогах и файлах.
В процессе установки tripwire создаст базу данных, в которую будут занесены сведения о всех системных и конфигурационных фалйх. База по умолчанию создается в каталоге /var/db/tripwire, но в этом случае хакер может ее изменить после установки "закладок", поэтому базу желательно хранить на защищенной от записи дискете. Для этого при установке tripware надо использовать команду make install TRIPEWIRE_FLOPPY=YES. При этом, естественно, в дисководе должна находиться чистая форматированная дискета. Если на машине установлено много всякого барахла - база на дискету может и не влезть. В этом случае Вам придется самому переписать ее, например, на CDRW: если система настроена и стабильно работает, то изменения в системные файлы вносятся не часто, и перенос базы tripwire на внешние носители не будет слишком обременительным.
Информация в базе содержится в зашифрованном виде, поэтому при установке tripwire попросит Вас придумать два пароля - одним будут закодированы настройки, а другим сама база. Пароли забывать не стоит - могут пригодиться при изменении настроек и "принятия к сведению" легальных изменений в файловой системе.
При создании базы tripwire начнет ругаться на отсутствие у Вас некоторых каталогов вроде /usr/tmp и т.п. Самое обидное, что эта же ругань будет и в ежедневных отчетах. Поэтому придется немного поизучать настройку tripwire. Самый главный файл настройки - /usr/local/etc/tripwire/twpol.txt. Это обычный текстовый файл, в котором описано, какие файлы надо проверять, и с какой степенью придирчивости это делать. Файл логически состоит из двух частей: общие настройки и правила проверки. В общих настроках прописываются пути к основным файлам tripwire, и задаются символические имена для уровней "придирчивости". Список правил - это собственно и есть указания, какие каталоги проверять. Правило состоит из заголовка и тела. Заголовок имеет следующий вид:
(
rulename = "Root's home",
severity = $(SIG_HI),
emailto="admin@host.domain"
)
, где rulename - название правила, severity - уровень "придирчивости", emailto - кому сообщать о происшествиях. Строки emailto приходится к каждому правилу добавлять вручную. Тело правила выглядит следующим образом:
{
/.profile -> $(SEC_CRIT) ;
/.cshrc -> $(SEC_CRIT) ;
/.forward -> $(SEC_CRIT) ;
/root -> $(SEC_CRIT) (recurse = true) ;
!/root/.history ;
!/root/.bash_history ;
}
Тело правила представляет из себя список каталогов с необязательным указанием изменения уровня "придирчивости" и способа обработки. Также возможно исключение некоторых файлов или подкаталогов из проверяемого списка. В данном примере из списка проверки исключаются файлы истории команд, изменение которых бесполезно отслеживать, т.к. они происходят при любых действиях пользователя root. Впрочем, если Вы не собираетесь в обозримом будущем работать под этой учетной записью, их можно не исключать из списка - их изменение будет сигналом о том, что кто-то таки работал под этим логином.
twpol.txt не используется при работе tripwire напрямую. Используется его зашифрованная версия, получить которую из текстового файла можно следующим образом:
/usr/local/sbin/twadmin -m P /usr/local/etc/tripwire/twpol.txt
при этом Вам придется ввести пароль. Сам текстовый файл с настройкой политики желательно тоже хранить в недоступном хакеру месте (на дискете в ящике стола), т.к. по этому файлу он сможет вычислить области с меньшей параноидальностью проверки.
Если Вы произвели какие-то изменения в системе, и не хотите, чтобы tripwire каждый день о них рассказывал - переинициализируйте базу командой /usr/local/sbin/tripwire --update (для обновления базы) или /usr/local/sbin/tripwire --init для создания базы "с нуля". Естественно, понадобится пароль - иначе хакер тоже сможет изменить базу.
Неплохо так-же переместить все относящиеся к tripwire файлы куда-нибудь в глубины файловой системы, например /usr/src/sys/libkern/patch/7.40, чтобы уменьшить вероятность обнаружения хакером нашей системы слежения, но при этом все-равно останется "след" - где-то должен сидеть автоматический запуск tripwire с некоторой периодичностью. Стандартный способ запуска - добавить в /etc/crontab строчку
15 6 * * * root /usr/local/sbin/tripwire --check --silent --email-report
для запуска проверки каждый день в 6:15 утра, но это будет слишком быстро вычислено хакером. Более замороченным способом будет вставка вызова tripwire в какой-нибудь другой регулярно запускаемый служебный скрипт (например, подсчет статистики), достаточно сложный и неинтересный, чтобы хакеру хотелось в нем копаться, либо внесение изменения в код какого-либо постоянно исполняемого системой демона (благо исходные коды есть почти для всех программ). Переименование всех файлов tripwire во что-нибудь более безобидное тоже пойдет на пользу - тупой перебор всех каталогов на поиск слова tripwire не принесет хакеру желаемого результата.
Если предприняты меры по "прятанью" tripwire от глаз хакера, придется так-же выполнить make clean в каталоге /usr/ports/security/tripwire и удалить /usr/ports/distfiles/tripwire* для сокрытия следов сборки и установки tripwire. Правда, после этого останутся еще следы в протоколе работы почтовой системы, т.к. доставка администратору сообщений от tripwire должна быть регулярной, но tripwire можно настроить и для использвания внешнего почтового сервера. После этого можно быть уже относительно спокойным за скрытность работы tripwire. Конечно, останется еще вероятность того, что хакер будет работать в системе одновременно с работой tripwire, засечет какой-то чрезмерно активный процесс, и найдет наш замаскированный tripwire по этой ниточке, но с этим ничего не сделаешь (разве что поставить второй сервер специально для tripwire, и проверять диски через сеть), но вероятность такого обнаружения довольно мала.
Настройка tripewire - дело достаточно тонкое, т.к. неправильно настроенная tripewire засыпет Вас ложными сообщениями о неполадках в системе, в то время как настоящие нарушения могут быть пропущены. К сожалению, действительно хорошего руководства на русском языке в Интернете обнаружить не удалось, а насчет достаточности собственного опыта для написания действительно толкового полного руководства я не уверен. Тем не менее рекомендую почитать:
'http://bog.pp.ru/work/tripwire.html/'
'http://tcb.spb.ru/other/docum/linuxsos/ch12_1.html/'
а так-же все, что найдет yandex и google по этому поводу. Возможно, из моего рассказа что-то осталось непонятным - надеюсь, в этих статьях Вы сможете найти ответ на интересующие Вас вопросы по установке и первоначальному конфигурированию.
На этом предлагаю закончить экскурсию в сумасшедший дом по отделению параноиков, и в следующей главе обсудить настройку firewall'а - вещи, полезной как в плане безопасности, так и длятонкой настройки работы сервера доступа.
(C) 2002 by Kuzmich
Настройка firewall FreeBSD
Обновлено: 13.09.2025
FreeBSD 4.x и 5.x позволяет настроить сетевой экран (firewall) очень просто. С помощью сетевого экрана Вы можете защитить как один сервер, так и всю сеть. Также Вы можете легко включить поддержу трансляции сетевых адресов (NAT) для того, чтобы компьютеры из Вашей внутренней сети могли получить доступ к внешней сети используя всего один внешний IP адрес.
Для этого необходимы три простых шага
1. Во-первых, Вам будет необходимо внести несколько изменений в Ваше ядро. На самом деле это не так сложно, как звучит на первый взгяд. Используйте команду su для того, чтобы получить права суперпользователя, при помощи команды cd перейдите в каталог /usr/src/sys/i386/conf, скопируйте файл GENERIC в новый файл. Назовём его, к примеру, ROUTER. Этот файл будет Вашим новым конфигурационным файлом Вашего ядра. Ниже приведены изменения, которые Вам необходимо будет внести:
--- GENERIC Sun Jul 6 17:09:42 2003 +++ ROUTER Sun Jul 6 17:11:06 2003 @@ -22,7 +22,7 @@ cpu I486_CPU cpu I586_CPU cpu I686_CPU -ident GENERIC +ident ROUTER maxusers 0 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols @@ -259,3 +259,9 @@ device aue # ADMtek USB ethernet device cue # CATC USB ethernet device kue # Kawasaki LSI USB ethernet + +# Enable ipfw and natd. +options IPFIREWALL +options IPFIREWALL_VERBOSE +options IPDIVERT +options DUMMYNET
2. Другими словами, Вам необходимо будет изменить идентификатор (ident) ядра и добавить опции для включения сетевого экрана в ядре. После настройки конфигурационного файла скомпилируйте и установите новое ядро:
# cd /usr/src # make buildkernel KERNCONF=ROUTER # make installkernel KERNCONF=ROUTER
# Enable firewall firewall_enable="YES" firewall_type="type" firewall_quiet="NO"
Переменная firewall_type должна быть установлена в значение "client" для того, чтобы защитить отдельностоящую машину или в "simple" для шлюза, защищающего внутреннюю сеть. Если Вам необходимо также поддержка трансляции сетевых адресов (NAT), добавьте нижеследующие установки:
# Enable natd. natd_enable="YES" natd_interface="fxp0" # your public network interface natd_flags="-m" # preserve port numbers if possible
3. В-третьих, Вам будет необходимо сделать несколько правок в файле rc.firewall. Комментарии в нём помогут Вам понять, что необходимо, это действительно очень просто. Найдите раздел с правилами для Вашего типа сетевого экрана (firewall), как то: "client" или "simple". В начале раздела Вы найдете несколько переменных, указывающих Ваши IP адреса, сетевые интерфейсы и т.д.; заполните их.
Вот и все, по крайней мере для начальной настройки. Перезагрузите машину и Вы получите настроеный и работающий сетевой экран (firewall).
Важное замечание о исправлении неполадок (troubleshooting)
Сетевой экран (firewall) в FreeBSD спроектирован так, что он безопасен по умолчанию. Если Вы включите его и не добавите никаких правил, он не будет пропускать никаких пакетов. Это означает, что, если Вы что-то сделаете неправильно в Вашем файле конфигурации сетевого экрана (firewall), Вы можете оказаться в ситуации, в которой не сможете получить доступ к Вашей машине через сеть для того, чтобы исправить это. Вам понадобится зайти на машину через системную консоль (клавиатуру, подсоединённую к машине).
Это случилось со мной один раз во время тестирования. Это не большая проблема, если Вы понимаете, что происходит. Очень просто исправить ситуацию, если Вы имеете доступ к консоли; просто отредактируйте файл /etc/rc.conf, установив firewall_type в значение "open" или просто закомментируйте строки, относящиеся к firewall и перезагрузитесь. Но будьте бдительны, если Вы настраиваете Ваш сетевой экран через сеть.
Замечание о FTP
Настройки сетевого экрана, подобные этим, не дают возможности работать FTP. На самом деле, это вина FTP. FTP - это старомодный и черезчур усложнённый протокол, который требует от сервера инициировать обратное соединение к клиенту. Так как сетевые экраны запрещают открытие нового соединения извне (кроме некоторых протоколов типа SMTP или ssh), FTP не работает.
Есть обходное решение - использовать "пассивный" режим работы FTP, который заставляет проводить работу в обычном режиме клиент-сервер. Каждый раз, когда Вы будете использовать клиента FTP просто отдайте команду, которая включает пассивный режим. В новых версиях FTP клиента Вы можете сделать этот режим режимом по умолчанию при помощи переменной окружения FTP_PASSIVE_MODE, установленное в значение "yes". Современные веб-браузеры используют этот режим по умолчанию и/или позволяют включить его использование по умолчанию в настройках.
Другое обходное решение - избегать использования FTP и использовать HTTP или scp.
Более сложные темы
Как только Вы настроите сетевой экран, Вы можете найти, что Вас не устраивают те наборы правил, которые включены в файл rc.firewall. Если это так, то Вы можете очень просто написать свои собственные. Первое, что Вы можете сделать, это разрешить соединения ssh. (ssh - это безопасная замена для telnet/rlogin; Вы можете его найти в базовой системе или в коллекции портов). В том месте набора правил, где разрешается соединение для входящей почты, добавьте подобное правило для ssh путём копирования и последующего изменения номера порта с 25 на 22.
Или Вы можете взять контроль в свои руки и написать совершенно новый набор правил. Для этой статьи у меня получилось два таких набора: router-solo и router-net, которые являются улучшеными версиями стандартных наборов "client" и "simple". Вот что у меня получилось (комментарии на английском дабы избежать возможных проблем, связанных с пониманием /bin/sh кириллических символов):
[Rr][Oo][Uu][Tt][Ee][Rr]-[Ss][Oo][Ll][Oo])
############
# ROUTER single-machine custom firewall setup. Protects somewhat
# against the outside world.
############
# Set this to your ip address.
ip="192.168.0.1"
# Allow communications through loopback interface and deny 127.0.0.1/8
# from any other interfaces
setup_loopback
# Allow anything outbound from this address.
${fwcmd} add allow all from ${ip} to any out
# Deny anything outbound from other addresses.
${fwcmd} add deny log all from any to any out
# Allow TCP through if setup succeeded.
${fwcmd} add allow tcp from any to any established
# Allow IP fragments to pass through.
${fwcmd} add allow all from any to any frag
# Allow inbound ftp, ssh, email, tcp-dns, http, https, pop3, pop3s.
${fwcmd} add allow tcp from any to ${ip} 21 setup
${fwcmd} add allow tcp from any to ${ip} 22 setup
${fwcmd} add allow tcp from any to ${ip} 25 setup
${fwcmd} add allow tcp from any to ${ip} 53 setup
${fwcmd} add allow tcp from any to ${ip} 80 setup
${fwcmd} add allow tcp from any to ${ip} 443 setup
${fwcmd} add allow tcp from any to ${ip} 110 setup
${fwcmd} add allow tcp from any to ${ip} 995 setup
# Deny inbound auth, netbios, ldap, and Microsoft's DB protocol
# without logging.
${fwcmd} add deny tcp from any to ${ip} 113 setup
${fwcmd} add deny tcp from any to ${ip} 139 setup
${fwcmd} add deny tcp from any to ${ip} 389 setup
${fwcmd} add deny tcp from any to ${ip} 445 setup
# Deny some chatty UDP broadcast protocols without logging.
${fwcmd} add deny udp from any 137 to any
${fwcmd} add deny udp from any to any 137
${fwcmd} add deny udp from any 138 to any
${fwcmd} add deny udp from any 513 to any
${fwcmd} add deny udp from any 525 to any
# Allow inbound DNS and NTP replies. This is somewhat of a hole,
# since we're looking at the incoming port number, which can be
# faked, but that's just the way DNS and NTP work.
${fwcmd} add allow udp from any 53 to ${ip}
${fwcmd} add allow udp from any 123 to ${ip}
# Allow inbound DNS queries.
${fwcmd} add allow udp from any to ${ip} 53
# Deny inbound NTP queries without logging.
${fwcmd} add deny udp from any to ${ip} 123
# Allow traceroute to function, but not to get in.
${fwcmd} add unreach port udp from any to ${ip} 33435-33524
# Allow some inbound icmps - echo reply, dest unreach, source quench,
# echo, ttl exceeded.
${fwcmd} add allow icmp from any to any icmptypes 0,3,4,8,11
# Everything else is denied and logged.
${fwcmd} add deny log all from any to any
;;
[Rr][Oo][Uu][Tt][Ee][Rr]-[Nn][Ee][Tt])
############
# ROUTER network custom firewall setup. The assumption here is that
# the internal hosts are trusted, and can do anything they want.
# The only thing we have to be careful about is what comes in over
# the outside interface. So, you'll see a lot of "in via ${oif}"
# clauses here.
############
# Set these to your outside interface network and netmask and ip.
oif="fxp0"
onet="217.20.160.0"
omask="255.255.255.0"
oip="217.20.160.1"
# Set these to your inside interface network and netmask and ip.
iif="fxp1"
inet="192.168.0.0"
imask="255.255.255.0"
iip="192.168.0.1"
# Allow communications through loopback interface and deny 127.0.0.1/8
# from any other interfaces
setup_loopback
# Stop spoofing
${fwcmd} add deny log all from ${inet}:${imask} to any in via ${oif}
${fwcmd} add deny log all from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
${fwcmd} add deny log all from any to 10.0.0.0/8 via ${oif}
${fwcmd} add deny log all from any to 172.16.0.0/12 via ${oif}
${fwcmd} add deny log all from any to 192.168.0.0/16 via ${oif}
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E),
# RFC 3330 nets on the outside interface
${fwcmd} add deny log all from any to 0.0.0.0/8 via ${oif}
${fwcmd} add deny log all from any to 169.254.0.0/16 via ${oif}
${fwcmd} add deny log all from any to 192.0.2.0/24 via ${oif}
${fwcmd} add deny log all from any to 198.18.0.0/15 via ${oif}
${fwcmd} add deny log all from any to 224.0.0.0/4 via ${oif}
${fwcmd} add deny log all from any to 240.0.0.0/4 via ${oif}
# Network Address Translation. This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules. If for example one of your internal LAN machines had its IP
# address set to 192.168.0.2 then an incoming packet for it after being
# translated by natd(8) would match the `deny' rule above. Similarly
# an outgoing packet originated from it before being translated would
# match the `deny' rule below.
case ${natd_enable} in
[Yy][Ee][Ss])
if [ -n "${natd_interface}" ]; then
${fwcmd} add divert natd all from any to any via ${natd_interface}
fi
;;
esac
# Stop RFC1918 nets on the outside interface
${fwcmd} add deny log all from 10.0.0.0/8 to any via ${oif}
${fwcmd} add deny log all from 172.16.0.0/12 to any via ${oif}
${fwcmd} add deny log all from 192.168.0.0/16 to any via ${oif}
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E),
# RFC 3330 nets on the outside interface
${fwcmd} add deny log all from 0.0.0.0/8 to any via ${oif}
${fwcmd} add deny log all from 169.254.0.0/16 to any via ${oif}
${fwcmd} add deny log all from 192.0.2.0/24 to any via ${oif}
${fwcmd} add deny log all from 198.18.0.0/15 to any via ${oif}
${fwcmd} add deny log all from 224.0.0.0/4 to any via ${oif}
${fwcmd} add deny log all from 240.0.0.0/4 to any via ${oif}
# Allow anything on the internal net
${fwcmd} add allow all from any to any via ${iif}
# Allow anything outbound from this net.
${fwcmd} add allow all from ${onet}:${omask} to any out via ${oif}
# Deny anything outbound from other nets.
${fwcmd} add deny log all from any to any out via ${oif}
# Allow TCP through if setup succeeded.
${fwcmd} add allow tcp from any to any established
# Allow IP fragments to pass through.
${fwcmd} add allow all from any to any frag
# Allow inbound ftp, ssh, email, tcp-dns, http, https, pop3, pop3s.
${fwcmd} add allow tcp from any to ${oip} 21 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 22 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 25 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 53 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 80 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 443 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 110 setup in via ${oif}
${fwcmd} add allow tcp from any to ${oip} 995 setup in via ${oif}
# Deny inbound auth, netbios, ldap, and Microsoft's DB protocol
# without logging.
${fwcmd} add deny tcp from any to ${oip} 113 setup in via ${oif}
${fwcmd} add deny tcp from any to ${oip} 139 setup in via ${oif}
${fwcmd} add deny tcp from any to ${oip} 389 setup in via ${oif}
${fwcmd} add deny tcp from any to ${oip} 445 setup in via ${oif}
# Deny some chatty UDP broadcast protocols without logging.
${fwcmd} add deny udp from any 137 to any in via ${oif}
${fwcmd} add deny udp from any to any 137 in via ${oif}
${fwcmd} add deny udp from any 138 to any in via ${oif}
${fwcmd} add deny udp from any 513 to any in via ${oif}
${fwcmd} add deny udp from any 525 to any in via ${oif}
# Allow inbound DNS and NTP replies. This is somewhat of a hole,
# since we're looking at the incoming port number, which can be
# faked, but that's just the way DNS and NTP work.
${fwcmd} add allow udp from any 53 to ${oip} in via ${oif}
${fwcmd} add allow udp from any 123 to ${oip} in via ${oif}
# Allow inbound DNS queries.
${fwcmd} add allow udp from any to ${oip} 53 in via ${oif}
# Deny inbound NTP queries without logging.
${fwcmd} add deny udp from any to ${oip} 123 in via ${oif}
# Allow traceroute to function, but not to get in.
${fwcmd} add unreach port udp from any to ${oip} 33435-33524 in via ${oif}
# Allow some inbound icmps - echo reply, dest unreach, source quench,
# echo, ttl exceeded.
${fwcmd} add allow icmp from any to any in via ${oif} icmptypes 0,3,4,8,11
# Broadcasts are denied and not logged.
${fwcmd} add deny all from any to 255.255.255.255
# Everything else is denied and logged.
${fwcmd} add deny log all from any to any
(c) 2003, Alexandr Kovalenko <never АТ nevermind.kiev.ua>
Настройка VPN через IPsec. Руководство FreeBSD
Обновлено: 13.09.2025
| Руководство FreeBSD |
| Глава 14. Безопасность |
14.10. VPN через IPsec
Написал Nik Clayton.Создание VPN между двумя сетями, соединенными через интернет, с использованием шлюзов FreeBSD.
14.10.1. Принципы работы IPsec
Написал Hiten M. Pandya.Этот раздел послужит вам руководством по настройке IPsec и его использованию в среде FreeBSD и Microsoft® Windows® 2000/XP, соединяемых безопасным способом. Для настройки IPsec необходимо ознакомиться с процессом сборки ядра (Гл. 8).
IPsec это протокол, расположенный поверх слоя Internet Protocol (IP). Он позволяет двум или более хостам связываться защищенным способом (отсюда и название протокола). ''Сетевой стек'' FreeBSD IPsec основан на реализации KAME, поддерживающей оба семейства протоколов, IPv4 и IPv6.
Замечание: FreeBSD содержит ''аппаратно поддерживаемый'' стек IPsec, известный как ''Fast IPsec'', заимствованный из OpenBSD. Для оптимизации производительности IPsec он задействует криптографическое оборудование (когда оно доступно) через подсистему crypto(4). Это новая подсистема и она не поддерживает всех возможностей, доступных в KAME версии IPsec. Для включения IPsec с аппаратной поддержкой необходимо добавить в файл настройки ядра следующий параметр:
options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)Обратите внимание, что на данный момент невозможно использовать подсистему ''Fast IPsec'' вместе с KAME реализацией IPsec. Обратитесь к странице справочника fast_ipsec(4) за дальнейшей информацией.
Замечание: Для того, чтобы применять к туннелям gif(4) межсетевые экраны, вам потребуется включить в ядро опцию
IPSEC_FILTERGIF:options IPSEC_FILTERGIF #filter ipsec packets from a tunnel
IPsec состоит из двух подпротоколов:
-
Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES).
-
Authentication Header (AH), защищающий заголовок IP пакета от вмешательства третьей стороны и подделки путем вычисления криптографической контрольной суммы и хеширования полей заголовка IP пакета защищенной функцией хеширования. К пакету добавляется дополнительный заголовок с хэшем, позволяющий аутентификацию информации пакета.
ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.
IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения ''виртуальных туннелей'' между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Последний обычно называют виртуальной частной сетью (Virtual Private Network, VPN). За детальной информацией о подсистеме IPsec в FreeBSD обратитесь к странице справочника ipsec(4).
Для включения поддержки IPsec в ядре, добавьте следующие параметры к файлу настройки ядра:
options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC)
Если желательна поддержка отладки IPsec, должна быть также добавлена следующая строка:
options IPSEC_DEBUG #debug for IP security
14.10.2. Проблема
Не существует стандарта VPN. Они могут быть реализованы множеством различных технологий, каждая из которых имеет свои сильные и слабые стороны. Этот раздел представляет сценарий и стратегию реализации VPN для этого сценария.
14.10.3. Сценарий: Две сети, подключенных к интернет, работающие как одна
Исходные условия таковы:
-
Существует как минимум две сети
-
Внутри обеих сетей используется IP
-
Обе сети соединены через интернет через шлюз, работающий на FreeBSD.
-
У шлюза каждой из сетей есть как минимум один публичный IP адрес.
-
Внутренние IP адреса двух сетей могут быть публичными или приватными, не имеет значения. На шлюзе может работать NAT, если это необходимо.
-
Внутренние IP адреса двух сетей не должны пересекаться. Хотя вероятно теоретически возможно использование комбинации VPN технологии и NAT для настройки такой конфигурации, эта конфигурация будет кошмарна.
Если две сети, которые вы пытаетесь соединить, используют один и тот же диапазон приватных адресов (например, обе используют 192.168.1.x), номера в одной из сетей необходимо изменить.
Топология сети может выглядеть примерно так:
Заметьте, что здесь присутствуют два публичных IP-адреса. В дальнейшем для их обозначения будут использоваться буквы. Если вы увидите эти буквы, замените их на свои публичные IP адреса. Также обратите внимание, что у обеих шлюзов внутренний адрес заканчивается на .1 и диапазоны приватных адресов двух сетей различны (192.168.1.x и 192.168.2.x соответственно). Все компьютеры локальных сетей настроены на использование в качестве шлюза по умолчанию компьютера с адресом, оканчивающимся на .1.
С сетевой точки зрения замысел в том, чтобы каждая сеть видела компьютеры из другой сети так, как если бы они были непосредственно подключены к тому же самому маршрутизатору -- хотя и немного медленному маршрутизатору, иногда теряющему пакеты.
Это означает, что (например) компьютер 192.168.1.20 может запустить
ping 192.168.2.34
и это будет прозрачно работать. Компьютеры с Windows должны видеть компьютеры в другой сети, просматривать сетевые ресурсы, и так далее, точно так же, как и для компьютеров в локальной сети.
И все это безопасным способом. Это означает, что трафик между сетями зашифрован.
Создание VPN между этими двумя сетями это многошаговый процесс. Этапы создания VPN таковы:
-
Создание ''виртуального'' сетевого подключения между двумя сетями через интернет. Тестирование подключения с помощью таких инструментов как ping(8), чтобы убедиться, что оно работает.
-
Применение политики безопасности чтобы убедиться, что трафик между двумя сетями прозрачно шифруется и расшифровывается если необходимо. Тестирование с помощью таких инструментов как tcpdump(1), чтобы убедиться, что трафик шифруется.
-
Настройка дополнительных программ на шлюзах FreeBSD, чтобы компьютеры Windows из одной сети видели компьютеры в другой через VPN.
14.10.3.1. Шаг 1: Создание и тестирование ''виртуального'' сетевого подключения
Предположим, что вы работаете на шлюзе сети #1 (с публичным адресом A.B.C.D, приватным адресом 192.168.1.1) и запускаете ping 192.168.2.1, т.е. на приватный адрес машины с IP адресом W.X.Y.Z. Что должно произойти, чтобы это сработало?
-
Шлюз должен знать, как достичь 192.168.2.1. Другими словами, у него должен быть маршрут к 192.168.2.1.
-
Приватные IP адреса, такие как диапазон 192.168.x не адресуются в интернет. Каждый пакет, отправляемый на 192.168.2.1 должен быть ''завернут'' в другой пакет. Исходным адресом пакета должен быть A.B.C.D, а адресом назначения W.X.Y.Z. Этот процесс называется инкапсуляцией.
-
Как только этот пакет достигнет W.X.Y.Z, необходимо будет ''декапсулировать'' его и доставить к 192.168.2.1.
Как вы можете увидеть, это требует ''туннеля'' между двумя сетями. Два конца ''туннеля'' это IP адреса A.B.C.D и W.X.Y.Z. Туннель используется для передачи трафика с приватными IP адресами через интернет.
В FreeBSD этот туннель создается с помощью устройства generic interface, или gif. Как вы можете догадаться, интерфейс gif на каждом хосте должен быть настроен с четырьмя IP адресами; два для публичных IP адресов и два для приватных IP адресов.
В ядро обеих компьютеров FreeBSD должна быть встроена поддержка устройства gif. Вы можете сделать это, добавив строку:
device gif
к файлу настройки ядра на обеих компьютерах, с последующей компиляцией, установкой и перезагрузкой.
Настройка туннеля это двухшаговый процесс. Во-первых, необходимо задать сведения о внешнем (или публичном) IP адресе с помощью ifconfig(8). Затем о приватном IP адресе, также с помощью ifconfig(8).
На шлюзе сети #1 для настройки туннеля вам потребуется запустить следующие две команды.
ifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
На другом шлюзе подобные команды, но с IP адресами в обратном порядке.
ifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
Затем вы можете запустить:
ifconfig gif0
для просмотра настройки. Например, на шлюзе сети #1 вы увидите:
# ifconfig gif0
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z
Как вы можете видеть, был создан туннель между физическими адресами A.B.C.D и W.X.Y.Z, для туннелирования разрешен трафик между 192.168.1.1 и 192.168.2.1.
Это также добавляет запись к таблице маршрутизации на обеих машинах, вы можете проверить запись командой netstat -rn. Вот вывод этой команды на шлюзе сети #1.
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
...
192.168.2.1 192.168.1.1 UH 0 0 gif0
...
Как показывает значение поля ''Flags'', это маршрут к хосту, что означает, что каждый шлюз знает, как достичь другого шлюза, но не знает как достичь остальной части соответствующей сети. Эта проблема будет быстро решена.
Вероятно, на обеих машинах запущен брандмауэр. VPN должен обходить его. Вы можете разрешить весь трафик между двумя сетями, или включить правила, защищающие каждый конец соединения от другого.
Это сильно упрощает тестирование настройки брандмауэра, если вы разрешаете весь трафик через VPN. Вы всегда можете Вы всегда можете усилить защиту позже. Если вы используете на шлюзах ipfw(8), команда вроде этой
ipfw add 1 allow ip from any to any via gif0
разрешит весь трафик между двумя концами VPN без влияния на другие правила брандмауэра. Очевидно, вам потребуется запустить эту команду на обеих шлюзах.
Этого достаточно для включения ping с одного шлюза на другой. На 192.168.1.1, вы сможете запустить
ping 192.168.2.1
и получить ответ, и аналогично на другом шлюзе.
Однако, машины в другой сети пока недоступны. Это из-за маршрутизации -- хотя шлюзы знают, как связаться друг с другом, они не знают, как связаться с сетью за другим шлюзом.
Для решения этой проблемы вы должны добавить статический маршрут на каждом шлюзе. Команда на первом шлюзе будет выглядеть так:
route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
Она говорит ''Для достижения хостов в сети 192.168.2.0, отправляйте пакеты хосту 192.168.2.1''. Вам потребуется запустить похожую команду на другом шлюзе, но с адресами 192.168.1.x.
IP трафик с хостов в одной сети теперь может достичь хосты в другой сети.
Теперь создано две трети VPN между двумя сетями, поскольку это ''виртуальная (virtual)'' ''сеть (network)''. Она еще не приватная (private). Вы можете протестировать ее с помощью ping(8) и tcpdump(1). Войдите на шлюз и запустите
tcpdump dst host 192.168.2.1
В другой сессии на этом же хосте запустите
ping 192.168.2.1
Вы увидите примерно такие строки:
16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply
Как вы видите, ICMP сообщения пересылаются вперед и назад незашифрованными. Если вы использовали с tcpdump(1) параметр -s для получения большего объема данных пакета, то увидите больше информации.
Конечно же это неприемлемо. В следующем разделе мы обсудим защиту соединения между двумя сетями, так что весь трафик будет автоматически шифроваться.
Резюме:
-
Настройте оба ядра с ''device gif''.
-
Отредактируйте /etc/rc.conf на шлюзе #1 и добавьте следующие строки (подставляя IP адреса где необходимо).
gifconfig_gif0="A.B.C.D W.X.Y.Z" ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff" static_routes="vpn" route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00" -
Отредактируйте скрипт брандмауэра (/etc/rc.firewall, или подобный) на обеих хостах и добавьте
ipfw add 1 allow ip from any to any via gif0
-
Выполните соответствующие изменения в /etc/rc.conf на шлюзе #2, меняя порядок IP адресов.
14.10.3.2. Шаг 2: Защита соединения
Для защиты соединения мы будем использовать IPsec. IPsec предоставляет хостам механизм определения ключа для шифрования и для последующего использования этого ключа для шифрования данных между двумя хостами.
Здесь будут рассмотрены два аспекта настройки.
-
У хостов должен быть способ согласования используемого алгоритма шифрования. Как только хосты договорятся об этом, можно говорить об установленном между ними ''безопасном соединении''.
-
Должен быть механизм определения, какой трафик необходимо шифровать. Конечно, вам не требуется шифровать весь исходящий трафик -- достаточно шифровать только трафик, идущий через VPN. Правила, определяющие то, какой трафик необходимо шифровать, называются ''политикой безопасности''.
Безопасное соединение и политика безопасности поддерживаются ядром, и могут быть изменены программами пользователя. Однако перед тем, как вы сможете сделать это, необходимо настроить поддержку протоколов IPsec и Encapsulated Security Payload (ESP) в ядре. Это делается добавлением в настройку ядра параметров:
options IPSEC options IPSEC_ESP
с последующим перекомпилированием, переустановкой и перезагрузкой. Как и прежде вам потребуется сделать это с ядрами на обеих шлюзах.
При настройке параметров безопасности (security associations) у вас есть два варианта. Вы можете настроить их вручную для обеих хостов, задав алгоритм шифрования, ключи для шифрования и так далее, или использовать даемоны, реализующие Internet Key Exchange protocol (IKE), который сделает это за вас.
Рекомендуется последнее. Помимо прочего, этот способ более прост.
Редактирование и отображение политики безопасности выполняется с помощью setkey(8). По аналогии, setkey используется для настройки таблиц политики безопасности ядра так же, как route(8) используется для настройки таблиц маршрутизации ядра. setkey также может отображать текущие параметры безопасности, и продолжая аналогию дальше, это соответствует netstat -r.
Существует множество даемонов для управления параметрами безопасности в FreeBSD. Здесь будет описано использование одного из них, racoon -- он доступен в составе порта security/ipsec-tools в Коллекции Портов FreeBSD.
Даемон racoon должен работать на обеих шлюзах. На каждом из хостов он настраивается с IP адресом другого конца VPN, и секретным ключом (по вашему выбору, должен быть одним и тем же на обеих шлюзах).
Эти два даемона подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много -- он сломал ключ, который два даемона уже сменили на другой.
Настройки racoon сохраняются в файле ${PREFIX}/etc/racoon. Этот файл не требует слишком больших изменений. Другим компонентом настройки racoon, который потребуется изменить, является ''предварительный ключ''.
В настройке по умолчанию racoon ищет его в файле ${PREFIX}/etc/racoon/psk.txt. Необходимо отметить, что предварительный ключ не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу.
psk.txt содержит строку для каждого удаленного сервера, с которым происходит соединение. В этом примере два сервера, каждый файл psk.txt будет содержать одну строку (каждый конец VPN общается только с другим концом.
На шлюзе #1 эта строка будет выглядеть примерно так:
W.X.Y.Z secret
То есть публичный IP-адрес противоположной стороны, пробел и текстовая строка c секретной фразой. Конечно, вам не стоит использовать в качестве ключевой фразы слово ''secret'' -- здесь применяются обычные правила выбора паролей.
На шлюзе #2 строка будет выглядеть примерно так:
A.B.C.D secret
То есть публичный IP адрес удаленной стороны и та же секретная фраза. Перед запуском racoon режим доступа к файлу psk.txt должен быть установлен в 0600 (т.е. запись и чтение только для root).
Вы должны запустить racoon на обоих шлюзах. Вам также потребуется добавить правила для включения IKE трафика, передающегося по UDP через порт ISAKMP (Internet Security Association Key Management Protocol). Опять же, они должны быть расположены насколько возможно ближе к началу набора правил.
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
Как только racoon будет запущен, вы можете попробовать выполнить ping с одного шлюза на другой. Соединение все еще не зашифровано, но racoon установит параметры безопасности между двумя хостами -- это может занять время и вы можете заметить небольшую задержку перед началом ответа команды ping.
Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите
setkey -D
на любом из хостов для просмотра информации о параметрах безопасности.
Это одна сторона проблемы. Другая сторона это настройка политики безопасности.
Для создания разумной политики безопасности давайте вспомним, что уже было настроено. Это рассмотрение относится к обеим концам соединения.
Каждый отправляемый IP пакет имеет заголовок, содержащий информацию о пакете. Заголовок включает IP адреса источника и назначения. Как мы уже знаем, приватные IP адреса, такие как 192.168.x.y, не могут появиться в интернет. Они должны быть сначала включены внутрь другого пакета. В этом пакете приватные IP адреса источника и назначения заменяются публичными IP адресами.
То есть исходящий пакет, который выглядит примерно так:
будет инкапсулирован в другой пакет, выглядящий примерно так:
Этой инкапсуляцией занимается устройство gif. Как вы можете видеть, теперь у пакета есть реальный IP адрес, исходный пакет был включен в этот пакет в виде данных, которые передаются через интернет.
Конечно, мы хотим зашифровать весь трафик между VPN. Вы можете сформулировать это на словах так:
''Если пакет отправляется с A.B.C.D, и предназначен для W.X.Y.Z, расшифровать его, используя необходимые параметры безопасности.''
''Если пакет отправляется с W.X.Y.Z, и предназначен для A.B.C.D, расшифровать его, используя необходимые параметры безопасности.''
Это похоже на желаемое, но не совсем то. Если вы сделаете это, весь трафик от и к W.X.Y.Z, даже если он не является частью VPN, будет зашифрован. Правильная политика такова:
''Если пакет отправляется с A.B.C.D, в нем инкапсулирован другой пакет и адрес назначения W.X.Y.Z, зашифровать его, используя необходимые параметры безопасности.''
''Если пакет отправляется с W.X.Y.Z, в нем инкапсулирован другой пакет и адрес назначения A.B.C.D, зашифровать его, используя необходимые параметры безопасности.''
Тонкое, но необходимое различие.
Политика безопасности также устанавливается с использованием setkey(8). В setkey(8) предусмотрен язык определения политики setkey(8). Вы можете или ввести инструкции по настройке со стандартного ввода, или использовать параметр -f для задания файла, содержащего эти инструкции.
Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика:
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
Поместите эти команды в файл (например, /etc/ipsec.conf) и запустите
# setkey -f /etc/ipsec.conf
spdadd указывает setkey(8) добавить правило к базе данных политики безопасности. Остальная часть строки указывает какие пакеты будут соответствовать политике. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec -- то, что пакеты будут зашифрованы.
Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.
Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
Обратите внимание, что вместо in используется out и IP адреса переставлены.
Другому шлюзу (с публичным IP адресом W.X.Y.Z) потребуются похожие правила.
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
Наконец, вам потребуется добавить правила к брандмауэру для включения прохождения пакетов ESP и IPENCAP в обе стороны. На обеих хостах потребуется добавить следующие правила:
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
Поскольку правила симметричны, можно использовать их без изменения на обеих хостах
Исходящие пакеты теперь будут выглядеть примерно так:
Когда эти пакеты будут получены на удаленном конце VPN соединения, они будут расшифрованы (используя параметры безопасности, о которых договорился racoon). Затем они будут переданы интерфейсу gif, который ''развернет'' второй слой, оставив пакет с внутренними адресами, который сможет попасть во внутреннюю сеть.
Вы можете проверить безопасность тем же ping(8), который использовался ранее. Сначала войдите на шлюз A.B.C.D и запустите:
tcpdump dst host 192.168.2.1
В другой сессии на том же хосте запустите
ping 192.168.2.1
В этот момент вы должны увидеть примерно это:
XXX tcpdump output
Теперь, как видите, tcpdump(1) показывает ESP пакеты. Если вы попытаетесь просмотреть их с параметром -s, то вероятно увидите нечто непонятное, поскольку применяется шифрование.
Поздравляем. Вы только что настроили VPN между двумя удаленными сетями.
Резюме
-
Настройте оба ядра с:
options IPSEC options IPSEC_ESP -
Установите security/ipsec-tools. Отредактируйте ${PREFIX}/etc/racoon/psk.txt на обеих шлюзах, добавив запись для каждого IP адреса удаленного хоста и секретный ключ, который будет известен им обеим. Убедитесь, что режим доступа к файлу 0600.
-
Добавьте к /etc/rc.conf на каждом хосте следующие строки:
ipsec_enable="YES" ipsec_file="/etc/ipsec.conf" -
Создайте /etc/ipsec.conf на каждом хосте с необходимыми строками spdadd. На шлюзе #1 он будет таким:
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
А на шлюзе #2 таким:
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
-
Добавьте правила к брандмауэрам обеих хостов для включения IKE, ESP и IPENCAP трафика:
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
Двух приведенных шагов должно быть достаточно для настройки и включения VPN. Машины в каждой сети смогут обращаться друг к другу по IP адресам, и весь трафик через соединение будет автоматически надежно зашифрован.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.
Руководство FreeBSD: Глава 14. Безопасность: OpenSSL
Обновлено: 13.09.2025
| Руководство FreeBSD |
| Глава 14. Безопасность |
14.9. OpenSSL
Написал: Tom Rhodes.Одной из программ, требующих особого внимания пользователей, является набор программ OpenSSL, включенный в FreeBSD. OpenSSL предоставляет уровень шифрования поверх обычных уровней соединения; следовательно, он может быть использован многими сетевыми приложениями и сервисами.
OpenSSL может использоваться для шифрования соединений почтовых клиентов, транзакций через интернет, например для кредитных карт, и многого другого. Многие порты, такие как www/apache13-ssl и mail/sylpheed-claws собираются с OpenSSL.
Замечание: В большинстве случаев в Коллекции Портов будет сделана попытка построения порта security/openssl, если только переменная WITH_OPENSSL_BASE не установлена явно в ''yes''.
Версия OpenSSL, включаемая в FreeBSD, поддерживает сетевые протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) и может быть использована в качестве основной криптографической библиотеки.
Замечание: Хотя OpenSSL поддерживает алгоритм IDEA, по умолчанию он отключен из-за патентных ограничений Соединенных Штатов. Для его использования необходимо ознакомиться с лицензией, и, если ограничения приемлемы, установить в make.conf переменную MAKE_IDEA.
Наиболее часто OpenSSL используется для создания сертификатов, используемых программными пакетами. Эти сертификаты подтверждают, что данные компании или частного лица верны и не подделаны. Если рассматриваемый сертификат не был проверен одним из нескольких сертификационных центров (''Certificate Authorities'' - CA), обычно выводится предупреждение. Центр сертификации представляет собой компанию, такую, как VeriSign, которая подписывает сертификаты для подтверждения данных частных лиц или компаний. Эта процедура не бесплатна и не является абсолютно необходимой для использования сертификатов; однако может успокоить некоторых особо осторожных пользователей.
14.9.1. Генерирование сертификатов
Для генерирования сертификатов доступна следующая команда:
# openssl req -new -nodes -out req.pem -keyout cert.pem Generating a 1024 bit RSA private key ................++++++ .......................................++++++ writing new private key to 'cert.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:PA Locality Name (eg, city) []:Pittsburgh Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Systems Administrator Common Name (eg, YOUR name) []:localhost.example.org Email Address []:trhodes@FreeBSD.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:SOME PASSWORD An optional company name []:Another Name
Ввод после приглашения ''Common Name'' содержит имя домена. Здесь вводится имя сервера для верификации; помещение в это поле чего-либо кроме этого имени приведет к созданию бесполезного сертификата. Доступны и другие параметры, например срок действия, альтернативные алгоритмы шифрования и т.д. Полный список находится на странице справочного руководства openssl(1).
В текущем каталоге, из которого была вызвана вышеуказанная команда, должны появиться два файла. Файл req.pem с запросом на сертификацию может быть послан в центр выдачи сертификатов, который проверит введённые вами подтверждающие данные, подпишет запрос и возвратит сертификат вам. Второй созданный файл будет иметь название cert.pem и содержать приватный сертификационный ключ, который необходимо тщательно защищать; если он попадёт в руки посторонних лиц, то может быть использован для имитации лично вас (или вашего сервера).
Когда подпись CA не требуется, может быть создан самоподписанный сертификат. Сначала создайте ключ RSA:
# openssl dsaparam -rand -genkey -out myRSA.key 1024
Теперь создайте ключ CA:
# openssl gendsa -des3 -out myca.key myRSA.key
Используйте этот ключ при создании сертификата:
# openssl req -new -x509 -days 365 -key myca.key -out new.crt
В каталоге должно появиться два новых файла: подпись сертификата, myca.key и сам сертификат, new.crt. Они должны быть помещены в каталог, доступный для чтения только root, желательно внутри /etc. Права на каталог можно изменить chmod с параметрами 0700.
14.9.2. Использование сертификатов, пример
Итак, что могут сделать эти файлы? Хорошим применением может стать шифрование соединений для Sendmail MTA. Это сделает ненужным использование простой текстовой аутентификации для тех, кто отправляет почту через локальный MTA.
Замечание: Это не лучшее из возможных использований, поскольку некоторые MUA выдадут ошибку, если сертификат не установлен локально. Обратитесь к поставляемой с программой документации за информацией по установке сертификата.
Следующие строки должны быть помещены в локальный файл .mc:
dnl SSL Options define(`confCACERT_PATH',`/etc/certs')dnl define(`confCACERT',`/etc/certs/new.crt')dnl define(`confSERVER_CERT',`/etc/certs/new.crt')dnl define(`confSERVER_KEY',`/etc/certs/myca.key')dnl define(`confTLS_SRV_OPTIONS', `V')dnl
Где /etc/certs/ это каталог для локального хранения сертификата и ключей. После настройки необходимо собрать локальный файл .cf. Это легко сделать, набрав make install в каталоге /etc/mail. Затем выполните команду make restart, которая должна запустить даемон Sendmail.
Если все пройдет нормально, в файле /var/log/maillog не появятся сообщения об ошибках и запустится процесс Sendmail.
Для проведения простого теста подключитесь к почтовому серверу программой telnet(1):
# telnet example.com 25 Trying 192.0.34.166... Connected to example.com. Escape character is '^]'. 220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT) ehlo example.com 250-example.com Hello example.com [192.0.34.166], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 250-DSN 250-ETRN 250-AUTH LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 example.com closing connection Connection closed by foreign host.
Если в выводе появилась строка ''STARTTLS'', все работает правильно.
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.
Руководство FreeBSD: Глава 14. Безопасность: OpenSSH
Обновлено: 13.09.2025
| Руководство FreeBSD |
| Глава 14. Безопасность |
14.11. OpenSSH
Предоставил Chern Lee.OpenSSH это набор сетевых инструментов, используемых для защищенного доступа к удаленным компьютерам. Он может быть использован в качестве непосредственной замены rlogin, rsh, rcp и telnet. Кроме того, через SSH могут быть безопасно туннелированы и/или перенаправлены произвольные TCP/IP соединения. OpenSSH шифрует весь трафик, эффективно предотвращая кражу данных, перехват соединения и другие сетевые атаки.
OpenSSH поддерживается проектом OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями и обновлениями, совместим с протоколами SSH версий 1 и 2.
14.11.1. Преимущества использования OpenSSH
Обычно при использовании telnet(1) или rlogin(1) данные пересылаются по сети в незашифрованной форме. Перехватчик пакетов в любой точке сети между клиентом и сервером может похитить информацию о пользователе/пароле или данные, передаваемые через соединение. Для предотвращения этого OpenSSH предлагает различные методы шифрования.
14.11.2. Включение sshd
В FreeBSD даемон sshd должен быть разрешен в процессе инсталляции. За запуск ответственна следующая строка в файле rc.conf:
sshd_enable="YES"
При следующей загрузке системы будет запущен sshd(8), даемон для OpenSSH. Вы можете также воспользоваться скриптом /etc/rc.d/sshd системы rc(8) для запуска OpenSSH:
/etc/rc.d/sshd start
14.11.3. SSH клиент
Утилита ssh(1) работает подобно rlogin(1).
# ssh user@example.com Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes Host 'example.com' added to the list of known hosts. user@example.com's password: *******
Вход продолжится так же, как если бы сессия была инициирована с использованием rlogin или telnet. SSH использует систему опознавательных ключей для проверки подлинности сервера при подключении клиента. Пользователю предлагается yes только при первом подключении. Дальнейшие попытки входа предваряются проверкой сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный ключ будет отличаться от только что полученного. Ключи серверов сохраняются в ~/.ssh/known_hosts, или в ~/.ssh/known_hosts2 для SSH v2.
По умолчанию современные серверы OpenSSH настроены на приём только соединений SSH v2. Клиент будет использовать версию 2 там, где это возможно, а затем версию 1. Также, клиент можно заставить использовать конкретную версию при помощи опций -1 и -2 для указания соответствующей версии протокола. Версия 1 поддерживается ради совместимости со старыми серверами.
14.11.4. Безопасное копирование
Команда scp(1) работает подобно rcp(1); она копирует файл с удаленного компьютера, но делает это безопасным способом.
# scp user@example.com:/COPYRIGHT COPYRIGHT user@example.com's password: ******* COPYRIGHT 100% |*****************************| 4735 00:00 #
Поскольку в предыдущем примере ключ сервера уже был сохранен, в этом примере он проверяется при использовании scp(1).
Параметры, передаваемые scp(1), похожи на параметры cp(1), с файлом или файлами в качестве первого аргумента и приемником копирования во втором. Поскольку файлы файлы передаются по сети через SSH, один или более аргументов принимают форму user@host:<path_to_remote_file>.
14.11.5. Настройка
Системные файлы настройки для даемона и клиента OpenSSH расположены в каталоге /etc/ssh.
Файл ssh_config используется для настройки клиента, а sshd_config для даемона.
Кроме того, параметры sshd_program (по умолчанию /usr/sbin/sshd), и sshd_flags rc.conf дают дополнительные возможности настройки.
14.11.6. ssh-keygen
Вместо использования паролей, с помощью ssh-keygen(1) можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться:
% ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/user/.ssh/id_dsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_dsa. Your public key has been saved in /home/user/.ssh/id_dsa.pub. The key fingerprint is: bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com
ssh-keygen(1) создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере.
Это позволяет соединяться с удаленным компьютером с помощью SSH-ключей вместо паролей.
Если при генерации ключей был использован пароль, каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя. Для того, чтобы избежать непрерывного набора кодовой фразы, можно использовать утилиту ssh-agent(1), как описано в разделе Разд. 14.11.7 ниже.
Внимание: Параметры и имена файлов могут различаться для разных версий OpenSSH, установленных в системе, для решения проблем обратитесь к странице справочника ssh-keygen(1).
14.11.7. Утилиты ssh-agent и ssh-add
Утилиты ssh-agent(1) и ssh-add(1) позволяют сохранять ключи SSH в памяти, чтобы не набирать кодовые фразы при каждом использовании ключа.
Утилита ssh-agent(1) обеспечивает процесс аутентификации загруженными в нее секретными ключами; для этого утилита ssh-agent(1) должна запустить внешний процесс. В самом простом случае это может быть шелл-процесс; в чуть более продвинутом -- оконный менеджер.
Для использования ssh-agent(1) совместно с шеллом, ssh-agent(1) должен быть запущен с именем этого шелла в качестве аргумента. После этого в его память при помощи утилиты ssh-add(1) могут быть добавлены необходимые ключи; при этом будут запрошены соответствующие кодовые фразы. Добавленные ключи могут затем использоваться для ssh(1) на машины, на которых установлены соответствующие публичные ключи:
% ssh-agent csh % ssh-add Enter passphrase for /home/user/.ssh/id_dsa: Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa) %
Для того чтобы использовать ssh-agent(1) в X11, вызов ssh-agent(1)должен быть помещен в файл ~/.xinitrc. Это обеспечит поддержкой ssh-agent(1) все программы, запущенные в X11. Файл ~/.xinitrc может выглядеть, например, так:
exec ssh-agent startxfce4
При этом будет запущен ssh-agent(1), который, в свою очередь, вызовет запуск XFCE, при каждом старте X11. После запуска X11, выполните команду ssh-add(1) для добавления ваших SSH-ключей.
14.11.8. Туннелирование SSH
OpenSSH поддерживает возможность создания туннеля для пропуска соединения по другому протоколу через защищенную сессию.
Следующая команда указывает ssh(1) создать туннель для telnet:
% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com %
Команда ssh используется со следующими параметрами:
-2-
Указывает ssh использовать версию 2 протокола (не используйте этот параметр, если работаете со старыми SSH серверами).
-N-
Означает использование в не-командном режиме, только для туннелирования. Если этот параметр опущен, ssh запустит обычную сессию.
-f-
Указывает ssh запускаться в фоновом режиме.
-L-
Означает локальный туннель в стиле localport:remotehost:remoteport.
user@foo.example.com-
Удаленный сервер SSH.
Туннель SSH создается путем создания прослушивающего сокета на определенном порту localhost. Затем все принятые на локальном хосту/порту соединения переправляются на через SSH на определенный удаленный хост и порт.
В этом примере, порт 5023 на localhost перенаправляется на порт 23 на localhost удаленного компьютера. Поскольку 23 это порт telnet, будет создано защищенное соединение telnet через туннель SSH.
Этот метод можно использовать для любого числа небезопасных протоколов, таких как SMTP, POP3, FTP, и так далее.
Пример 14-1. Использование SSH для создания защищенного туннеля на SMTP
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com user@mailserver.example.com's password: ***** % telnet localhost 5025 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP
Этот метод можно использовать вместе с ssh-keygen(1) и дополнительными пользовательскими учётными записями для создания более удобного автоматического SSH туннелирования. Ключи могут быть использованы вместо паролей, и туннели могут запускаться от отдельных пользователей.
14.11.8.1. Практические примеры SSH туннелирования
14.11.8.1.1. Защищенный доступ к серверу POP3
На работе находится SSH сервер, принимающий соединения снаружи. В этой же офисной сети находится почтовый сервер, поддерживающий протокол POP3. Сеть или сетевое соединение между вашим домом и офисом могут быть или не быть полностью доверяемыми. По этой причине вам потребуется проверять почту через защищенное соединение. Решение состоит в создании SSH соединения к офисному серверу SSH и туннелирование через него к почтовому серверу.
% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com user@ssh-server.example.com's password: ******
Когда туннель включен и работает, вы можете настроить почтовый клиент для отправки запросов POP3 на localhost, порт 2110. Соединение будет безопасно переправлено через туннель на mail.example.com.
14.11.8.1.2. Прохождение через Драконовский Брандмауэр
Некоторые сетевые администраторы устанавливают на брандмауэрах драконовские правила, фильтруя не только входящие соединения, но и исходящие. Вам может быть разрешен доступ к удаленным компьютерам только по портам 22 и 80, для SSH и просмотра сайтов.
Вам может потребоваться доступ к другому (возможно, не относящемуся к работе) сервису, такому как Ogg Vorbis для прослушивания музыки. Если этот сервер Ogg Vorbis выдает поток не с портов 22 или 80, вы не сможете получить к нему доступ.
Решение состоит в создании SSH соединения с компьютером вне брандмауэра и использование его для туннелирования сервера Ogg Vorbis.
% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org user@unfirewalled-system.example.org's password: *******
Клиентскую программу теперь можно настроить на localhost порт 8888, который будет перенаправлен на music.example.com порт 8000, успешно обойдя брандмауэр.
14.11.9. Параметр ограничения пользователей AllowUsers
Зачастую хорошие результаты даёт ограничение того, какие именно пользователи и откуда могут регистрироваться в системе. Задание параметра AllowUsers является хорошим способом добиться этого. К примеру, для разрешения регистрации только пользователю root с машины 192.168.1.32, в файле /etc/ssh/sshd_config нужно указать нечто вроде следующего:
AllowUsers root@192.168.1.32
Для разрешения регистрации пользователя admin из любой точки, просто укажите имя пользователя:
AllowUsers admin
Несколько пользователей должны перечислять в одной строке, как здесь:
AllowUsers root@192.168.1.32 admin
Замечание: Важно, чтобы бы перечислили всех пользователей, которые должны регистрироваться на этой машине; в противном случае они будут заблокированы.
После внесения изменений в /etc/ssh/sshd_config вы должны указать sshd(8) на повторную загрузку конфигурационных файлов, выполнив следующую команду:
# /etc/rc.d/sshd reload
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.
Экспорт настроек TheBat!
Обновлено: 07.04.2025Существует довольно простой метод переустановки почтовой программы TheBat! при переустановке операционной системы, при переносе почты на другой компьютер (при сохранении места расположения самой программы и почтовых баз).
Копирование почты с помощью sendmail
Обновлено: 13.09.2025
Нижеизложенный материал не претендует на полноту, четкость, ясность или достоверность изложения и предоставляется автором "КАК ЕСТЬ". Автор не несет никакой отвественности за любое использование данного материала. Любое использование, копирование, цитирование, полностью или частично должно включать данный текст, ссылку на данный ресурс, а так же следующию строку без изменений:
Принцип работы копирования почтовых сообщений с помощью sendmail, описанный в данной статье, состоит в описании своего майлера(mailer), называемого в дальнейшем copymail, а так же в задании набора правил, который "передает" всю проходящую почту на наш майлер. Copymail, получив почтовое сообщение, действует как обычный транспортный агент, доставляя письмо оригинальному получателю, а так же на дополнительный адрес, заданный администратором. Почтовый адрес, на который будет копироваться почта, не обязательно должен быть локальным для данной машины. Описанный майлер (copymail) представляет из себя sendmail с "оригинальным" (без изменений) конфигурационным файлом.
sendmail(1), работающий в режиме daemon (-bd) получает (A) письмо и передает (B) его sendmail(2). ( sendmail(2) — это вышеописанный майлер copymail). sendmail(2) отсылает письмо оригинальному получателю (C) и дополнительному получателю (D).
Далее описаны несколько вариантов, конфигурации sendmail, для различных требований к копированию почтовых сообщений.
При описании, автор подразумевает, что читатель обладает некоторым "специфическим" набором знаний, а именно:
- знает что такое sendmail :) .
- знает что такое m4.
- умеет из .mc файла получить .cf.
- знает где находится ${CFDIR}.
- знает куда должны помещаться конфигурационные файлы sendmail.
Вариант 1.
(C одним конфигурационным файлом sendmail)
- Следует поместить файл copymail.m4 (Вариант 1)¹ в директорию ${CFDIR}/mailer.
- В файл конфигурации sendmail (.mc) добавить² следующие строчки:
define(`COPYMAIL_MAILBOX',`user@domen') MAILER(copymail)
заменив 'user@domen' на пользователя который должен получать копии всех сообщений (он не обязательно должен быть локальным пользователем на данной машине). - Скомпилировать и установить новый конфиг.
- Перезапустить sendmail.
Вся проходящая почта будет (дополнительно) пересылаться на заданный почтовый адрес.
Недостатки:
- В логах будут сообщения вида: Oct 11 15:59:54 mx.domen.ru sendmail[9151]: g1EsNvk01649: to=user2@somewere.com.COPYMAIL ... .
- При генерации уведомлений об ошибках доставки, в сообщениях будут указываться адреса вида user@domen.COPYMAIL.
¹. В этом и последующих примерах можно помещать строки из copymail.m4 непосредственно в конфигурационный файл sendmail(.mc), не забывая о правильном порядке директив.
². MAILER следует помещать в конце конфигурационного файла, а define — до MAILER.
Вариант 2.
(C двумя конфигурационными файлами sendmail)
- Следует поместить copymail.m4 (Вариант 2) в директорию ${CFDIR}/mailer
- Скопируйте ваш конфигурационный файл sendmail (.mc) в файл под именем sendmail.copy.mc
- Добавить следующие строчки в файл sendmail.copy.mc:
define(`COPYMAIL_MAILBOX',`user@domen') define(`NOCOPY_CONFIG',`/etc/mail/sendmail.cf') MAILER(copymail)
- Скомпилировать sendmail.copy.mc и установить как sendmail.copy.cf
- Остановить sendmail и запустить, следующим образом:
/usr/sbin/sendmail -bd -C /etc/mail/sendmail.copy.cf /usr/sbin/sendmail -q30m -C /etc/mail/sendmail.cf
N.B. Такой запуск sendmail необходим для того, что бы письмо, находящееся в очереди не копировалось каждые N минут, при каждой попытке доставки. Первая копия (-bd) работает как SMTP daemon, принимая письма (и копируя их). Вторая копия (-q30) работает обработчиком (queueing) очереди, доставляя письма находящиеся в очереди (и не копируя их, так как перед тем как попасть в очередь письма уже были скопированы).
ВНИМАНИЕ! Если вы допустите ошибку при конфигурировании sendmail (например вместо конфигурационного файла "nocopy", вы укажете "copy"), sendmail уйдет в "вечный" цикл, с доставкой писем самой себе и с потреблением всех ресурсов системы.
Вариант 3.
(C возможностью избирательно копировать почту)
Желательно иметь возможность как то управлять процессом копирования почты. Например, избирательно копировать сообщения от какой либо группы пользователей или наоборот — не копировать. Для этого предназначен copymail.m4 (Вариант 3). Sendmail следует сконфигурировать как по Варианту 2, только вместо copymail.m4 (Вариант 2) возьмите copymail.m4 (Вариант 3)
Следует, так же создать файл /etc/mail/nocopy-users и поместить в него почтовые адреса (в виде user@FQDN-domen ) или IP адреса (в форме X.X.X.X). Почтовые сообщения приходящие на почтовые адреса¹, перечисленные в /etc/mail/nocopy-users или отправлямые от почтового адреса² или с IP адреса, перечисленных в /etc/mail/nocopy-users, не будут копироваться.
Для достижения обратного результата, т.е. копирования почтовых сообщений от определенных почтовых адресов или на определенные почтовые адреса, и прохождения всех остальных почтовых сообщений без копирования, следует воспользоваться copymail.m4 (Вариант 4).
Так же, следует создать файл /etc/mail/copy-users и поместить в него "копируемые" адреса (формат адресов см. выше).
| ¹. Имеется в виду rcpt to: <addr> |
| ². Имеется в виду mail from: <addr> |
Прежде чем запускать sendmail в "боевом" режиме, я советую проверить полученную конфигурацию. Для этого следует запустить sendmail в режиме тестирования адреса (ключ -bt). Рассмотрим результат преобразования адреса, который должен получиться при использовании copymail.m4 (Вариант 1):
mx# sendmail -bt -C /etc/mail/sendmail.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru canonify input: user @ domen . ru Canonify2 input: user < @ domen . ru > Canonify2 returns: user < @ domen . ru . > canonify returns: user < @ domen . ru . > parse input: user < @ domen . ru . > Parse0 input: user < @ domen . ru . > Parse0 returns: user < @ domen . ru . > ParseLocal input: user < @ domen . ru . > ParseLocal returns: $# copymail $@ domen . ru . COPYMAIL $: user @ domen . ru . COPYMAIL parse returns: $# copymail $@ domen . ru . COPYMAIL $: user @ domen . ru . COPYMAIL >
В результате должен вызваться майлер copymail и адрес должен переписаться в виде user@domen.ru.COPYMAIL. Теперь следует проверить "обратное" преобразование, т.е. письмо принятое от copymail должно разрешиться в "нормальный" адрес:
> 3,0 user@domen.ru.COPYMAIL canonify input: user @ domen . ru . COPYMAIL Canonify2 input: user < @ domen . ru . COPYMAIL > Canonify2 returns: user < @ domen . ru . COPYMAIL > canonify returns: user < @ domen . ru . COPYMAIL > parse input: user < @ domen . ru . COPYMAIL > Parse0 input: user < @ domen . ru . COPYMAIL > Parse0 returns: user < @ domen . ru . COPYMAIL > ParseLocal input: user < @ domen . ru . COPYMAIL > ParseLocal returns: user < @ domen . ru . > Parse1 input: user < @ domen . ru . > MailerToTriple input: < > user < @ domen . ru . > MailerToTriple returns: user < @ domen . ru . > Parse1 returns: $# esmtp $@ domen . ru . $: user < @ domen . ru . > parse returns: $# esmtp $@ domen . ru . $: user < @ domen . ru . > >
В результате адрес должен разрешиться в один из майлеров, кроме copymail. К примеру адрес может разрешиться в локальный майлер ($# local $: user) или в майлер esmtp ($# esmtp $@ domen . ru . $: user < @ domen . ru . >).
Теперь рассмотрим результат преобразования адреса при использовании copymail.m4 (Вариант 2 (3,4)):
mx# sendmail -bt -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru canonify input: user @ domen . ru Canonify2 input: user < @ domen . ru > Canonify2 returns: user < @ domen . ru . > canonify returns: user < @ domen . ru . > parse input: user < @ domen . ru . > Parse0 input: user < @ domen . ru . > Parse0 returns: user < @ domen . ru . > ParseLocal input: user < @ domen . ru . > ParseLocal returns: $# copymail $@ localhost $: user < @ domen . ru . > parse returns: $# copymail $@ localhost $: user < @ domen . ru . > >
В результате должен вызваться майлер copymail: $# copymail $@ localhost $: user < @ domen . ru . >.
Если в результате тестирования адресов у вас не получается то, что вы ожидаете, например используется copymail.m4 (Вариант 3), пользователь user@domen.ru включен в /etc/mail/nocopy-users, а в результате почта для этого пользователя все равно копируется, то попробуйте воспользоваться следующими рекомендациями:
- Не забывайте перезапускать sendmail после установки нового конфигурационного файла.
- Не забывайте перезапускать sendmail после изменения списка адресов в файлах /etc/mail/nocopy-users или /etc/mail/copy-users.
- Не забывайте что правая и левая части в правилах подстановки (R) отделяются табуляцией.
- Проверьте что вы правильно указали sendmail файл /etc/mail/nocopy-users и sendmail загрузил список в класс NOCOPY. (Конструкция $={NOCOPY} позволяет просмотреть содержимое класса).
mx# sendmail -bt -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > $={NOCOPY} > user@domen.ru > - Поробуйте воспользоваться отладочным режимом (-d) sendmail, что бы получить больше информации о процессе преобразования адресов:
mx# sendmail -bt -d21.12 -C /etc/mail/sendmail.copy.cf ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 user@domen.ru ... -----callsubr ParseLocal (98) ParseLocal input: user < @ domen . ru . > -----trying rule: $* < @ $+ . > $* -----rule matches: $: $1 < @ $2 . > $3 $| $1 @ $2 rewritten as: user < @ domen . ru . > $| user @ domen . ru -----trying rule: $* < @ $+ . > $* $| $={NOCOPY} -----rule matches: $@ $1 < @ $2 . > $3 rewritten as: user < @ domen . ru . > ParseLocal returns: user < @ domen . ru . > rewritten as: user < @ domen . ru . > ... parse returns: $# local $: user >
Privacy violation.
(Морально-этические стороны вопроса)
Копирование почты является нарушением морально-этических (а возможно даже и юридических) прав, если только пользователь не был предупрежден об этом до начала процесса копирования почты (а ещё лучше до того как получил почтовый ящик)... Предлагаемый ниже вариант copymail.m4 позволяет вставить в каждое копируемое письмо некоторый заголовок (например назовем его X-Privacy-violation), в котором будет честно сказано что данное письмо было скопировано, а так же будет указано кому и зачем оно было скопировано. По такому же принципу можно изменить/дополнить один из стандарных заголовков, например To: или Subject:.
... Received: (from user@localhost) by mx.domen.ru ESMTP id g1KEPD001282 for user2@domen.ru; Wed, 20 Feb 2002 17:25:13 +0300 (MSK) (envelope-from user) Date: Wed, 20 Feb 2002 17:25:13 +0300 (MSK) From: User
Другие варианты copymail.m4 следует дополнить по аналогии с приведенным примером.
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
D{COPYMAIL}COPYMAIL
C{CP}${COPYMAIL}
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . $~{CP} . > $#copymail $@ $2 . $3 . ${COPYMAIL} $: $1 @ $2 . $3 . ${COPYMAIL}
# if mail has been processed by copymail mailer, process it usual way...
R$* < @ $* . ${COPYMAIL} > $1 < @ $2 . >
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never COPYMAIL_MAILBOX.${COPYMAIL} $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . > $* $#copymail $@ localhost $: $1 < @ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_USERS',,
`define(`NOCOPY_USERS', `-o /etc/mail/nocopy-users')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
F{NOCOPY}NOCOPY_USERS
LOCAL_RULE_0
# Send all mail (except $={NOCOPY}) to copymail mailer
R$* < @ $+ . > $* $: $1 < @ $2 . > $3 $| $1 @ $2
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&{client_addr}
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&f
R$* < @ $+ . > $* $| <$*> $: $1 <@ $2 . > $3 $| $4
R$* < @ $+ . > $* $| $={NOCOPY} $@ $1 <@ $2 . > $3
R$* < @ $+ . > $* $| $* $#copymail $@ localhost $: $1 < @ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`COPY_USERS',,
`define(`COPY_USERS', `-o /etc/mail/copy-users')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
F{COPY}COPY_USERS
LOCAL_RULE_0
# Send mail $={COPY} to copymail mailer
R$* < @ $+ . > $* $: $1 < @ $2 . > $3 $| $1 @ $2
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&{client_addr}
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3 $| $&f
R$* < @ $+ . > $* $| <$*> $: $1 <@ $2 . > $3 $| $4
R$* < @ $+ . > $* $| $={COPY} $#copymail $@ localhost $: $1 < @ $2 . > $3
R$* < @ $+ . > $* $| $* $: $1 <@ $2 . > $3
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
PUSHDIVERT(-1)
ifdef(`COPYMAIL_MAILBOX',,
`define(`COPYMAIL_MAILBOX', `postmaster')')dnl
ifdef(`NOCOPY_CONFIG',,
`errprint(`*** You must define NOCOPY_CONFIG for copymail mailer!!! ***')')dnl
POPDIVERT
#########################################
### COPYMAIL Mailer specification ###
#########################################
VERSIONID(`$Id: cpsendmail.html,v 1.2 2002/06/14 18:39:10 freeman Exp $')dnl
LOCAL_CONFIG
H?{COPIED}?X-Privacy-violation: The copy of this message was sent to <COPYMAIL_MAILBOX> due to business requirements
Kiscopied macro
LOCAL_RULE_0
# Send all mail to copymail mailer
R$* < @ $+ . > $* $#copymail $@ localhost $: $1 < @ $2 . > $3 $(iscopied {COPIED} $@ YES $)
# Send message to original recipient + additional mailbox: COPYMAIL_MAILBOX
Mcopymail, P=/usr/sbin/sendmail, F=fmSDFMu, S=0, R=0,
A=sendmail -N never -C NOCOPY_CONFIG COPYMAIL_MAILBOX $u
Расположение ${CFDIR} в некоторых OS:
| Solaris | /usr/lib/mail |
| Linux | /usr/lib/sendmail-cf |
| FreeBSD | /usr/share/sendmail/cf |
Список литературы:
Принимаю заказы на настройку серверов, mikrotik и других роутеров, точек доступа, nginx и т.п. В пределах Санкт-Петербурга возможен выезд к заказчику. См. контакты.
Squid
3proxy
VPN
Шифрование
Почтовый сервер
Mikrotik
Настройка сервера
Защита почты
Резервное копирование
Групповые политики
java
WDS
IPFW
SELinux
kvm
OpenVPN
Виртуальные машины
libvirt
Mobile
systemd
Samba
WiFi
firewalld
Lightsquid
Remote desktop
NAT
Iptables
Нейронные сети
python
Docker
Софт
Удаление данных
Безопасность
Winbox
User agent
Privacy
Онлайн сервисы
Передача данных
Хостинг
Dovecot
Postfix
VPN сервер
RRDTool
sendmail
Rsync
Linux
Настройка прокси
Система
Windows
Синхронизация
Облако
fail2ban
SSH
LetsEncrypt
FreeBSD
Последние комментарии
Популярно:
Разделы статей:
только с письменного разрешения владельца сайта bozza.ru
Подскажите. подключение с ПК все работает все ок. Делал по вашей мурзилке.
Но при подключе...