IP 주소 필터링은 얼마나 안전합니까?

https://stackoverflow.com/questions/437146

22-07-2019
|

문제

민감한 데이터가있는 내부 앱을 배포 할 계획입니다. 나는 우리가 그것을 일반 인터넷, 내부 네트워크에만 노출되지 않은 기계에 넣을 것을 제안했습니다. IT 부서는이 제안을 거부하면서 하나의 응용 프로그램을 위해 전체 컴퓨터를 따로 설정하는 것이 가치가 없다고 말합니다. (앱에는 관련이있는 경우 자체 도메인이 있지만 URL을 기반으로 요청을 차단할 수 없다고 들었습니다.)

앱 내부에서 나는 내부 IP 주소에서 온 경우에만 요청을 존중하도록 프로그램했다. 그렇지 않으면 "이것을 볼 수 없다"라는 페이지가 표시됩니다. 우리의 내부 주소는 모두 고유 한 패턴을 가지고 있으므로 Regex에 대한 요청 IP를 확인하고 있습니다.

그러나 나는이 전략에 대해 긴장합니다. 그것은 나에게 일종의 멍청한 느낌입니다. 이것이 합리적으로 안전합니까?

해결책

IP 필터링은 아무것도 아닌 것보다 낫지 만 두 가지 문제가 있습니다.

IP 주소를 스푸핑 할 수 있습니다.
내부 시스템이 손상된 경우 (예 : 트로이 목마 설치를 통한 클라이언트 워크 스테이션 포함), 공격자는이를 점프 호스트 또는 프록시로 사용할 수있는 시스템을 공격 할 수 있습니다.

이것이 정말로 민감한 데이터 인 경우 반드시 전용 머신이 필요하지는 않지만 (모범 사례 임), 최소한 사용자를 어떻게 든 인증해야하며, 같은 기계.

그리고 그것이 정말로 민감하다면, 보안 전문가가 당신이하고있는 일을 검토 할 수 있도록하십시오.

편집 : 우연히도, 가능하다면 Regex를 버리고 TCPWrappers 또는 OS 내의 방화대 기능과 같은 것을 사용하십시오. 또는 앱에 대해 다른 IP 주소를 가질 수 있다면 방화벽을 사용하여 외부 액세스를 차단하십시오. (그리고 방화벽이 없다면 데이터를 포기하고 공격자에게 이메일을 보낼 수도 있습니다 :-)

다른 팁

차라리 SSL 및 일부 인증서 또는 IP 필터링 대신 간단한 사용자 이름 / 비밀번호 보호 기능을 사용합니다.

그것은 당신이 얼마나 안전 해야하는지 정확히 달라집니다.

귀하의 서버가 외부 호스팅되고 VPN을 통해 연결되어 있지 않다고 가정합니다. 따라서 HTTPS에 대한 요청 주소 (HTTPS를 사용하고 있습니까, 그렇지 않습니까?) 사이트가 자신의 조직의 네트워크 내에 있는지 확인하고 있습니다.

IP 주소와 일치하기 위해 Regex를 사용하여 Sounds Sound Iffy, 다른 사람과 마찬가지로 네트워크/넷 마스크를 사용할 수 없습니까?

실제로 얼마나 안전해야합니까? IP 주소 스푸핑은 쉽지 않으며, 스푸핑 패킷은 상류 라우터를 조작하여 리턴 패킷을 공격자에게 리디렉션 할 수 없다면 HTTPS 연결을 설정하는 데 사용할 수 없습니다.

실제로 안전 해야하는 경우 IT 부서에 VPN을 설치하고 개인 IP 주소 공간을 통과하십시오. 해당 개인 주소에 대한 IP 주소 제한을 설정하십시오. 호스트 기반 VPN을 통해 라우팅이있는 IP 주소 제한은 누군가가 상류 기본 게이트웨이를 타협하더라도 여전히 안전합니다.

응용 프로그램이 IP 주소를 확인하는 경우 매우 취약합니다. 이 시점에서 IP 필터링이 실제로 필요한 라우터에서 보호 기능이 없습니다. 응용 프로그램은 전송 IP 주소에 대한 HTTP 헤더 정보를 확인하고 있으며 스푸핑하기가 매우 쉽습니다. 라우터에서 IP 주소를 낮추면 다른 스토리이며 어디에서 사이트에 액세스 할 수 있는지에 대한 실제 보안을 구입할 것입니다.

당신이하고있는 경우, 내부적으로 응용 프로그램에 액세스하고 있다면, 조직 내부의 당사자로부터 정보를 보호하려고하지 않거나 고객 인증서가 필요하지 않으면 SSL은 많이 구매하지 않습니다. 이것은 외부 연결에서 사이트에 액세스하지 않을 것이라고 가정합니다 (VPN은 내부 네트워크로 터널링하고 기술적으로 해당 시점의 일부이기 때문에 계산되지 않습니다). 그것은 아프지 않고 설정하기가 어렵지 않으며 모든 문제에 대한 해결책이 될 것이라고 생각하지 마십시오.

IP 주소로 제한되면 IP 주소를 스푸핑 할 수 있지만 답장을받을 수 없습니다. 물론 인터넷에 노출 된 경우 앱에 대한 공격 이외의 공격에 여전히 타격을받을 수 있습니다.

Ressource 문제에 대한 나의 첫 생각은 가상 머신과 마법을 작동시킬 수 없는지 묻는 것입니다.

그 외에 - 당신이 확인하는 IP 주소가 당신이 아는 IP가 애플리케이션에 액세스 해야하는 컴퓨터 또는 로컬 IP 범위에 속하는 경우, 그것이 충분히 안전 할 수없는 방법을 알 수 없습니다 (실제로 사용 중입니다. 사이트가 "숨겨진"상태로 유지되는 것은 엄청나게 중요하지는 않지만 프로젝트에서 ATM에 대해 동시에 접근합니다).

모든 내부 IP가 주어진 Regex와 일치한다고해서 주어진 Regex와 일치하는 모든 IP가 내부임을 의미하지는 않습니다. 따라서 Regex는 가능한 보안 실패의 지점입니다.

사이트를 구축하는 데 어떤 기술이 사용되었는지는 모르겠지만 Windows/Asp.net 인 경우 요청이 이루어질 때 Windows 자격 증명을 기반으로 요청 시스템의 권한을 확인할 수 있습니다.

모든 보안과 마찬가지로 자체적으로는 쓸모가 없습니다. 공개 웹 서버에 넣어야하는 경우 IP 화이트리스트를 사용하십시오. ~와 함께 기본 사용자 이름/비밀번호 인증, ~와 함께 SSL, ~와 함께 괜찮은 모니터링 설정, ~와 함께 최신 서버 응용 프로그램.

즉, 서버에 공개적으로 액세스 할 수 있도록하는 점은 무엇입니까? 그런 다음 내부 IP 주소로만 제한하는 것은 무엇입니까? 기본적으로 NAT가 무료로 제공하는 것을 재창조하고 내부 전용 서버를 사용하여 웹 서버 익스플로잇 및 좋아요에 대해 걱정해야합니다.

당신은 외부에 액세스 할 수있게함으로써 아무것도 얻지 못하는 것 같으며, 그것을 내부적으로 전용하게하는 데 많은 이점이 있습니다 ..

귀하의 보안은 가장 약한 링크만큼 강력합니다. 그랜드 계획에서 IP를 스푸핑하는 것은 어린이의 놀이입니다. SSL을 사용하고 클라이언트 CERT가 필요합니다.

다른 종류의 IP를 구별하는 것이 먼저 유용해졌습니다. VPN 기술이 아닌 행정 관계를 기반으로 노드를 상호 연결합니다. 관계가 정의되면 보안 및 서비스 품질과 같은 요구 사항에 따라 다른 기술을 사용할 수 있습니다.

어쩌면 이것이 도움이 될까요? 나는 같은 대답을 찾고 있었고 Red Hat Linux Ent 의이 아이디어뿐만 아니라이 stackoverflow를 발견했습니다. 곧해볼 게요. 도움이되기를 바랍니다.

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

여기서 0/24는 보호하려는 LAN 범위입니다. 아이디어는 "인터넷"을 직접 직면하여 (앞으로) 장치가 로컬 IP 네트워크를 스푸핑 할 수 없다는 것을 차단하는 것입니다.

ref : http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html

적절한 방화벽은 IP 스푸핑으로부터 보호 할 수 있으며, 발신자 ID를 스푸핑하는 것만 큼 쉽지 않으므로 스푸핑 위험으로 인해 IP 필터링을 사용하지 않아야합니다. 보안은 레이어에 적용되는 것이 가장 좋으므로 하나의 메커니즘에만 의존하지 않습니다. 그렇기 때문에 WAF 시스템, 사용자 이름+비밀번호, 레이어 3 방화벽, 레이어 7 방화벽, 암호화, MFA, SIEM 및 기타 보안 조치가있는 이유는 각각 보호가 추가됩니다 (비용 증가).

이것이 당신이 말하는 웹 응용 프로그램이라면 (질문에서 명확하지 않은), 고급 보안 시스템의 비용없이 솔루션이 상당히 간단합니다. IIS, Apache 등을 사용하든간에 응용 프로그램에 대한 연결을 특정 대상 URL로 제한 할 수 있으며 소스 IP 주소 (앱 변경이 필요하지 않은 경우). IP 소스 제한과 결합 된 IP 기반 웹 브라우징을 방지하면 캐주얼 브라우징/공격으로부터 상당한 보호를 제공해야합니다. 이것이 웹 앱이 아닌 경우, 사람들이 OS 기반 보안 (다른 사람이 제안한)이 유일한 옵션인지 아닌지를 알 수 있도록보다 구체적이어야합니다.

IP 화이트리스트는 다른 사람들이 언급했듯이 IP 스푸핑 및 중간 공격에 취약합니다. MITM에서는 일부 스위치 또는 라우터가 손상되었으며 "답장"을 볼 수 있습니다. 모니터링하거나 변경할 수도 있습니다.

SSL 암호화로 취약점도 고려하십시오. 노력에 따라, 이것은 Primes의 재사용과 함께 잘 알려진 Gaff뿐만 아니라 MITM에도 포일 될 수 있습니다.

데이터의 민감도에 따라 SSL에 정착하지는 않지만 더 많은 보안을 위해 Strongswan 또는 OpenVPN과 함께 진행됩니다. 제대로 처리하면 MITM에 훨씬 덜 취약합니다.

화이트리스트 혼자 (SSL을 사용하더라도)에 대한 의존도 나는 "낮은 등급"을 고려할 것이지만, 당신의 요구에 충분할 수 있습니다. 그 의미를 예리하게 인식하고 "허위 보안 감각"의 함정에 빠지지 마십시오.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow