Насколько безопасна фильтрация IP-адресов?

Question

Я планирую развернуть внутреннее приложение с конфиденциальными данными. Я предложил поставить его на компьютер, который не подключен к общему Интернету, а только на нашу внутреннюю сеть. Это. Департамент отклонил это предложение, заявив, что не стоит выделять целую машину для одного приложения. (У приложения есть собственный домен на случай, если это уместно, но мне сказали, что они не могут блокировать запросы на основе URL.)

Внутри приложения я запрограммировал его так, чтобы он учитывал запросы только в том случае, если они поступают из внутреннего IP адрес, в противном случае он просто показывает страницу с надписью «вы не можете смотреть на это». Наши внутренние адреса имеют четкую структуру, поэтому я проверяю запрос I.P. против регулярного выражения.

Но я нервничаю по поводу этой стратегии. Мне кажется, это немного не по себе. Это достаточно безопасно?

Answer 1

IP-фильтрация лучше, чем ничего, но у нее есть две проблемы:

1. IP-адреса могут быть подделаны.

2. Если внутренняя машина скомпрометирована (включая рабочую станцию ​​клиента, например, посредством установки трояна), то злоумышленник может использовать ее в качестве хоста-прыгуна или прокси для атаки на вашу систему.

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

И если это действительно деликатный вопрос, попросите специалиста по безопасности проверить, что вы делаете.

edit: между прочим, если вы можете, откажитесь от регулярного выражения и используйте что-то вроде tcpwrappers или функций брандмауэра в ОС, если они есть. Или, если у вас может быть другой IP-адрес для вашего приложения, используйте брандмауэр для блокировки внешнего доступа. (А если у вас нет брандмауэра, то вы можете отказаться и отправить свои данные злоумышленникам по электронной почте: -)

Answer 2

Я бы предпочел использовать SSL и некоторые сертификаты или простую защиту имени пользователя / пароля вместо фильтрации IP.

Answer 3

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

Если вы используете внутренний доступ к приложению, то SSL не будет вам дорого стоить, если вы не попытаетесь защитить информацию от сторонних организаций или если вам требуются клиентские сертификаты. Это предполагает, что вы никогда не будете получать доступ к сайту из внешнего соединения (VPN не учитываются, потому что вы туннелируете во внутреннюю сеть и технически являетесь ее частью в этот момент). Это тоже не повредит и не так сложно настроить, просто не думайте, что это решение всех ваших проблем.

Answer 4

Это зависит от того, КАК безопасно вы действительно должны быть.

Я предполагаю, что ваш сервер размещен снаружи и не подключен через VPN. Поэтому вы проверяете, что запрашивающие адреса для вашего HTTPS-сайта (вы используете HTTPS, не так ли?) Находятся в сетях вашей организации.

Использование регулярного выражения для сопоставления IP-адресов звучит странно, разве вы не можете просто использовать маску сети / сети как все остальные?

Насколько безопасным оно действительно должно быть? Подделка IP-адресов не легка, подделанные пакеты не могут быть использованы для установления HTTPS-соединения, если они также не манипулируют вышестоящими маршрутизаторами, чтобы позволить перенаправлять возвращаемые пакеты атакующему.

Если вы хотите, чтобы он был действительно безопасным, просто попросите ваш ИТ-отдел установить VPN и маршрутизировать через пространство частных IP-адресов. Установите ограничения вашего IP-адреса для этих частных адресов. Ограничения IP-адресов, когда маршрутизация осуществляется через VPN на основе хоста, по-прежнему безопасны, даже если кто-то скомпрометирует вышестоящий шлюз по умолчанию.

Answer 5

Как и вся безопасность, сама по себе она бесполезна. Если вам нужно разместить его на общедоступном веб-сервере, используйте белый список IP-адресов, с базовым именем пользователя / паролем, с SSL, с приличным мониторингом setup, с современным серверным приложением.

Тем не менее, какой смысл в том, чтобы сервер был общедоступным, а затем ограничивался только внутренними IP-адресами? Похоже, что это в основном переосмысление того, что NAT дает вам бесплатно и с внутренним сервером, плюс вам нужно беспокоиться об уязвимостях веб-сервера и подобных вещах.

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

Answer 6

То, что все ваши внутренние IP-адреса соответствуют заданному регулярному выражению, не означает, что все IP-адреса, соответствующие заданному регулярному выражению, являются внутренними. Таким образом, ваше регулярное выражение является точкой возможного сбоя безопасности.

Я не знаю, какую технологию вы использовали для создания своего сайта, но если это Windows / ASP.net, вы можете проверить разрешения запрашивающего компьютера на основе его учетных данных Windows при выполнении запроса.

Answer 7

Моей первой мыслью по вопросу о ресурсах было бы спросить, нельзя ли поработать над магией с виртуальной машиной?

Кроме этого - если IP-адреса, по которым вы проверяете, являются либо IP-адресами, которые вы ЗНАЕТЕ, принадлежат компьютерам, которые должны иметь доступ к приложению, либо находятся в локальном диапазоне IP-адресов, то я не могу понять, как это не могло быть достаточно безопасно На самом деле я использую похожий подход atm в проекте, хотя не исключено, что сайт остается «скрытым»).

Answer 8

Если он ограничен IP-адресом, то, хотя они могут подделать IP-адрес, они не смогут получить ответ. Конечно, если он подключен к Интернету, он все равно может подвергаться атакам, отличным от приложения.

Answer 9

Белый список IP-адресов, как уже упоминалось, уязвим для подмены IP-адресов и атак типа «человек посередине». На MITM учтите, что какой-то коммутатор или маршрутизатор был скомпрометирован и увидит «ответы». Он может либо контролировать, либо даже изменять их.

Рассмотрим также уязвимости с SSL-шифрованием. В зависимости от усилия это может быть сорвано в MITM, а также в известных багах с повторным использованием простых чисел и т. Д.

В зависимости от чувствительности ваших данных я бы не стал соглашаться на SSL, но для большей безопасности выбрал бы StrongSWAN или OpenVPN. При правильном обращении они будут намного менее уязвимы для MITM.

Опора только на белый список (даже с SSL) я бы посчитал "низким классом", но может быть достаточным для ваших нужд. Просто знайте о последствиях и не попадите в ловушку «ложного чувства безопасности».

Answer 10

Правильный брандмауэр может защитить от IP-спуфинга, и это не так просто, как, скажем, подделка вашего идентификатора вызывающего абонента, поэтому аргумент / не / использовать IP-фильтрацию из-за опасности спуфинга немного устарел. Безопасность лучше всего применять в слоях, поэтому вы не полагаетесь только на один механизм. Вот почему у нас есть системы WAF, имя пользователя + пароль, брандмауэры 3-го уровня, брандмауэры 7-го уровня, шифрование, MFA, SIEM и множество других мер безопасности, каждая из которых добавляет защиту (с повышением стоимости).

Если это веб-приложение, о котором вы говорите (что было непонятно из вашего вопроса), решение довольно простое без затрат на современные системы безопасности. Независимо от того, используете ли вы IIS, Apache и т. Д., У вас есть возможность ограничивать подключения к вашему приложению определенным целевым URL-адресом, а также исходным IP-адресом - никаких изменений в вашем приложении не требуется - для каждого приложения. Предотвращение просмотра вашего приложения на основе IP-адреса в сочетании с ограничениями на источник IP-адреса должно обеспечить вам значительную защиту от случайного просмотра / атак. Если это не веб-приложение, вам нужно быть более конкретным, чтобы люди знали, является ли безопасность на основе ОС (как было предложено другими) вашим единственным вариантом или нет.