[공통] LoadBalancer와 WAF

클라우드 상품은 CSP 사에서 제공하는 그대로 사용해야 하는 장점이자 단점이 있다.

 

모든 CSP가 이와 같은 문제를 갖고 있지 않을 수 있고 이것을 문제라고 생각해야 하는지도 의문이지만

 

WAF와 LoadBalancer 사이에 묘한 문제가 있다.

 

우선 우리는 CSP 사에서 제공하고있는 상품들은 보안상의 이유로 구성의 위치를 정확하게 알 수는 없다.

 

단지 Legacy 방식에서 유사할 것이라고 생각하거나 기타 여러 명령어 또는 네트워크 흐름을 통해서 유추할 뿐이다.

 

이러한 이유로 앞서 말한 것 처럼 지금 말하고자 하는 WAF 와 LoadBalancer 의 특이점이 모든 CSP에 공통으로 적용되는 것은 아니다.

 

웹 서버는 보통 공인 IP를 사용하고 그 공인 IP는 domain 으로 사용하게 된다.

 

이때 웹에 가용성 및 보안성을 높이기 위해 LoadBalancer 나 WAF를 사용하게 된다.

 

이 경우 LB와 WAF의 위치에 대해서 2가지 가능성이 생긴다.

 

1. LB가 WAF 보다 앞에 있을 때

2. WAF 가 LB 보다 앞에 있을 때

LB와 WAF의 위치에 대한 구성도

1번의 경우 그림에서 처럼 1-1의 경우가 있지만 이럴 경우 LB를 사용하려는 목적이 없기 때문에 의미가 없는 구성이다.

 

1번으로 다시 돌아가보면 LB의 목적상 분배를 해야하는데 WAF로 분배를 하게 된다.

 

이 경우 WAF의 이중화 구성이라는 점에서 장점이 될 수 있겠다.

 

2번의 경우 WAF가 먼저 받고 LB에서 웹 서버로의 분배를 하는 구성이다.

 

1과 1-1 을 통해서 LB가 WAF 보다 앞에 있는 구성은 그리 일반적인 구성이 아니라는걸 통해 보통의 CSP 에서는

 

WAF가 LB 보다 앞에 있을 것이라고 예상해볼 수 있다.

 

설명에는 빠져있지만 웹 서버에서 사용하고자 하였던 공인 IP는 1번에서는 LB에서 사용하고, 2번의 경우에선 WAF에서 사용하게 된다.

 

예를들어 공인 IP가 2.2.2.2 가 test222.com 이라는 도메인으로 연결되어 있다면

1번의 경우 LB가 공인 IP 2.2.2.2 가 되며 test222.com 으로 접속될 때 LB가 먼저 받게 된다.

2번의 경우 WAF의 공인 IP는 2.2.2.2 가 되며 test222.com 으로 접속될 때 WAF가 먼저 받게 된다.

 

LB에는 부하분산을 하는 몇 가지 알고리즘이 존재 하는데 그중에 src IP hash 알고리즘에 대해서 다시 한번 설명하고자 한다.

 

웹 서버는 http 통신을 한다 http 는 대표적인 비연결성을 갖는다. 

 

비연결성이란 통신하고 있는 데이터가 지속되지 않음을 의미한다.

 

이러한 데이터의 지속을 유지하기 위해서 사용하는 기술이 쿠키나 세션 이다.

 

이러한 특징으로 인해 LB의 부하분산 알고리즘도 그 특징에 따라 장단점이 되어 준다.

 

대표적인 알고리즘인 Round Robin 은 쿠키나 세션에 크게 영향을 받지 않아도 되는 말 그대로 부하분산[2개의 웹 서버에 연결할 때마다 한번씩 반복하며 연결하는] 에만 목적을 둬도 사용할 수 있다.

 

src IP hash 알고리즘을 사용하게 된다면 사용자의 IP가 변경되지 않는 2개의 웹 서버중에 한개의 웹 서버[사용자가 하나의 웹 서버로만 접속을 해야하는 연결]로만 사용하게 된다.

 

이때 IP 정보가 다음과 같다고 가정해보자.

사용자 11.22.33.44 

도메인 test222.com 2.2.2.2

WAF의 공인 IP 2.2.2.2

WAF의 내부 IP 172.25.0.5

LB의 내부 IP 172.25.1.6

웹 서버 1 내부 IP 172.25.3.2

웹 서버 2 내부 IP 172.25.3.3

 

LB가 Round Robin 알고리즘을 사용할 경우에는 LB에 의해서 web01과 web02 로 한번씩 분산이 이루어진다.

 

LB가 출발지 IP에 대한 hash 값을 토대로 분산을 하게 될때 hash의 동일한 값은 항상 동일한 hash 값을 같는 다는 특징으로 인해

 

동일한 IP는 항상 동일한 서버로 분산이 된다.

LB가 src IP hash 알고리즘을 갖고 있을 경우 흐름도

그런데 이때 특이점이 생긴다.

 

WAF가 아에 없을 경우에는 전혀 문제가 되지 않는데, 보안상 WAF를 이용하게 될 때 WAF의 내부 IP 172.25.0.5가 항상 LB와 통신을 하게 된다는 점이다.

 

이렇게되면 172.25.0.5 IP의 hash 값은 항상 같은 hash 값을 갖게 될 것이고 이에 따라 항상 고정된 서버로만 분산이 된다. 사실 분산이라는 말을 쓰기도 민망한 일이 발생한다.

 

이러한 구성을 의도한 것이라면(LB의 목적을 부하분산이 아닌 고가용성을 위한 HA로 쓰고자 한것이 맞다면[의도와 다르게 우회하여 HA 기능을 사용하는]) 쓸수도 있겠지만... 쩜쩜쩜 을 남긴다.

 

또한 이 경우 웹 로그 또한 LB의 내부 IP만 남게되어 실제 사용자의 IP를 확인할 수 없는 문제가 존재한다.

 

이를 해결하기 위해서는 X-forwarded-For(XFF) 를 통해서 해결할 수 있다.

 

이는 다음에 이야기 해보자.