ip차단을 계속 해도 끊임없이 차단이 되면서
아직 제대로 릴리즈도 안한 서버에서만 약 300개 이상의 ip가 차단됐다.
이게 정상인가?.. 싶던 차에 서치를 해보니
위와 같은 글이 나왔다.
우선, 이렇게 차단이 되는 거를 크게 신경쓸 필요가 없다고 하는데
그 이유는
라고 한다.
오히려 로그에 아무런 기록이 남지 않는 게 더 무서운 상황이다.
그만큼 보안이 제대로 작동하지 않을 수 있다는 뜻이기 때문이다.
또한, 80과 443 포트는 외부에서 들어오라고 만든 포트다.
그만큼 노출이 되는 것이고(포트를 변경해도 스캔할 수 있다고 한다)
이런 어뷰징과 해킹시도는 어쩔 수 없는 것이다.
이 글에서 역방향 프록시, 리버스 프록시라는 개념이 계속 나왔다.
예전에 구름톤에서 리버스 프록시를 만들어본 경험이 있는데, 그때는 스프링으로 리버스 프록시를 따로 띄웠던 기억이 있다.
리버스 프록시란?
프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스와 간접적으로 접속하도록 해주는 중계자 역할을 한다.
포워드 프록시는 클라이언트 바로 뒤에 있고, 리버스 프록시는 서버 바로 앞에 있다.
리버스 프록시를 두는 주된 이유는 보안 때문이다. 보통 기업에서는 DMZ라고 해서, 내부네트워크와 외부 네트워크 사이에 구간이 존재한다. 이 구간에는 보통 메일 서버, 웹 서버, FTP 서버 등 외부 서비스를 제공하는 서버가 위치하게 된다.
WAS는 DB서버와 연결되어 있으므로, WAS가 해킹당할 경우 DB서버까지 해킹당할 수 있는 문제가 발생할 수 있다.따라서 리버스 프록시 서버를 DMZ에 두고 실제 서비스 서버는 내부망에 위치시킨 후 서비스 하는 것이다.
이 리버스 프록시를 통해서 로드밸런싱을 수행할 수 있고, 본 서버의 IP를 감출 수 있다는 이점이 있다.
NGINX를 리버스 프록시로 사용하자
Server{
listen 443;
location ~ \.php {
proxy_pass http://127.0.0.1:8000;
}
}이렇게 하면 먼저 요청이 엔진엑스를 먼저 거치고, 스프링 서버로 가게 된다.
이렇게 라우팅을 해줘야 하는 이유가 뭘까?
이렇게 하지 않으면 스프링 서버에서 사용하는 포트를 다 외부에 열어야 한다(만약 외부에서 직접 호출이 필요하다면)
그렇게 되면, 요청이 다 서버로 가면서 이를 처리하는 데(불필요한 요청마저도) 리소스 낭비를 할 수밖에 없게 된다.
처음에 리버스 프록시를 도입하지 않았을 때는 어뷰징 요청이 다 스프링 서버에서 500에러로 처리가 되고, 로그도 계속 남았다. 리버스 프록시를 통해서 1차적으로 정상적이지 않은 요청을 다 걸러내니 지금은 스프링 서버의 로그가 굉장히 깨끗하다.
또 다른 이점
Without a reverse proxy you won't be able to host more than 1 service per port (bye bye 443), and most applications don't even bother with HTTPS support and don't have any functionality to deal with certificates and encryption. That's where a proper http server with SSL support that can act as a reverse proxy, comes in and solves all of that.
Hacker protection. In case your server is feeling down, as you get attacked by many requests, you can just stop the reverse proxy, and still have your private access to the server. Proper logging will also show you what's going on.
One place to see where all the websites exist. In case you have a docker container here, another one there, and a service running without a container, all listening to ports and doing their things, it's easy to forget what you actually have. But in the reverse proxy config you can quickly see what exists, how you can access it, where it resides, etc. All in one place.
우선, 443 포트를 nginx에서 관리하면 여기서 라우팅을 계속 시켜줄 수 있기 때문에, 8000 포트 하나 9000포트하나 10000포트하나 이런식으로 각각 띄워놓은 서비스들을 443포트로 관리할 수 있다.(HTTPS 적용)
또한, 해커의 공격이 있을 때 리버스 프록시와 외부 연결만 끊어두면 우선 잠시 대피가 가능하다. 모든 접근 기록을 한 곳에서 볼 수 있고, 리버스 프록시에 연결된 서비스에 대해서 한 곳에서 모든 걸 관리할 수 있다는 점도 큰 이점이다.
또한, SSL과 관련된 작업을 NGINX에서 하기 때문에 암호화 및 해독에 대한 부하를 백엔드 서버가 아닌 NGINX에서 담당할 수 있다는 점도 이점이다.
참고자료
Reverse Proxy / Forward Proxy 정의 & 차이 정리
