로드 밸런서와 실제 IP 관계가 보안에 어떤 위험을 줍니까?

보안 전문가의 이점 중 하나는 수많은 팀과 협력한다는 것입니다. 감사 후 보안 전문가는 데이터베이스 관리자 및 분석가와 협력할 기회를 갖게 됩니다. 애플리케이션이 적절하고 안전하게 작동하기 위해 이러한 팀은 공통 기반이 있는 보안 취약성을 처리하려고 합니다. 이 팀 간의 대화는 실제 IP에 대한 몇 가지 문제를 제기합니다.

프록시 및 실제 IP 개념

오늘날의 웹 애플리케이션은 여러 앱 서버와 데이터베이스 시스템에서 실행됩니다. 동일한 소스 코드를 공유하는 두 개의 애플리케이션 서버를 상상해 보십시오. 로드 상황에 따라 이러한 서버 중 하나에서 사용자의 요청을 충족할 준비가 되어 있습니다. 애플리케이션 서버 앞에서 HTTP 요청을 처리하는 로드 밸런싱 메커니즘은 어떤 요청을 어떤 애플리케이션 서버로 전달할지 결정합니다. 이것은 미들웨어 시스템 관리자와 소프트웨어 개발자에게 큰 질문을 제기합니다. 사용자의 실제 IP 주소는 무엇입니까?

프록시는 두 시스템 간의 데이터 전송을 담당합니다. 로드 밸런서는 프록시를 담당하는 메커니즘입니다. 즉, 단 하나의 시스템이 사용자 및 애플리케이션 서버와 통신합니다. 네트워크 트래픽 측면에서 웹 A 또는 웹 B 서버는 항상 로드 밸런서의 IP 주소와 통신합니다. 사용자에 대해서도 마찬가지입니다. 보안 전문가에게 로드 밸런서는 시간 기반 SQL 주입 공격에서 심각한 문제를 일으킵니다. 그러나 여기서 주요 초점은 IP 스푸핑입니다.

X-Forwarded-For 및 IP 관계

X-Forwarded-For, 개발자 및 미들웨어 간의 관계를 고려하십시오. 예를 들어 애플리케이션 개발자의 작업이 사용자의 잘못된 암호 시도와 같은 모든 활동을 IP 주소와 함께 기록하는 것이라고 가정해 보겠습니다. 처음에 개발자는 자신이 사용하는 프로그래밍 언어가 제공하는 기회와 HTTP 요청이 충족될 때 사용자의 IP 주소를 결정하고 이 데이터를 응용 프로그램에서 계속 사용하려고 시도합니다.

IP 주소는 개발 프로세스 전반에 걸쳐 고정되므로 일반적으로 회사 네트워크의 사용자 컴퓨터는 고정 IP over MAC 주소로 작동하기 때문에 테스트 중에 항상 동일한 주소를 보게 됩니다. 장치는 몇 가지 승인 테스트를 수행합니다. 그러나 이것들에 문제가 있을 것입니다. 테스트 장치는 이 문제를 소프트웨어 개발자에게 전달합니다.

이 단계에서 개발자는 개발 환경에서 컨트롤러를 작성하고 모든 사람이 동일한 IP 주소를 가지므로 응용 프로그램에 원시 형식으로 전송된 HTTP 요청을 볼 수 있습니다. 이렇게 하면 X-Forwarded-For로 작업하게 됩니다.

X-Forwarded-For라는 헤더 정보가 애플리케이션 서버로 전송됩니다. 이 단계에서 소프트웨어 개발자는 로그에 표시되는 로드 밸런서가 아니라 ipconfig로 제어하는 ​​IP 주소를 보게 됩니다. 많은 프로그래머는 다음과 같은 코드 블록으로 이 문제를 해결할 수 있다고 생각합니다.

function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode(',', $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: false;
}


이것만으로는 충분하지 않습니다. 개발자는 들어오는 값이 유효한 IP 주소인지 확인해야 합니다.

위의 모든 것은 개발자가 처리하는 부분에 속했습니다. 그러나 응용 프로그램이 적절하고 안전하게 작동하려면 팀(이론적으로는 함께 작업하지만 실제로는 서로 극단적인 지점에서) 공통 기반을 가진 보안 취약성을 처리하려고 합니다. 이제 로드 밸런서 구성을 담당하는 사람의 관점에서 문제를 살펴보십시오.

시스템 관리자는 HTTP 요청의 데이터를 신뢰할 수 없기 때문에 개발자가 X-Forwarded-For와 같은 정보를 기록한다고 생각할 수 있습니다. 이러한 관리자는 종종 X-Forwarded-For를 전송합니다. 그러나 요청을 보낸 시스템의 TCP 소스 주소도 두 번째 헤더 값으로 전송합니다. True-Client-IP 구조가 이에 대한 좋은 예입니다.

이 모든 것을 종합하면 클라이언트 IP 스푸핑으로 알려진 동일한 문제에 대해 두 개의 서로 다른 장치가 서로 다른 경로를 따릅니다. 그 결과 IP 로깅 및 IP 기반 인증이 작동하지 않는 중요한 문제가 발생합니다.

침투 테스트에서 클라이언트 IP 스푸핑은 어떻게 탐지됩니까?

대부분의 침투 테스터는 보안 검사를 위해 Firefox를 사용합니다. 그들은 모든 HTTP 요청에 대해 간단한 추가 기능인 X-Forwarded-For: 127.0.0.1로 Firefox를 구성합니다. 따라서 모든 침투 테스트에서 이러한 취약점을 탐지할 가능성이 높아집니다. OWASP 체크리스트 에 따라 감사를 수행하면 이러한 취약성을 확인할 수 있습니다. 그러나 X-Forwarded-For 취약점을 탐지하려면 IP 주소 또는 취한 조치를 보여주는 애플리케이션의 모듈이 필요합니다.

X-Forwarded-For 취약점을 해결하는 방법

조직은 모든 ​​소프트웨어 팀과 아웃소싱 회사를 위한 필수 보안 애플리케이션 개발 문서가 필요합니다. 예를 들어 사용자 IP 주소가 필요한 경우 회사는 미리 계획하고 여기에서 사용할 헤더 정보에 대한 규칙을 만들어야 합니다. 그렇지 않으면 다른 팀이 다른 솔루션을 생성합니다. 이러한 상황을 처리하지 못하면 아웃소싱 응용 프로그램이 작동하여 소스 코드를 측정하기 어렵게 됩니다. 일반적으로 회사는 그러한 경로를 따르기를 원하지 않습니다.

그러나이 문제를 해결하려면 다음 F5 규칙을 사용할 수 있습니다.

when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}


이렇게 하면 외부 세계의 HTTP 요청에서 X-Forwarded-For 필드가 제거됩니다. 그런 다음 요청을 보낸 시스템의 IP 주소를 추가하여 요청을 전송합니다. 이렇게 하면 X-Forwarded-For에 따라 작동하는 소프트웨어에 대한 신뢰할 수 있는 목록이 생성됩니다.

요약하면 여기서 가장 큰 목표는 HTTP 요청에 대한 몇 가지 검사를 수행하고 안정적인 환경을 만드는 것입니다. 위의 코드 블록은 이를 위해 사용할 수 있는 좋은 예입니다.

기업용 사이버 보안 프레임워크 및 문서

서로 독립적인 것처럼 보이는 단위들은 사실 전체의 일부입니다. 그렇기 때문에 모든 것이 체계적으로 작동해야 합니다. 사전에 결정된 규칙은 각 유닛 간에 적용되어야 합니다. 이러한 작업 시스템을 채택하지 않으면 X-Forwarded-For 취약점과 같은 많은 문제가 발생할 수 있습니다. 이를 위해 사전에 모든 것을 고려하고 가능한 한 포괄적인 문서를 사용해야 합니다.

그리고 이 대규모 시스템의 모든 단위는 사이버 보안 프레임워크를 채택하고 구현해야 합니다. 시작점은 이러한 프레임워크의 작동 논리를 연구하고 학습하는 것입니다.