Безопасно ли ограничивать чувствительные точки входа только через IP? [Дубликат]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Может быть, это поможет? Я искал тот же ответ и нашел этот 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

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

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

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

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

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

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

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

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

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