☰

방화벽은 IP 스푸핑 공격을 완화하는 데 어떻게 기여합니까?

tag-icon • tag-icon firewall
방화벽은 IP 스푸핑 공격을 완화하는 데 어떻게 기여합니까?

특정 IP 주소에서만 서버에 대한 액세스를 허용하도록 방화벽을 구현할 수 있지만 사람들이 TCP 패킷에서 소스 IP 주소를 위조할 수는 없다는 것을 알고 있습니다. 이것이 실제로 어떻게 부도덕한 사람들이 귀하의 서버에 접근하는 것을 막습니까?

답변1

Dude가 말한 것은 당신이 찾는 답입니다.

내 생각에 당신이 생각하는 것은 다음과 같습니다.

SERVER.......................CLIENT
............[FIREWALL].........|
..|............................|
..|_>___[CHECK FOR AUTHORITY]_<_|

이 다이어그램에서는 서버와 클라이언트 모두에 방화벽이 있다고 가정합니다(일반적으로 방화벽이 있습니다).

권한이 실패하면 서버/클라이언트에 대한 호출이 무시됩니다.

따라서 서버 IP가 xxx.xxx.xxx.1이고 클라이언트가 xxx.xxx.xxx.2이고 클라이언트가 인증 없이 명령을 보내 서버에 액세스하려고 하면 서버 로그는 다음과 같습니다. xxx.xxx .xxx.2 [인증 실패 - 무시]

xxx.xxx.xxx.2가 서버에 액세스할 수 있는 권한이 있는 자신의 IP를 xxx.xxx.xxx.3으로 숨긴 경우 이런 일이 발생합니다. xxx.xxx.xxx.3 -> 명령 패킷을 xxx.xxx.xxx로 보냅니다. .1 xxx.xxx.xxx.1 -> 명령에 응답하고 xxx.xxx.xxx.3으로 패킷을 보냅니다.

따라서 xxx.xxx.xxx.1은 검색된 명령을 결코 얻지 못합니다.

이제 당신이 생각하는 것은 무엇입니까?그게 어떻게 안전합니까?

대부분의 서버는 실제로 이렇게 작동합니다.

SERVER..............................CLIENT
..|______________[CONNECT]___________<_|
............|
...[TEST AUTHORIZATION]
...........|
......[PASSED]
..........|
...........[SEND CONNECTED RESPONSE]...|

따라서 클라이언트가 인증을 받고 서버를 호출하면 서버는 연결된 응답으로 응답하여 클라이언트가 이 응답을 받으면 서버는 이것이 올바른 클라이언트임을 알게 됩니다.

답변2

확실히 누군가가 TCP/IP 패킷을 보내기 위해 자신의 IP 주소를 위조할 수 있지만, 그가 사용한 가짜 IP 주소로 이동하기 때문에 응답을 전혀 받지 못할 것입니다! 따라서 이 방법은 양방향 통신을 원하는 사람에게는 쓸모가 없습니다!

답변3

보낸 사람을 속이는 것만으로는 충분하지 않으며, 유용한 많은 작업을 수행하기 위해 답변을 다시 받고 싶을 수도 있습니다. 그러면 중간에 풀맨을 해야 합니다.

그러나 방화벽은 일반적으로 소스 IP를 기반으로 하는 많은 것을 "허용"하지 않습니다.

방화벽은 주로 다음 용도로 사용됩니다.블로킹, 승인용이 아님.

즉, 신뢰할 수 없는 IP는 VPN이 있는지도 모르고 VPN 서비스에 연결할 수도 없습니다. 아니면 쉽게 공격하세요. 그러나 주요 보안 기능은 VPN 자체입니다.

IP 기반 필터링은 가격이 저렴하기 때문에첫 번째 방어선. 방화벽에서 패킷을 거부한다는 것은 뒤에 있는 서비스가 훨씬 적은 "공격"(및 기타 소음)을 처리해야 함을 의미합니다. 방화벽에 대해 DDoS를 실행하는 것은 요청을 처리하는 서버의 CPU가 아닌 인터넷 연결을 채워야 하기 때문에 실제 서비스에 대해 DDoS를 실행하는 것보다 어렵습니다.

답변4

단방향 연결(예: UDP와 같은 상태 비저장 프로토콜)을 사용하면 실제로 해를 끼칠 수 있지만 이는 결국 IP 기반(안전하지 않은) 인증을 피하는 것으로 귀결됩니다.

TCP

연결을 설정하려면 패킷을 원래 호스트로 다시 보내야 하므로 TCP는 일반적으로 영향을 받지 않습니다. 진행 방법은 다음과 같습니다.

Alice는 승인된 호스트 목록에 있습니다.

  • Alice는 Bob에게 SYN 패킷을 보냅니다.
  • Bob은 Alice에게 SYN-ACK를 반환하여 계속 진행할 수 있음을 알립니다.
  • Alice는 ACK 패킷을 진행하고 의도한 페이로드를 계속 진행합니다.

Charlie는 서비스에 연결을 시도합니다.

  • Charlie는 Bob에게 SYN 패킷을 보냅니다.
  • 방화벽이 패킷을 차단하고 Bob은 아무 것도 받지 못합니다(또는 Charlie가 그에게 연결을 시도한 로그에 경고가 표시됩니다).
  • Charlie는 자신의 요청이 거부되었음을 알 수도 있고 모를 수도 있습니다(방화벽 구성에 따라 요청 시간이 초과되거나 Bob이 명시적으로 ICMP 거부/접근할 수 없는 패킷을 보냅니다).

Charlie는 Alice가 서비스에 액세스할 수 있다는 것을 어떻게든 알고 있습니다.

  • Charlie는 Bob에게 그가 Alice인 것처럼 가장하여 SYN 패킷을 보냅니다.
  • 패킷은 방화벽을 통과하고 Bob은 SYN-ACK를 Alice에게 반환합니다.
  • Alice는 Bob에게서 뭔가를 기대하지 않았기 때문에 RST-ACK(승인 재설정) 또는 ICMP Unreachable이라고 응답합니다.
  • Charlie는 요청이 처리되었는지 결코 알 수 없습니다.

이제 연결이 이미 설정되어 있으면 어떻게 되나요? 이것이 바로 시퀀스 번호의 용도입니다. 다른 사람이 예측할 수 없으며(해서는 안 되며) 양 당사자는 시퀀스가 ​​항상 1씩 증가할 것으로 기대합니다.

  • 연결이 설정되면 양 당사자는 바람직하게는 임의의 시퀀스 번호를 선택합니다.
  • 전송하는 각 패킷에서 시퀀스 번호는 1씩 증가해야 합니다. 이를 통해 수신측에서는 잘못된 시퀀스 번호가 있는 패킷을 거부하고 허용된 창 내에 있는 패킷의 순서를 변경할 수 있습니다.

이제 Charlie는 시퀀스 번호를 예측할 수 없기 때문에 Alice와 Bob 사이의 기존 연결에 패킷을 "주입"할 방법이 없으며 그의 패킷은 로그에 경고 또는 알림과 함께 Bob에 의해 거부됩니다.

UDP

프로토콜이 UDP인 경우 피어가 인터넷에 스푸핑된 패킷을 주입할 수 있는 만큼 스푸핑에 매우 취약하므로 전송 대신 애플리케이션 계층에 인증 또는 암호화 메커니즘을 추가해야 합니다.

완화

ISP는 IP 주소 스푸핑을 방지하기 위한 조치를 추가할 것입니다. 이는 자신의 넷블록과 일치하지 않는 모든 패킷이 라우터에서 나가는 것을 거부하고, 넷블록과 일치하는 패킷이 네트워크로 들어가는 것을 거부하는 것만큼 간단할 수 있습니다.

로컬 네트워크에서는 누군가의 스푸핑을 방지할 수 있는 메커니즘이 많지 않기 때문에 스푸핑을 수행하는 것이 매우 쉽습니다.

관련 정보