방화벽
사설
솔루션 패치 작업을 하러 나가면 서버와 네트워크 구성이 외근지마다 다르다.처음 패치를 다니면서 가장 어려웠던건 설치, 기동이 아닌 이 네트워크 관련 이슈였다.
네트워크 관련 지식이 없다시피 하여 삽질도 여러번 했다.
가장 많이 나는 이슈들은
- WAS가 정상 기동 되었음에도 클라이언트의 컴퓨터에서는 WAS 에 접속 불가
- FCM 과 같은 외부 api 호출 불가
- DNS 문제로 SMTP 를 이용한 메일 발송 불가
- 통합 DB와의 연결 불가
등등....
가장 흔하게 나는 문제는 방화벽으로 인한 문제가 많았고,
경험치가 쌓이면서 솔루션을 패치 할 환경이 다 구성된게 맞는지 방화벽을 확인하는 방법을 익혔다.
방화벽 개념
이미지 출처
미리 정의된 보안 규칙에 기반해 들어오고(Inbound) 나가는(Outbound) 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템
말 그대로 벽이기 때문에 따로 열어주지 않으면 통과할 수 없다.
방화벽은 내부 서버 네트워크 기준으로 Inbound와 Outbound 가 있다.
외부 -> 내부 : Inbound
외부 <- 내부 : Outbound
웹 포트를 외부에서 접근하고자 할 때 방화벽 정책
내부 서버에 443 포트로 서비스되는 웹이 실행되고 있다면,
외부 인터넷망에서 내부의 443 포트로 방화벽이 열려있어야만 접속이 가능하다.
접근하고자 하는 IP가 출발지(Source) 이며 모든 IP에서 접근 가능해야한다면 ANY로 작성한다.
도착지는(Destination) 웹이 실행되고 있는 서버의 IP가 된다.
이때 내부 네트워크 구성에 따라 방화벽을 여러개 거칠 수 있다.
열고자 하는 포트는 TCP/443이 된다.
| 출발지 | 도착지 | 포트 |
|---|---|---|
| ANY | 0.0.0.0 | TCP/443 |
위 방화벽 정책이 적용된다면 아무 인터넷에서 0.0.0.0 서버의 443포트 접근이 가능해진다.
이때 궁금증은 사용자가 WEB 요청 행위는 inbound가 확실하다.
그런데 WEB에서 html을 뱉어주는 행위는 outbound가 아닌가?
과거에는 네트워크 담당자를 통해 inbound가 열려있으면 outbound가 자동으로 열린다고 들어서 모든 방화벽은 다 그런 줄 알았다.
클라우드 인프라를 경험하기 전까지는…..
Stateful vs Stateless 방화벽
방화벽도 stateful 방화벽과 stateless 방화벽으로 구분된다.
간단히 말해 stateful 방화벽은 inbound만 허용하면 요청한 정보를 기억해뒀다가 응답(outbound)을 허용해준다.
stateless 방화벽은 요청 정보를 기억해두지 않기 때문에 outbound 정책도 허용 해줘야지만 응답이 나갈 수 있다.
(근데 작업을 나가보면 모두 Stateful 방화벽을 이용한 듯 하다. 나는 클라우드 플랫폼에서 네트워크를 구축할 때 Stateless 방화벽을 처음 경험했다.)
방화벽 테스트 (firewall-cmd)
방화벽을 직접 테스트 해본다.
사실 로컬 방화벽은 운영환경에선 잘 사용하지 않는다.
firewalld 나 iptables는 로컬 방화벽이긴 하지만 방화벽 개념을 이해하고, 테스트 서버를 구축할 땐 자주 사용되기도 하니 알아두는 게 좋다.
방화벽을 테스트 하기 위해서는 우선 해당 포트의 서비스가 정상적으로 실행 중이어야 한다.
때문에 was를 하나 올려두고 테스트 하면 된다.
우선 netstat -plunt 명령어를 이용해 서비스 중인 포트를 확인한다.
이 중 8080 포트가 올라와 있는 걸 확인 할 수 있다.
firewall-cmd --list-all 명령어를 통해 현재 방화벽 정책을 확인한다.
위에서 ports: ~ 목록을 확인하면 8080/tcp 포트는 현재 허용되지 않았음이 확인된다.
이제 접속하고자 하는 Client PC에서 8080 서비스가 실행 중인 서버의 ip와 포트를 telnet 시도 해보면 연결되지 않는 게 확인된다.
8080 포트의 방화벽을 허용해본다.
firewall-cmd --permanent --zone=public -add-port={포트}/tcp 를 이용해 8080 포트를 추가 한 뒤
firewall-cmd --reload 를 입력해 적용 시킨다.
이후 다시 방화벽 리스트를 조회하면 맨 뒤에 8080/tcp 가 추가된 게 확인된다.
이후 다시 Client PC 에서 telnet을 시도하면 즉시 접속 되는 것을 확인 할 수 있다.
작업 전 네트워크 환경에 문제가 없는지 이를 이용해 확인 하고, 문제가 있으면 telnet이 안된다고 다시 요청을 드림으로써 작업 시 로스를 많이 줄일 수 있었다.