ПОЖАЛУЙСТА, ОБРАТИТЕ ВНИМАНИЕ: Я не заинтересован в том, чтобы превращать это в пламенную войну! Я понимаю, что многие люди имеют твердые убеждения по этому поводу, в немалой степени потому, что они приложили много усилий для создания своих решений по брандмауэрам, а также потому, что их внушили верить в их необходимость.
Однако я ищу ответы от людей, которые эксперты в безопасности. Я считаю, что это важный вопрос, и ответ на него принесет пользу не только мне и компании, в которой я работаю. Я уже несколько лет эксплуатирую нашу серверную сеть без каких-либо компромиссов, без какого-либо брандмауэра. Ни один из компромиссов безопасности, которые мы иметь это можно было предотвратить с помощью брандмауэра.
Думаю, я работаю здесь слишком долго, потому что, когда я говорю «серверы», я всегда имею в виду «услуги, предлагаемые населению», а не «секретные внутренние базы данных биллинга». Таким образом, любые правила, которые мы бы есть в каких-либо межсетевых экранах, чтобы разрешить доступ ко всему Интернету. Кроме того, все наши серверы общего доступа находятся в выделенном центре обработки данных отдельно от нашего офиса.
Кто-то еще задал аналогичный вопрос, и мой ответ получил отрицательное число. Это заставляет меня думать, что либо люди, проголосовавшие против него, не совсем поняли мой ответ, либо я недостаточно понимаю безопасность, чтобы делать то, что я делаю сейчас.
Это мой подход к безопасности сервера:
Следуйте моей операционной системе правила безопасности перед подключение моего сервера к Интернету.
Используйте оболочки TCP для ограничения доступа к SSH (и другим службам управления) небольшим количеством IP-адресов.
Следите за состоянием этого сервера с помощью Мунин. И исправьте вопиющие проблемы безопасности, присущие Munin-node в его конфигурации по умолчанию.
Nmap мой новый сервер (также перед подключением моего сервера к Интернету). Если бы я установил брандмауэр на этот сервер, это был бы точный набор портов, на которые должны быть ограничены входящие соединения.
Установите сервер в серверной и дайте ему публичный IP-адрес.
Обеспечьте безопасность системы с помощью функции обновлений безопасности моей операционной системы.
Моя философия (и основа вопроса) заключается в том, что сильная безопасность на основе хоста устраняет необходимость в брандмауэре. Общая философия безопасности гласит, что строгая безопасность на основе хоста по-прежнему требуется, даже если у вас есть брандмауэр (см. правила безопасности). Причина этого в том, что брандмауэр, который перенаправляет общедоступные службы на сервер, позволяет злоумышленнику в такой же степени, как и отсутствие брандмауэра. Уязвима сама служба, и поскольку предложение этой услуги всему Интернету является обязательным требованием ее работы, ограничение доступа к ней не имеет значения.
Если здесь являются доступные на сервере порты, к которым не требуется доступ для всего Интернета, то это программное обеспечение необходимо было закрыть на шаге 1 и было проверено на шаге 4. Если злоумышленник успешно проникнет на сервер через уязвимое программное обеспечение и откроет порт сами по себе, злоумышленник может (и делает) так же легко победить любой брандмауэр, установив вместо этого исходящее соединение на случайный порт. Дело безопасности не в том, чтобы защитить себя после успешной атаки - это уже доказано, - а в том, чтобы не допустить злоумышленников в первую очередь.
Было высказано предположение, что есть и другие соображения безопасности, помимо открытых портов, но для меня это звучит как защита своей веры. Любые уязвимости операционной системы / стека TCP должны быть одинаково уязвимы независимо от того, существует ли брандмауэр или нет - в зависимости от того, что порты перенаправляются непосредственно в эту операционную систему / стек TCP. Точно так же запуск вашего брандмауэра на самом сервере, а не на маршрутизаторе (или, что еще хуже, в обоих местах), кажется, добавляет ненужные уровни сложности. Я понимаю философию «безопасность приходит послойно», но наступает момент, когда это все равно, что строить крышу, складывая X слоев фанеры друг на друга, а затем просверливая отверстие во всех них. Еще один слой фанеры не остановит утечку через отверстие, которое вы делаете специально.
Честно говоря, я вижу, что брандмауэр можно использовать только для серверов, если он имеет динамические правила, предотвращающие все подключения ко всем серверам от известных злоумышленников - например, RBL для спама (что, по совпадению, в значительной степени то, что делает наш почтовый сервер) . К сожалению, я не могу найти брандмауэры, которые это делают. Следующим лучшим вариантом является сервер IDS, но это предполагает, что злоумышленник не атакует сначала ваши реальные серверы, и что злоумышленники потрудятся исследовать всю вашу сеть. перед нападающий. Кроме того, известно, что они вызывают большое количество ложных срабатываний.
Преимущества межсетевого экрана:
Прежде всего, если у вас нет брандмауэра и система скомпрометирована, как вы его обнаружите? Нельзя доверять попытке запустить какую-то команду ps, netstat и т. Д. В локальной системе, поскольку эти двоичные файлы можно заменить. «nmap» из удаленной системы не является гарантированной защитой, так как злоумышленник может гарантировать, что root-kit принимает соединения только с выбранного исходного IP-адреса (а) в определенное время.
Аппаратные брандмауэры помогают в таких сценариях, поскольку чрезвычайно сложно изменить ОС / файлы брандмауэра по сравнению с ОС / файлами хоста.
Недостатки межсетевого экрана:
TCP Wrappers можно было бы назвать реализацией межсетевого экрана на основе хоста; вы фильтруете сетевой трафик.
Для точки, когда злоумышленник устанавливает исходящие соединения через произвольный порт, брандмауэр также предоставляет средства контроля исходящего трафика; Правильно настроенный брандмауэр управляет входом и выходом в соответствии с рисками, связанными с системой.
Что касается того, как брандмауэр не устраняет любую TCP-уязвимость, вы не знакомы с тем, как брандмауэры работают. У Cisco есть целый набор правил, доступных для загрузки, которые определяют пакеты, построенные таким образом, что могут вызвать определенные проблемы операционной системы. Если вы возьмете Snort и начнете запускать его с правильным набором правил, вы также получите предупреждение об этом. И, конечно же, Linux iptables может отфильтровывать вредоносные пакеты.
По сути, межсетевой экран - это проактивная защита. Чем дальше вы уходите от упреждающего действия, тем больше вероятность того, что вы окажетесь в ситуации, когда вы реагируете на проблему, а не предотвращаете ее. Сосредоточение вашей защиты на границе, как и в случае с выделенным межсетевым экраном, упрощает управление, потому что у вас есть центральный узел, а не дублирование правил повсюду.
Но ни одна вещь не обязательно является окончательным решением. Хорошее решение безопасности, как правило, является многоуровневым, когда у вас есть брандмауэр на границе, TCP-оболочки на устройстве и, возможно, некоторые правила для внутренних маршрутизаторов. Обычно вам следует защищать сеть от Интернета и защищать узлы друг от друга. Этот многослойный подход не похож на просверливание отверстия в нескольких листах фанеры, это больше похоже на установку пары дверей, чтобы злоумышленник мог сломать два замка вместо одного; Это называется ловушкой для людей с точки зрения физической безопасности, и почти в каждом здании есть такая ловушка. :)
(Вы можете прочитать "Жизнь без межсетевых экранов")
Теперь: как насчет устаревшей системы, для которой больше не публикуются исправления? Как насчет невозможности применить исправления к N-машинам в то время, когда вам нужно это сделать, и в то же время вы можете применить их на меньшем количестве узлов в сети (межсетевые экраны)?
Нет смысла обсуждать существование или необходимость межсетевого экрана. Что действительно важно, так это то, что вы должны реализовать политику безопасности. Для этого вы будете использовать любые инструменты, которые будут его реализовывать и помогать управлять, расширять и развивать. Если для этого нужны брандмауэры, ничего страшного. Если они не нужны, тоже хорошо. Что действительно важно, так это наличие работающей и поддающейся проверке реализации вашей политики безопасности.
Большинство ваших объяснений, кажется, опровергают необходимость в брандмауэре, но я не вижу недостатков в его наличии, кроме небольшого количества времени на его установку.
Мало что является «необходимостью» в строгом смысле этого слова. Безопасность - это больше о настройке всех возможных блокад. Чем больше работы потребуется для взлома вашего сервера, тем меньше шансов на успешную атаку. Вы хотите сделать так, чтобы взломать ваши машины было больше, чем где-либо еще. Добавление брандмауэра усложняет работу.
Я думаю, что ключевое применение - избыточность в безопасности. Еще один плюс брандмауэров в том, что вы можете просто отбрасывать попытки подключения к любому порту, а не отвечать на отклоненные запросы - это сделает nmapping немного более неудобным для злоумышленника.
В практическом плане вашего вопроса для меня важнее всего то, что вы можете заблокировать SSH, ICMP и другие внутренние службы до локальных подсетей, а также ограничить скорость входящих соединений, чтобы облегчить атаки DOS.
«Задача безопасности не в том, чтобы защитить себя после успешной атаки - это уже доказано, что это невозможно, - в первую очередь, чтобы не допустить атакующих».
Я не согласен. Не менее важно ограничение ущерба. (в соответствии с этим идеалом, зачем использовать хэш-пароли? или прикрепить программное обеспечение базы данных на другом сервере, чем ваши веб-приложения?) Я думаю, что здесь применима старая поговорка: «Не кладите все яйца в одну корзину».
Should I firewall my server? Хороший вопрос. Казалось бы, нет смысла устанавливать брандмауэр поверх сетевого стека, который уже отклоняет попытки подключения ко всем, кроме горстки легально открытых портов. Если в ОС есть уязвимость, которая позволяет злонамеренно созданным пакетам нарушать работу / использовать хост, будет ли межсетевой экран работает на том же хосте предотвратить эксплойт? Хорошо, может быть ...
И это, вероятно, самая веская причина запускать брандмауэр на каждом хосте: брандмауэр. мощь предотвратить использование уязвимости сетевого стека. Это достаточно веская причина? Не знаю, но полагаю, можно сказать: «Никого не уволили за установку брандмауэра».
Еще одна причина для запуска брандмауэра на сервере - разделить эти две сильно коррелированные проблемы:
Без брандмауэра набор запущенных служб (вместе с конфигурациями для tcpwrappers и т. Д.) Полностью определяет набор портов, которые сервер будет открывать, и от которых будут приниматься соединения. Брандмауэр на основе хоста дает администратору дополнительную гибкость для контролируемой установки и тестирования новых служб, прежде чем сделать их более доступными. Если такая гибкость не требуется, то меньше причин для установки брандмауэра на сервере.
В заключение, есть один элемент, не упомянутый в вашем контрольном списке безопасности, который я всегда добавляю, и это система обнаружения вторжений на основе хоста (HIDS), такая как Помощник или Самайн. Хорошая HIDS чрезвычайно затрудняет злоумышленнику возможность внести нежелательные изменения в систему и остаться незамеченным. Я считаю, что на всех серверах должны работать какие-то HIDS.
Брандмауэр - это инструмент. Сам по себе он не делает вещи безопасными, но может внести свой вклад в качестве уровня в защищенную сеть. Это не значит, что он вам нужен, и меня, конечно, беспокоят люди, которые слепо говорят: «Мне нужен брандмауэр», не понимая, почему они так думают, и которые не понимают сильных и слабых сторон брандмауэров.
Есть много инструментов, которые мы можем сказать, что нам не нужны ... Можно ли запустить компьютер с Windows без антивируса? Да, это так ... но иметь такую страховку - это хороший уровень страховки.
Я бы сказал то же самое о брандмауэрах - что бы вы ни говорили о них, это хороший уровень страховки. Они не заменяют установку исправлений, блокировку машин, отключение неиспользуемых сервисов, ведение журнала и т. Д., Но они могут быть полезным дополнением.
Я также предлагаю, чтобы уравнение несколько изменилось в зависимости от того, говорите ли вы о размещении брандмауэра перед группой тщательно обслуживаемых серверов, как вы, кажется, или типичной локальной сети с сочетанием рабочих станций и серверов. , некоторые из которых могут запускать довольно непростые вещи, несмотря на все усилия и пожелания ИТ-команды.
Еще одна вещь, которую следует учитывать, - это преимущество создания явно устойчивой цели. Видимая безопасность, будь то яркий свет, тяжелые замки и явная сигнализация на здании; или очевидный брандмауэр на диапазоне IP-адресов компании может отпугнуть случайного злоумышленника - они пойдут искать более легкую добычу. Это не остановит решительного злоумышленника, который знает, что у вас есть информация, которую он хочет, и полон решимости получить ее, но сдерживание случайных злоумышленников по-прежнему имеет смысл - особенно если вы знаете, что к любому злоумышленнику, чьи зондирования не проходят мимо средства устрашения, следует относиться особенно серьезно. .
Всем отличные вопросы. НО - Я очень удивлен, что ПРОИЗВОДИТЕЛЬНОСТЬ не была доведена до сведения.
Для веб-интерфейсов, которые сильно (с точки зрения ЦП) используются, локальный брандмауэр действительно снижает производительность, точка. Попробуйте нагрузочный тест и посмотрите. Я видел это много раз. Отключение брандмауэра увеличивает производительность (количество запросов в секунду) на 70% и более.
Этот компромисс необходимо учитывать.
Брандмауэр - дополнительная защита. Три конкретных сценария, от которых он защищает: атаки на сетевой стек (то есть ваша серверная ОС имеет уязвимость для специально созданных пакетов, которые никогда не достигают уровня портов), успешное вторжение, устанавливающее соединение с «телефоном домой» (или отправка спама, или что-то еще ), или успешное вторжение, открывающее порт сервера, или, что менее обнаружимо, проследите за последовательностью стука порта перед открытием порта. Конечно, последние два связаны с уменьшением ущерба от вторжения, а не с его предотвращением, но это не значит, что это бесполезно. Помните, что безопасность - это не предложение по принципу «все или ничего»; one использует многоуровневый подход с использованием ремня и подтяжек для достижения уровня безопасности, достаточного для ваших нужд.
Брандмауэр определенно не нужен для небольших установок. Если у вас один или два сервера, программные брандмауэры можно обслуживать. При этом мы не работаем без специальных брандмауэров, и есть несколько причин, по которым я придерживаюсь этой философии:
Разделение ролей
Серверы для приложений. Межсетевые экраны предназначены для проверки пакетов, фильтрации и политик. Веб-сервер должен позаботиться об обслуживании веб-страниц, и все. Поместить обе роли в одно устройство - это все равно, что попросить бухгалтера быть вашим охранником.
Программное обеспечение - это движущаяся цель
Программное обеспечение на хосте постоянно меняется. Приложения могут создавать собственные исключения брандмауэра. ОС обновлена и исправлена. Серверы - это «административная» область с высоким трафиком, и ваши политики брандмауэра / политики безопасности часто намного важнее для безопасности, чем конфигурации вашего приложения. Предположим, что в среде Windows кто-то совершает ошибку на каком-то уровне групповой политики и выключает брандмауэр Windows на настольных компьютерах и не понимает, что это будет применено к серверам. Вы широко открыты в несколько кликов.
Говоря об обновлениях, обновления прошивки брандмауэра обычно выходят один или два раза в год, в то время как обновления ОС и сервисов - это постоянный поток.
Многоразовые услуги / политики / правила, управляемость
Если я настрою службу / политику под названием «Веб-сервер» один раз (скажем, TCP 80 и TCP 443) и применю ее к «группе веб-серверов» на уровне брандмауэра, это будет намного эффективнее (пара изменений конфигурации) и экспоненциально менее подвержен человеческим ошибкам, чем настройка служб межсетевого экрана на 10 устройствах и открытие 2 портов в 10 раз. Когда эту политику нужно изменить, это 1 изменение против 10.
Я все еще могу управлять брандмауэром во время атаки или после компрометации
Скажем, мой брандмауэр + сервер приложений на базе хоста подвергается атаке, а ЦП не работает. Чтобы даже начать понимать, что происходит, я полагаю, что моя нагрузка меньше, чем у злоумышленника, чтобы даже войти и посмотреть на это.
Фактический опыт - однажды я испортил правило брандмауэра (оставил порты на ЛЮБОЙ, а не на конкретный, и на сервере была уязвимая служба), и у злоумышленника действительно был активный сеанс удаленного рабочего стола с ящиком. Каждый раз, когда я начинал получать сеанс, злоумышленник убивал / отключал мой сеанс. Если бы не возможность остановить эту атаку с помощью независимого брандмауэра, все могло быть намного хуже.
Независимый мониторинг
Ведение журнала в специализированных блоках межсетевого экрана обычно намного превосходит программные межсетевые экраны на базе хоста. Некоторые из них достаточно хороши, поэтому вам даже не понадобится внешнее программное обеспечение для мониторинга SNMP / NetFlow, чтобы получить точную картину.
Сохранение IPv4
Нет причин иметь два IP-адреса, если один для Интернета, а другой для почты. Храните службы в отдельных коробках и соответствующим образом маршрутизируйте порты через устройство, предназначенное для этого.
Я ни в коем случае не эксперт по безопасности, но похоже, что у вас брандмауэр. Кажется, что вы взяли часть основных функций брандмауэра и сделали их частью своих политик и процедур. Нет, вам не нужен брандмауэр, если вы собираетесь выполнять ту же работу, что и брандмауэр. Что касается меня, я бы предпочел сделать все, что в моих силах, для обеспечения безопасности, но при этом брандмауэр заглядывал мне через плечо, но в какой-то момент, когда вы можете делать все, что делает брандмауэр, он начинает терять актуальность.
В общем, безопасность, как уже говорилось, луковичное дело. Есть причины, по которым существуют брандмауэры, и дело не только в том, что все остальные лемминги - глупые идиоты.
Этот ответ приходит, поскольку поиск «fail2ban» на этой странице не дал мне никаких результатов. Так что, если я удваиваю другой контент, терпите меня. И извините, если я немного разглагольствую, я предоставлю простой опыт, поскольку это может пригодиться другим. :)
Это скорее специфично для Linux и сосредоточено на брандмауэре на основе хоста, что обычно является вариантом использования. Внешний брандмауэр идет рука об руку с правильной сетевой структурой, и при этом обычно учитываются другие соображения безопасности. Если вы знаете, что здесь подразумевается, то эта публикация вам, скорее всего, не понадобится. Или нет, тогда просто читайте дальше.
Запуск брандмауэров снаружи и локально может показаться нелогичным и двойным. Но это также дает возможность включить правила на внешний, без ущерба для безопасности всех остальных хостов, находящихся за ним. Необходимость может возникнуть либо по причинам отладки, либо потому, что кто-то просто облажался. Другой вариант использования будет в разделе «Адаптивный глобальный брандмауэр», для которого вам также понадобятся как глобальные, так и локальные брандмауэры.
Брандмауэр - это лишь один из аспектов надежной защищенной системы. Не устанавливать брандмауэр, поскольку он «стоит» денег, вводит SPOF или что-то еще, это просто чушь собачья, простите за мой французский. Просто настройте кластер. О, но что, если пожарная ячейка вышла из строя? Затем настройте кластер на два или более пожарных отсека.
Но что, если весь дата-центр недоступен, поскольку оба внешних оператора не работают (экскаватор отключил ваше волокно)? Тогда просто сделайте свой кластер, охватывающим несколько центров обработки данных.
Это дорого? Кластеры слишком сложные? Что ж, за паранойю нужно платить.
Просто ныть по поводу SPOF, но не желать платить больше денег или создавать немного более сложные установки - это явный случай двойных стандартов или просто небольшой кошелек на стороне компании или клиента.
Этот шаблон применяется ко ВСЕМ этим обсуждениям, независимо от того, какая услуга сейчас актуальна. Независимо от того, является ли это шлюзом VPN, Cisco ASA, используемым только для межсетевого экрана, базой данных MySQL или PostgreSQL, виртуальной системой или серверным оборудованием, серверной частью хранилища, коммутаторами / маршрутизаторами, ...
К настоящему времени вы должны уяснить эту идею.
Теоретически ваши рассуждения верны. (Можно использовать только запущенные службы.)
Но это только половина правды. Брандмауэр, особенно брандмауэр с отслеживанием состояния, может сделать для вас гораздо больше. Брандмауэры без сохранения состояния важны только в том случае, если у вас возникают проблемы с производительностью, подобные уже упомянутым выше.
Вы упомянули обертки TCP, которые реализуют в основном те же функции для защиты вашего. Ради аргумента предположим, что кто-то не знает о tcpd и любит пользоваться мышкой? fwbuilder может прийти в голову.
Вам следовало включить полный доступ из вашей сети управления, что является одним из первых вариантов использования брандмауэра на основе вашего хоста.
Как насчет настройки с несколькими серверами, когда база данных работает где-то еще, и вы не можете поместить обе / все машины в общую (частную) подсеть по какой-либо причине? Используйте брандмауэр, чтобы разрешить доступ MySQL к порту 3306 только для одного заданного IP-адреса другого сервера. Готово, просто.
И это также безупречно работает с UDP. Или каким-то другим протоколом. Брандмауэры могут быть чертовски гибкими. ;)
Кроме того, с помощью брандмауэра общие сканы портов могут быть обнаружены и смягчены, поскольку количество подключений за интервал времени можно контролировать через ядро и его сетевой стек, и брандмауэр может действовать в соответствии с этим.
Также недопустимые или непонятные пакеты могут быть обработаны до того, как они достигнут вашего приложения.
Фильтрация исходящего трафика обычно является головной болью. Но это может быть обязательно, в зависимости от контракта.
Еще одна вещь, которую может дать вам брандмауэр, - это статистика. (Считать watch -n1 -d iptables -vnxL INPUT с добавлением некоторых правил для специальных IP-адресов прямо вверху, чтобы увидеть, проходят ли пакеты.)
Вы можете видеть при обычном дневном свете, работает что-то или нет. Что ОЧЕНЬ полезно при поиске и устранении неисправностей в соединениях и при возможности сообщить другому человеку по телефону, что вы не получаете пакетов, без необходимости болтать. tcpdumpс. Сеть - это весело, большинство людей теперь просто знают, что делают, и зачастую это просто ошибки маршрутизации. Черт, даже я не всегда знаю, что делаю. Хотя я уже работал буквально с десятками сложных систем и устройств, часто с туннелированием.
Межсетевые экраны Layer7 обычно являются змеиным жиром (IPS / IDS), если не обслуживаются должным образом и не обновляются регулярно. К тому же лицензии чертовски дороги, поэтому я бы не стал их покупать, если у вас нет реальной необходимости получать все, что можно купить за деньги.
Легко, просто попробуйте это со своими обертками. : D
Смотрите маскировку.
Что делать, если у клиентов есть динамические IP-адреса и не развернута настройка VPN? Или другие динамические подходы к межсетевому экрану? На это уже намекают в вопросе, и здесь будет пример использования для К сожалению, я не могу найти брандмауэры, которые это делают. часть.
Обязательно отключите доступ к учетной записи root с помощью пароля. Даже если доступ ограничен определенными IP-адресами.
Кроме того, еще одна учетная запись blanko с паролем для входа в систему на случай потери ключей ssh или сбоя развертывания очень удобна, если что-то пойдет не так (у пользователя есть административный доступ к машине и «что-то случилось»?). Это та же идея для доступа к сети, поскольку он имеет однопользовательский режим в Linux или использует init=/bin/bash через grub для локального доступа действительно очень плохо и не может использовать живой диск по какой-либо причине. Не смейтесь, есть продукты виртуализации, запрещающие это. Что делать, если устаревшая версия программного обеспечения работает без этой функциональности?
В любом случае, даже если вы запустите свой демон ssh на каком-то эзотерическом порту, а не на 22, если вы не реализовали такие вещи, как стук порта (чтобы открыть даже другой порт и, таким образом, смягчить сканирование портов, медленно граничащее с слишком непрактичным), сканирование портов обнаружит ваш сервис в конце концов.
Обычно вы также настраиваете все серверы с одинаковой конфигурацией, с одинаковыми портами и службами из соображений эффективности. Вы не можете настроить ssh на другой порт на каждой машине. Кроме того, вы не можете изменять его на всех машинах каждый раз, когда считаете, что это «общедоступная» информация, потому что это уже сделано после сканирования. Вопрос о nmap законность или незаконность не является проблемой, если в вашем распоряжении взломанное соединение Wi-Fi.
Если эта учетная запись не называется «root», люди не смогут угадать имя учетной записи вашего «бэкдора». Но они будут знать, получат ли они еще один сервер от вашей компании или просто купят какое-то веб-пространство, и получат незащищенный / незащищенный / неконтролируемый взгляд на /etc/passwd.
В качестве чисто теоретической иллюстрации они могут использовать взломанный веб-сайт, чтобы получить доступ к вашему серверу и посмотреть, как все обычно работает у вас. Ваши инструменты поиска взлома могут не работать 24/7 (обычно они работают ночью из-за производительности диска при сканировании файловой системы?), И ваши антивирусные сканеры не обновляются через секунду нулевой день видит дневной свет, поэтому он не обнаружит эти события сразу, а без других мер защиты вы можете даже не узнать, что произошло. Вернемся к реальности: если у кого-то есть доступ к эксплойтам нулевого дня, очень вероятно, что он все равно не будет нацеливаться на ваши серверы, поскольку они просто дороги. Это просто для иллюстрации того, что всегда есть выход в систему, если возникнет «необходимость».
Но снова по теме: просто не используйте дополнительную учетную запись с паролем и не беспокойтесь? Пожалуйста, продолжайте читать.
Даже если злоумышленники узнают имя и порт этой дополнительной учетной записи, fail2ban + iptables комбинация остановит их короткими, даже если вы использовали только восьмибуквенный пароль. Кроме того, fail2ban может быть реализован и для других сервисов, расширяя горизонт мониторинга!
Для ваших собственных служб, если когда-либо возникнет такая необходимость: в основном каждая служба, регистрирующая сбои при регистрации в файле, может получить поддержку fail2ban, предоставив файл, какое регулярное выражение ему сопоставить и сколько разрешенных сбоев, а брандмауэр просто с радостью заблокирует каждый IP-адрес. сказано.
Я не говорю использовать пароли из 8 цифр! Но если их забанят на 24 часа за пять попыток неправильного пароля, вы можете догадаться, сколько времени им придется делать, если в их распоряжении нет ботнета даже при такой ужасной безопасности. И вы будете удивлены, какие пароли используют клиенты, а не только для ssh. Взглянув на пароли почты людей через Plesk говорит вам все, что вы предпочли бы не знать, если бы вы когда-либо сделали, но то, что я, конечно, не пытаюсь здесь подразумевать. :)
fail2ban это всего лишь одно приложение, которое использует что-то вроде iptables -I <chain_name> 1 -s <IP> -j DROP, но вы можете легко создать такие вещи самостоятельно с помощью магии Bash довольно быстро.
Чтобы еще больше расширить что-то подобное, объедините все IP-адреса fail2ban с серверов в вашей сети на дополнительном сервере, который курирует все списки и передает их, в свою очередь, вашим основным межсетевым экранам, блокируя весь трафик, уже находящийся на границе вашей сети.
Такую функциональность нельзя продать (конечно, можно, но это будет просто хрупкая система и отстой), но ее нужно встроить в вашу инфраструктуру.
При этом вы также можете использовать черный список IP-адресов или списки из других источников, будь они агрегированы вами или внешними.
Blockquote Ну вы правы, я не вставил туда никаких минусов. Минусы: повышенная сложность сети, единая точка отказа, единый сетевой интерфейс, из-за которого пропускная способность ограничена. Точно так же административные ошибки, допущенные на одном брандмауэре, могут убить всю вашу сеть. И боги запрещают вам блокировать себя в это время, когда это 20-минутная поездка в серверную.
Во-первых, добавить не более одного дополнительного маршрутизируемого перехода через вашу сеть несложно. Во-вторых, никакое решение межсетевого экрана, реализованное с единой точкой отказа, не является полностью бесполезным. Точно так же, как вы кластеризуете свой важный сервер или службы и используете связанные сетевые карты, вы реализуете высокодоступные межсетевые экраны. Не делать этого или не осознавать и не знать, что вы это сделаете, - очень близорука. Простое заявление о том, что существует единый интерфейс, не делает что-то автоматически узким местом. Это утверждение показывает, что вы не знаете, как правильно спланировать и развернуть брандмауэр, рассчитанный на обработку трафика, который будет проходить через вашу сеть. Вы правы, говоря, что ошибка в политике может нанести вред всей вашей сети, но я бы сказал, что поддержание отдельных политик на всех ваших серверах гораздо более подвержено ошибкам, чем в одном месте.
Что касается аргумента, что вы следите за исправлениями безопасности и следуете руководствам по безопасности; это в лучшем случае шаткий аргумент. Обычно исправления безопасности доступны только после обнаружения уязвимости. Это означает, что все время, пока вы используете общедоступные серверы, они уязвимы, пока не будут исправлены. Как отмечали другие, системы IPS могут помочь предотвратить компрометацию из таких уязвимостей.
Если вы думаете, что ваши системы настолько безопасны, насколько это возможно, это хорошая уверенность. Однако я бы порекомендовал вам провести профессиональный аудит безопасности вашей сети. Это может просто открыть вам глаза.
Межсетевые экраны с проверкой пакетов с отслеживанием состояния НЕ должны стоять перед общедоступными серверами. Вы принимаете все подключения, поэтому отслеживание состояния бесполезно. Традиционные брандмауэры являются серьезной помехой при DDoS-атаках и, как правило, в первую очередь выходят из строя при DDoS-атаках, даже до того, как полоса пропускания канала или ресурсы сервера будут полностью израсходованы.
Фильтры пакетов без сохранения состояния на маршрутизаторах имеют смысл перед общедоступными серверами, но только в том случае, если они могут обрабатывать линейную скорость всего входящего и исходящего трафика (например, аппаратный ACL в маршрутизаторе).
Google, Facebook и даже Microsoft не ставят традиционные «брандмауэры» перед общедоступными серверами. Это должен знать любой, кто запускал общедоступные веб-службы в масштабе «более одного сервера».
Другие функции традиционных межсетевых экранов, таких как Cisco ASA или других, лучше всего реализовать на самих хостах, где их можно эффективно масштабировать. В любом случае, ведение журнала, IDS и т. Д. - все это программные функции брандмауэров, поэтому они просто становятся огромным узким местом и целью DDoS, если размещены перед общедоступными серверами.
Прежде всего, говоря о переадресации портов, я думаю, вы объединяете межсетевой экран с NAT. Хотя в наши дни NAT очень часто функционируют как брандмауэры де-факто, это не та цель, для которой они были разработаны. NAT - это инструмент маршрутизации. Брандмауэры предназначены для регулирования доступа. Для ясности мысли важно, чтобы эти концепции были разделены.
Конечно, верно, что размещение сервера за блоком NAT и затем настройка NAT для пересылки чего-либо на этот сервер не более безопасны, чем размещение сервера непосредственно в Интернете. Я не думаю, что с этим кто-то будет спорить.
Точно так же брандмауэр, настроенный для разрешения всего трафика, вообще не является брандмауэром.
Но действительно ли вам нужна политика «разрешить весь трафик»? У кого-нибудь когда-нибудь была необходимость ssh на любой из ваших серверов с российского IP-адреса? Пока вы возитесь с настройкой нового экспериментального сетевого демона, нужен ли всему миру доступ к нему?
Сила брандмауэра в том, что он позволяет держать открытыми только те службы, которые, как вы знаете, должны быть открыты, и поддерживать единую точку контроля для реализации этой политики.
Должен сказать, Эрни, что, хотя вы, кажется, много делаете для усиления защиты серверов и защиты от атак и уязвимостей, я не согласен с вашей позицией в отношении межсетевых экранов.
Я отношусь к безопасности как к луку, потому что в идеале у вас есть уровни, через которые вы должны пройти, прежде чем добраться до ядра, и лично я считаю, что отсутствие какой-либо формы аппаратного брандмауэра на периметре вашей сети является большой ошибкой.
Я признаю, что подхожу к этому с точки зрения «того, к чему я привык», но я знаю, что каждый месяц я получаю хороший небольшой список исправлений этого месяца от Microsoft, многие из которых используются в дикой природе. . Я предполагаю, что то же самое происходит практически с любой ОС и набором приложений, о которых вы хотите подумать.
Я не предлагаю, чтобы брандмауэры покончили с этим, и брандмауэры не защищены от ошибок / уязвимостей, очевидно, что «аппаратный» брандмауэр - это просто программное обеспечение, работающее на аппаратном стеке.
Тем не менее, я сплю намного безопаснее, зная, что если у меня есть сервер, которому нужен только порт 443 для доступа из Интернета, мой периметр Juniper гарантирует, что из Интернета доступен только порт 443. Не только это, но и мой Пало-Альто гарантирует, что входящий трафик расшифровывается, проверяется, регистрируется и сканируется на предмет IPS / IDS - не то, чтобы это избавляло от необходимости поддерживать сервер (ы) в безопасности и в актуальном состоянии, но почему бы вам НЕ обнаружить это преимущество, учитывая, что оно может смягчить уязвимости нулевого дня и старые добрые человеческие ошибки?
Уязвимости трудно предсказать. Практически невозможно предсказать, каким образом будет эксплуатироваться ваша инфраструктура. Наличие брандмауэра «поднимает планку» для злоумышленника, желающего использовать уязвимость, и это важная часть, ДО того, как вы узнаете, что это за уязвимость. Кроме того, разветвления брандмауэра можно легко понять заранее, поэтому вы вряд ли сможете ПРИЧИНИТЬ проблемы с брандмауэром, которые более серьезны, чем проблемы, которых вы, вероятно, избежите.
Поэтому «за установку файервола никого не уволили». Их реализация сопряжена с очень низким риском и имеет ВЫСОКУЮ вероятность предотвращения или смягчения последствий эксплойта. Кроме того, большинство действительно опасных уязвимостей в конечном итоге используется автоматизацией, поэтому все «необычное» в конечном итоге сломает бота или, по крайней мере, заставит его пропустить вас в пользу более легкой цели.
Примечание; брандмауэры предназначены не только для Интернета. Ваш бухгалтерский отдел. не нужен ssh / что-либо для вашего ldap-сервера, поэтому не давайте его им. Разделение внутренних служб может иметь большое значение для работы по уборке в случае, если что-то ДЕЙСТВИТЕЛЬНО пробивает стены замка.
В физическом мире люди хранят ценности, складывая их в сейфы. Но нет сейфа, который нельзя было бы взломать. Сейфы или защитные контейнеры оцениваются по времени, необходимому для взлома. Цель сейфа - задержать злоумышленника на достаточно долгое время, чтобы он был обнаружен, и активные меры остановили атаку.
Точно так же правильное предположение о безопасности состоит в том, что ваши незащищенные машины в конечном итоге будут скомпрометированы. Брандмауэры и узлы-бастионы настроены не для предотвращения взлома вашего сервера (с вашими ценными данными), а для того, чтобы заставить злоумышленника сначала скомпрометировать их и позволить вам обнаружить (и предотвратить) атаку до того, как ценности будут потеряны.
Обратите внимание, что ни брандмауэры, ни банковские хранилища не защищают от внутренних угроз. Это одна из причин для банковских бухгалтеров брать двухнедельный отпуск подряд, а для серверов - иметь полные меры внутренней безопасности, даже если они защищены хостами-бастионами.
В исходном посте вы, кажется, имеете в виду, что пересылаете пакеты «внешнего мира» через брандмауэр прямо на свой сервер. В этом случае да, ваш брандмауэр не особо много работает. Лучшая защита периметра достигается с помощью двух брандмауэров и хоста-бастиона, где нет прямого логического соединения снаружи и изнутри - каждое соединение завершается в хосте-бастионе DMZ; каждый пакет проверяется надлежащим образом (и, возможно, разбирается) перед пересылкой.
Почему всем вашим серверам нужен публичный адрес?
Установите сервер в серверной и дайте ему публичный IP-адрес.
Из примерно 14 серверов, которые я использую на регулярной основе, только 2 имеют общедоступные интерфейсы.
Отредактировано для добавления: В других сетях, к управлению которыми я приложил руку, у нас была возможность выключать / включать службы по желанию, тогда как у нас не было доступа для управления брандмауэром. Я даже не могу сказать вам, сколько раз, конечно, непреднамеренно, ненужная служба (SMTP) включалась и оставалась включенной, и единственное, что спасало нас от превращения в спам-дамп и попадания в черный список, был брандмауэр.
Кроме того, полностью ли зашифрован весь трафик, который проходит между серверами?
Вы, конечно, можете водить машину со скоростью 100 миль в час без ремней безопасности, без подушек безопасности и лысых шин, но зачем вам ??
Брандмауэры могут помешать пользователям системы открывать доступные в сети службы, о которых администраторы не знают, или выполнять переадресацию портов на другие машины. Используя модуль hashlimit, брандмауэры также могут ограничивать скорость нарушителей на основе удаленного IP-адреса.
Брандмауэр - это еще одна подстраховка, обеспечивающая соблюдение ваших политик. Конечно, не запускайте службы, которых вы не ожидаете.
Я определенно рекомендую, например, своевременно устанавливать обновления программного обеспечения, но я также рекомендую брандмауэры на всех машинах. Это как когда я вожу: конечно, я стараюсь избегать препятствий и других машин, но я также пристегиваюсь ремнем безопасности и имею подушки безопасности на случай, если случится непредвиденное.
Вы можете не осознавать, какую выгоду вы получаете от брандмауэров, просто потому, что все еще использует их. В тот день, когда буквально у всех, вплоть до домашних пользователей DSL, есть брандмауэры, перехват портов был почти отброшен как возможный вектор атаки. Хороший хакер не станет тратить время на проверку таких вещей.