Вам знакомо выражение: «Не чини, коли не поломано»? Если да, то вы знаете, что иногда лучше не вмешиваться в сложившуюся ситуацию. Но ни один настоящий сисадмин не в состоянии спокойно смотреть на новые «примочки» и удержаться от того, чтобы не «потыкать» их и попробовать применить на практике. Именно так мы вышли на тот уровень, где сейчас находимся, и теперь планируем перебраться на еще более высокий уровень. Однако тыкать острой палкой в незнакомый предмет — не всегда безопасное занятие.
Мы составили список из 21 распространенной ошибки, которая не раз даст о себе знать. Наш совет: пробуя что-то новое, не забывайте думать о последствиях! Они могут быть самыми разными.
1. Анонимный доступ и FTP
Каждый, кто хоть раз создавал веб-сайт с использованием FTP, разрешал анонимный доступ и выкладывал свой сайт в Интернет, получил несколько уроков. Если вы разрешаете анонимный доступ, будьте готовы к тому, что очень скоро ваш сайт превратится в хостинг для пиратских программ и фильмов. Никогда не разрешайте анонимный доступ, даже во внутренней сети. В противном случае, у вас быстро закончится пространство на диске и трафик.
2. «Всем — полный контроль»
Вплоть до последних версий Windows, каждый раз как вы создавали общую папку, по умолчанию в ее настройках была активирована опция «Всем — полный контроль». Многие из этих устаревших систем используются и по сей день. Хуже того, многие сисадмины до сих пор оставляют эту опцию включенной по умолчанию в современных операционных системах, полагая, что дать всем возможность полностью контролировать каталог — это правильно! Рекомендуем вам перестать раздавать подобные привилегии направо и налево!
3. «Ответить всем»
Да, иногда действительно бывает необходимо отправить письмо сразу всем пользователям из корпоративной группы. Но оставить эту кнопку, чтобы любой пользователь мог воспользоваться ею,- самый простой способ загрузить по максимуму вашу электронную почту и испытать ее на прочность. Кто-нибудь непременно случайно нажмет ее, и через минуту 30 человек будут одновременно отписываться от коллективного диалога, или просить всех перестать отвечать всем, или же, наоборот, вставлять свои пять копеек в беседу. Мне приходилось видеть, как серверы специально отключали, чтобы только прекратить это безумие. Ограничьте возможности использования функции «Ответить всем» и сделайте так, чтобы только авторизованные пользователи могли отправлять письма самым большим группам пользователей в вашей электронной почте.
4. Опция «Завершение работы» в удаленном доступе
Однажды мне пришлось совершить внеплановую поездку в другой город из-за того, что во время удаленного управления сервером я случайно нажал кнопку «Завершение работы» вместо кнопки «Выход из системы». Сейчас опция «Завершение работы» убирается из меню по умолчанию, но в миллионах серверов 2003 и 2008 годов выпуска она все еще есть. Уберите кнопку «Завершение работы» из меню удаленного доступа. Если вы действительно захотите выключить сервер, лучше воспользоваться командной строкой. Ну а если внеплановые визиты в центр обработки данных вам по душе, так уж и быть, можете ее оставить.
5. Хранение незашифрованных паролей на веб-страницах
Веб-мастера слишком часто хранят параметры соединения для базы данных в коде сценариев веб-сайтов в незашифрованном виде. При этом кто угодно может пробраться в систему, чтобы «ознакомиться с источником данных». Никогда не сохраняйте пароли в файлах, доступ к которым есть у конечных пользователей. Если же вам все-таки нужно где-то хранить эту информацию, пользуйтесь шифрованием.
6. Игнорирование проверок входных данных
Переполнение буфера, инъекция SQL, изменение цен в корзине онлайн-магазина — все это возможно, если не предусмотреть проверку входных данных в вашем программном обеспечении и на вашем веб-сайте. Всегда повторно проверяйте то, какие данные вам приходят от пользователей и отклоняйте все, что не проходит проверку, до того, как изменения (и их последствия) станут необратимыми.
7. Использование незашифрованных протоколов
Помимо запросов на DNS-серверы, скачивания общедоступных файлов и создания веб-страниц для широкого круга посетителей, нет никакого практического смысла в использовании незашифрованных протоколов. Но если вы выполняете какую-либо аутентификацию или предоставляете доступ к конфиденциальным данным, использовать криптографическую защиту просто обязательно. При этом дополнительно изучите, какие из протоколов на данный момент считаются наиболее защищенными и почему.
8. Отсутствие переадресации с незашифрованного протокола на зашифрованный
Справедливости ради, уточним: мы не предлагаем вам отключить незашифрованные протоколы как таковые. Слишком многие пользователи будут печатать адрес без протокола, и без переадресации с HTTP на HTTPS они не смогут попасть на ваш веб-сайт. Используйте HTTP и настройте переадресацию с него. При этом данные пользователей будут защищены, и у них не возникнет проблем с посещением вашего веб-сайта.
9. Проверка SSL-сертификатов
Каждый раз, как вы учите пользователя просто «прощелкивать» предупреждения, не читая их, вы делаете его потенциальной жертвой киберпреступников в будущем. Чаще всего подобное происходит на внутренних веб-сайтах, которые используют протокол HTTPS с SSL-сертификатом. Пользователи, не задумываясь, кликают там, где не следует. Конечные пользователи не могут отличить внутренний сайт от внешнего. Они просто увидят знакомый формат предупреждения и кликнут «ОК» — как вы им и говорили, когда учили пользоваться внутренним приложением. Создайте корпоративный CA или приобретите сертификат wildcard, но не учите пользователей бездумно кликать «ОК» на предупреждениях.
10. Оставленные на боевой системе промежуточные сборки приложений и кода
Промежуточные сборки приложений созданы для демонстрации того, как они работают на данный момент. Они часто не соответствуют должному уровню безопасности и надежности и, как правило, не обновляются при установке патчей на приложение. При создании или запуске сервера удалите все предыдущие образцы кода и приложений, чтобы в будущем их не могли использовать против вас.
11. Установка обновлений и патчей без тестирования
Если вы используете исключительно «ванильный код» от разработчика, установка обновлений и патчей без тестирования может обернуться проблемой. Разработчик не имеет возможности тестировать каждую отдельно взятую конфигурацию. Это означает, что и вашу конфигурацию он не тестировал. Это ваша задача, а не его. Вы хотите установить обновление? Устанавливайте, но только сначала убедитесь, что это не создаст других проблем в вашей системе.
Обычно, при обновлении большого парка компьютеров, перед распределением обновления по всем системам выбирается контрольная группа из нескольких машин, на которых проверяется работоспособность устанавливаемых патчей. В случае, если на них обновление пройдет без проблем — можно распространять его на всю сеть.
12. Автоматические IP (169.254.y.z) в DNS
Если у сервера есть два IP-адреса в DNS, он будет отвечать на запросы с обоих из них. Если один из этих адресов — фальшивка, то с вероятностью 50 на 50 клиент попадет на него, а не на настоящий адрес. Это сделает работу медленной, и, соответственно, клиент будет звонить в вашу техническую поддержку. Как минимум, снимите галочку с опции «регистрация соединения в DNS», чтобы фальшивые адреса не присваивались настоящим именам хоста.
13. Ссылки на DNS в ActiveDirectory
В AD контроллерам домена никогда не следует давать на себя ссылку в DNS; необходимо указывать ссылку на другой контроллер домена. Если контроллер домена делает ссылку на себя, он может потерять синхронизацию с другими, и вы даже не заметите этого. Он быстро устареет и не сможет проводить идентификацию пользователей.
Если он слишком долго будет не синхронизирован (60 дней по умолчанию), вам придется снести его и установить заново для устранения проблемы. Всегда проверяйте, что контроллер домена привязан к другому контроллеру домена в DNS, а не к самому себе. В противном случае вам придется использовать NTDSUTIL для очистки AD от вредоносных данных.
14. Недостаточный аудит
Регистрация системных событий — очень важный процесс, но его редко выполняют правильно. Стандартных настроек аудита, как правило, недостаточно для полноценного восстановления хода событий и выяснения причины возникновения проблемы. Кроме того, журналы событий занимают много пространства на диске, и могут пройти дни или даже недели, прежде чем кто-либо вообще поймет, что что-то случилось и надо проверить журналы регистрации. Убедитесь, что вы регистрируете достаточно информации для восстановления хода событий, и что регистрационные записи хранятся достаточно долго, чтобы вы могли с их помощью провести полноценное расследование любого сбоя.
15. Отсутствие централизованного журнала регистрации
По умолчанию, система использует для ведения журналов регистрации локальные диски. Это нормально — до тех пор, пока система не рухнет или не будет взломана хакером, который сотрет журналы регистрации. Ведение централизованного журнала регистрации требует больше времени, денег и пространства. Но при этом у вас точно будет журнал событий в случае краха системы, а злоумышленнику будет сложнее замаскировать следы своей деятельности.
GFI рекомендует использовать GFI EventsManager — решение для централизованного сбора и анализа журналов событий в сети. Продукт можно загрузить и использовать до 30 дней бесплатно с полным функционалом — этого достаточно, чтобы проанализировать гигабайты журналов данных и выявить проблемы в сети.
16. Разрешение на чтение
Многие дистрибутивы Linux позволяют пользователям получать доступ к домашним каталогам откуда угодно. Как правило, это не подразумевает «весь Интернет», но означает, что любой пользователь в сети может читать файлы из домашнего каталога, а в нем могут быть и файлы с паролями, и конфигурационные файлы, и масса другой ценной информации. Убедитесь в том, что для уровня доступа для каждого домашнего каталога пользователя установлено значение 600, так что пользователи могут читать и писать файлы только в домашних каталогах, но не могут выполнять программы из них. Если нужно разрешить выполнение программ, установите значение 700.
17. Использование изначальной установки строк сообщества на значения «public» и «private» в протоколе SNMP
В протоколе SNMP v1 и v2 безопасность обеспечивается только строкой сообщества, а по умолчанию в строке сообщества для записи указано значение «private». При этом злоумышленнику, получившему доступ к сети, ничего не стоит обрушить роутер или поменять местами порты. Передача данных в протоколе SNMP v1 и v2 осуществляется в незашифрованном виде, но если изменить значение по умолчанию в строке сообщества, то это хоть немного усложнит для хакера задачу создания проблем в вашей сети. Если возможно, используйте протокол SNMP v3 или же не используйте SNMP для записи вообще.
18. Игнорирование протокола ICMP
Документы RFC предусматривают, что хосты ОБЯЗАНЫ отвечать на запросы ICMP Echo, так что сисадмины, игнорирующие протокол ICMP, нарушают их требования, что не есть хорошо. Кроме того, поскольку сетевые атаки типа Ping of death не актуальны уже 15 лет, игнорирование протокола ICMP приведет только к тому, что пользователям будет сложнее исправить ситуацию при неудачной попытке доступа на ваш сайт, и они будут перегружать вашу службу поддержки звонками и сообщениями о невозможности воспользоваться VPN. По меньшей мере, разрешите пинговать ваш сайт и конечные точки VPN (в большинстве случаев проверка сводится именно к этому).
19. Удаление (вместо блокирования) чего-либо во внутренней сети
Если вы блокируете нежелательный трафик во внутренней сети, то хорошие сисадмины увидят RST ACK или ICMP Unreachable и будут знать, что брандмауэр блокирует нечто целенаправленно. Если же вы просто молча удалите что-то во внутренней сети, ваши коллеги могут потратить дни на попытки понять, почему что-то не работает, как раньше, начнут обвинять брандмауэр во всех возможных бедах и, в лучшем случае, будут звонить вам при любой поломке. (В худшем случае, они будут по умолчанию считать, что виноваты вы).
20. Включение опции автоматического обновления системы
Как и в случае с установкой обновлений без тестирования, разрешить автоматическое обновление системы — значит, позволить ей устанавливать на себя патчи без предварительной проверки и возможности проконтролировать процесс. Нет, серьезно, если вы позволяете серверам обновляться автоматически, то зачем вы им вообще нужны? Вы должны контролировать процесс управления обновлениями. Во-первых, вы сможете осуществлять тестирование, а во-вторых, вы сможете перезагружать серверы только в плановом порядке, когда вам это нужно.
Для управления обновлениями, а также проверки сети на наличие уязвимостей, GFI советует воспользоваться продуктом GFI LanGuard. Продукт можно использовать 30 дней бесплатно без ограничений по функциональности — проверьте свою сеть на «дыры» в безопасности и получите централизованный контроль над обновлениями и патчами.
21. Использование локальных аппаратных часов для синхронизации времени
Синхронизация времени очень важна. Журналы регистрации зависят от нее. Аутентификация зависит от нее. Ваши пользователи зависят от нее — а как иначе они узнают, что пора идти домой? Все сети должны использовать протокол NTP для синхронизации часов, а также использовать надежный внешний источник наподобие pool.ntp.org, чтобы убедиться, что часы не просто синхронизированы, но и показывают точное время.
Позаботьтесь об этих важных моментах, и ваша сеть будет в прекрасном состоянии и выдержит любые нагрузки.
