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

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

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

Но я нервничаю по поводу этой стратегии. Для меня это выглядит очень жалким. Насколько это безопасно?

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

Это точно зависит от того, насколько вы действительно нуждаетесь в этом.

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

Ваша безопасность настолько сильна, насколько ваша самая слабая ссылка. В великой схеме вещей подмена IP - это детская игра. Используйте SSL и требуйте сертификаты клиентов.

Ответ 10

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

Ответ 11

Может, это поможет? Я искал тот же ответ и нашел этот stackoverflow, а также эту идею от Red Hat Linux Ent. Я попробую это скоро. Надеюсь, это поможет.

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

Где 0/24 - диапазон ЛВС, который вы хотите защитить. Идея состоит в том, чтобы блокировать "интернет" (Forward) устройства от возможности обманывать локальную IP-сеть.

Ссылка: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html

Ответ 12

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

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

Ответ 13

"Белый список IP", как отмечали другие, уязвим для IP-спуфинга и атак "Man-in-the-Middle". На MITM учтите, что некоторые коммутаторы или маршрутизаторы были скомпрометированы и будут видеть "ответы". Он может контролировать или даже изменять их.

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

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

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