갓.바.조.아

웹서비스를 운영하면 부하 분산을 위해서 nginx 로 reverse proxy를 사용하거나 HAPROXY 같은 로드밸런서를 널리 사용한다. 물론 이러한 부하 분산은 서비스의 안정적인 운영을 위해서 좋은 방법이다. 그런데, nginx 나 HAPROXY가 설치된 서버가 죽거나 해당 서비스가 다운된다면? 그 뒤에서 웹 서버들은 멀쩡히 돌아가고 있는데, 안정적인 운영을 위해 올려놓은 녀석 하나 때문에 모든 서비스가 불능에 빠져버리는 결과를 초래한다. 로드밸런서 뿐 아니라 라우터와 같이 통신을 위해 꼭 통과해야하는 지점도 불능이 되면, 해당 지점의 전후가 살아 있더라도 전체적인 불능 상태를 초래할 수 있다. 위의 그림과 같이 한 지점이 동작하지 않으면 전체를 불능에 빠트릴 수 있는 요소가 될 수 있는 지점을 sp..

https://springboot.cloud/21 에서는 컴파일을 통해서 Apache HTTP 웹서버를 설치하는 방법을 알아보았다. 이전 게시물에서 OpenSSL 을 빌드할 때 아래와 같이 빌드했었다. ./config --prefix=/tmp/apache-install/openssl-for-httpd -fPIC shared make make install 맨 뒤에 -fPIC shared 옵션이 붙은 것을 볼 수 있다. -fPIC 옵션은 OpenSSL이 위치독립코드(position independent code)로 동작하도록 빌드한다는 것이고 shared 옵션은 OpenSSL이 shared object에 의존성을 가지도록 빌드한다는 것이다. PIC에 대해서는 https://ko.wikipedia.org/w..

웹서버를 운영하다보면 주기적으로 웹서버나 WAS 등의 보안 취약점 패치 권고가 날아온다. 그러면 작업 계획을 세우고 버전업을 해야하는데, 아무래도 운영 서버들은 망분리가 되어 있는 경우가 많아서 직접 컴파일을 해서 설치해야 하는 경우가 있다. 아파치 웹서버도 그 중 하나인데, 아파치 웹서버 2.2 에서 2.4로 버전업을 할 때 바뀐 설정값을 일일이 체크하지 못 해서 힘들었던 경험도 있고해서 아파치 웹서버는 개인적으로 좀 아픈 손가락이다. 이번에도 아파치 2.4.38 까지 보안 취약점이 발견되었다고 해서 2.4.39 로 패치를 조만간 할 계획을 잡아놨는데 간만에 연습도 하고 준비도 해 둘겸 Apache httpd를 컴파일로 설치하는 법을 정리 해 보려 한다. 5G가 개통하고 초연결 시대가 왔다는데 인터넷 ..

https://springboot.cloud/19 에서는 내부망 혹은 사설인증서를 통해 TLS/SSL을 구현할 경우 CA를 신뢰할 수 없어 검증을 회피하는 로직을 적어보았다. 이 경우는 HTTPS를 통해 전달 과정에서 암호화는 유지가 되지만, 이것이 신뢰할 수 있는지 없는지는 신경을 쓰지 않는 방법이다. 반대로, 클라이언트와 서버간에 매칭이 되는 인증서를 소유하고 있지 않다면 서로 접근을 아예 거부하는 방법이 필요할 수도 있다. 뭔가 정보 수집을 하는 서버-에이전트간에 인증된 에이전트에서만 정보를 받아들이게 한다던가 뭐 그런 경우로 쓰고 있는데, 간단하게 구현을 할 때는 HTTP HEADER에 AUTH에 관한 부분을 삽입해서 그걸 체크하거나, 좀 더 복잡한 구현이 필요하다면 해당 헤더에 들어가는 값을 주..

회사의 네트워크 환경이 프록시를 통해서 외부로 나가는 환경이며, 내부망으로 구성된 환경이 많다보니 TLS/SSL과 관련하여 꼭 self-signed 인증서와 관련된 문제를 마주치게 된다. proxy를 통해서 외부와 접속할 경우에는 proxy에서 SSL 인증서가 회사의 사설 인증서로 교체되는 것이 원인이며 내부에서 필요에 의해 SSL 연결을 지원해야 할 경우에는, 내부에서는 self-signed 인증서를 발급하여 사용하기 때문이다. 어떤 툴을 쓰거나, 아니면 개발을 할 때도 꼭 시작은 이 문제를 짚고 넘어가는 것이 그 다음인데 오늘은 Spring 에서 마주치는 경우를 다뤄보려 한다. Spring4 까지 사용하던 RestTemplate는 HTTP(s)요청을 날리기 위해 JDK HttpURLConnection..