많은 개발자들이 SSH를 단순히 원격 터미널 접속 용도로만 사용한다. 그렇지만 SSH는 기본적인 접속 기능 외에도 'SSH 포트 포워딩' 또는 'SSH 터널링 기능' 이라고 불리는 것을 제공한다 (두 용어는 같은 것을 의미한다). 터널링이라는 단어는 보통 VXLAN의 Overlay Network에서 물리적 토폴로지를 논리적으로 나눌 때에나 등장하는 단어일 터인데, 신기하게도 SSH 에서도 그와 비슷한 기능을 사용할 수 있다.
단적으로 말하자면, SSH 터널링은'프록시'와 비슷한 역할을 하며, SSH의 특징 상 SSH 터널링을 통해 전달되는 데이터는모두 암호화된다. 그렇다면 SSH 터널링은무엇을 위한 프록시인가, 를 짚고 넘어가야 할 것 같다
SSH 포트 포워딩을 사용할 수 있는 단적인 예를 들어 보자. 나는 A 서버에서 80 포트로 바인딩 된 서비스에 접근할 필요가 있다. 그러나 보안 상의 이유로A 서버의 Firewall에서 SSH (22 포트) 외의 포트는 전부 차단된 상태이다.당연히 Firewall은 80 포트를 개방하지 않았기 때문에 해당 서비스로 접근이 불가능하다.
이 때, SSH 포트포워딩을 사용하면 SSH 터널링을 통해 웹 서버에 접근할 수 있다. 80 포트를 사용하는 서비스와 SSH 서버를 엮은 뒤 SSH 터널링을 생성하고, 사용자가 서비스를 요청하면 해당 요청은 SSH 서버로 전송된 뒤 A 서버 내부에서 다시 포워딩된다.
일단 사용자와 서버 간의 SSH 터널링이 수립되고 나면 데이터의 요청 및 반환은 모두 SSH 서버를 통해 일어나므로 서버의 80 포트로 접근할 필요가 없다. 따라서 SSH 서버는 터널링을 통해 데이터를 주고받을 수 있게 해주는 일종의 프록시의 역할을 수행하게 된다.
.... 설명은 이렇게 했지만 SSH 터널이라는 개념 자체는 원래 SSH 연결에서 사용되는 것이며, SSH 클라이언트와 SSH 서버 사이의 연결 통로 자체를 SSH 터널이라고 부른다. 즉,SSH 연결 수립 뒤 외부로부터 데이터를 보호할 수 있는 일종의 연결 통로를 터널이라고 부른다고 한다. SSH 터널링은 Secure Shell 상의 데이터뿐만 아니라기타 애플리케이션의 데이터또한 SSH 터널을 이용하게 함으로써 암호화 등과 같은 SSH의 장점을 활용할 수 있는 방법이라고 보면 된다. [4]
그러나 잘만 악용하면 나쁜 의도로 사용할 수도 있기 때문에 공격자의 관점에서 SSH 포트 포워딩을 바라볼 필요도 있을 것이다. 보안 측면에서도 SSH 터널링을 생각해 볼 필요가 있다는 이야기이다.
2. SSH 포트 포워딩 사용하기
SSH 포트 포워딩에는 크게 2가지 종류가 있다. Local, Remote 모드를 사용할 수 있고, Dynamic이라는 것도 있는 듯 하지만 지금은 다루지 않기로 했다.
2.1 서버 구성
당연하겠지만, SSH를 기반으로 하기 때문에 SSH Client와 SSH Server로 사용할 서버 각각 1대가 필요하다. VM을 사용해 아래와 같이 구성하였다.
테스트를 위해 SSH 서버에서는 Nginx 웹 서버를 80 포트와 바인딩해 컨테이너로 생성해 놓았다. SSH 포트 포워딩을 통해 SSH Client에서 해당 Nginx 웹 서버로 접근할 것이다.
2.2. Local 포트 포워딩
SSH 포트 포워딩은 연결을 수립하는 주체가 누구냐에 따라 Local과 Remote로 구분할 수 있다. Local은 가장 이해하기 쉽고 직관적인 경우로, 늘 하던 것처럼 SSH Client -> SSH Server로 연결을 수립하는 경우이다. 이해를 위해 간단한 예시를 통해 Local 포트 포워딩을 사용해보자.
SSH Client는 SSH Server에 SSH로 접속할 수 있다. 그러나 Nginx 서버는127.0.0.1:80으로 바인딩되어 있어 외부에서 접근할 수 없는 상황이다. SSH Client 에서 Nginx에 접근할 수 있도록 SSH 터널링 연결을 생성한다.
가장 많이 헷갈리는 것이 SSH 포트 포워딩 시 '무엇을 어떻게 입력할지' 인데, 위 그림으로 이해할 수 있다. SSH Client에서ssh -L [로컬에서 사용할 포트]:[최종적으로 접근할 곳] [SSH Server 주소]형식으로 입력한다. SSH 터널이 생성된 뒤에는 [로컬에서 사용할 포트] 를 이용해 [최종적으로 접근할 곳] 에 접근할 수 있다.
직접 해보자. 가장 먼저, SSH Server 에서는 Nginx 서버시 127.0.0.1:80 으로 바인딩되어 실행되고 있다.
SSH Client에서 아래의 명령어를 입력해 SSH 포트 포워딩을 실행한다. SSH Server의 주소는 192.168.1.201 이고, 해당 SSH Server에서 접근할 Endpoint는 127.0.0.1:80 (Nginx Server) 이며, SSH Client의 8585 포트로 해당 Endpoint에 접근할 것이다.
평상시와 똑같이 SSH 접속에 성공하였지만, SSH 터널이 생성된 상태이다. SSH Client에서 새로운 터미널을 생성한 뒤, 로컬호스트의 8585로 요청을 전송해보자.
[root@ssh-client ~] curl localhost:8585-v
...
< HTTP/1.1200 OK
< Server: nginx/1.15.3
< Date: Sun, 23 Sep 201809:06:43 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Tue, 28 Aug 201813:32:13 GMT
< Connection: keep-alive
< ETag: "5b854edd-264"
< Accept-Ranges: bytes
요청이 제대로 전송되었고 응답 또한 수신하였다. SSH 터널링은 수립된 SSH 연결을 통해 구성되기 때문에 위에서 접속한 SSH 연결을 끊으면 SSH 터널 또한 종료된다.
2.3 Remote 포트 포워딩
Remote 포트 포워딩은SSH Server -> SSH Client로 연결을 수립해 SSH 터널을 생성한다. 연결을 생성하는 주체가 SSH Server이기 때문에 SSH Server의 22 포트를 Firewall에서 개방해 둘 필요가 없다. 이는 역으로 말하자면22 포트를 포함해 모든 포트가 Firewall에 의해 막혀 있는 상태이더라도, SSH 터널을 생성해 SSH Server에서 실행 중인 서비스, 또는 SSH Server가 접근 가능한 네트워크에 접속할 수 있다는 의미가 된다.
간단한 예시를 들어보자.외부로 나가는 트래픽은 허용되지만 내부로 들어오는 트래픽은Firewall에 의해 전부 차단되는 상황을 가정한다. 물론 SSH 또한 사용할 수 없는 상황이다.
이 때 Remote 포트 포워딩을 SSH Server에서 사용한다면 내부 네트워크에 쉽게 접속할 수 있다. Outbound 트래픽은 허용되는 상황이므로 SSH Server -> SSH Client로 SSH 터널(SSH 연결)을 생성한 뒤, SSH Client는 SSH Server가 접근 가능한 네트워크에 접속해 데이터를 주고 받는 방식이다.
어찌 보면 보안상으로 취약하다고 말할 수 있다. Firewall 단에서 모든 포트로 들어오는 Inbound 트래픽을 차단해도 Outbound 트래픽을 통해 내부 네트워크에 자유롭게 접근할 수 있기 때문이다. 따라서 SSH 연결이라고 해서 무조건 Trust한 패킷만 오고 간다고 볼 수는 없다.
어쨌든, 사용해보는 것이 가장 빠르게 이해할 수 있는 지름길이다.
이번에는 SSH Server 에서ssh -R [SSH Client가 사용할 포트]:[최종 목적지] [SSH Client 주소]와 같은 형식으로 SSH 포트 포워딩을 실행한다. 당연하지만, SSH Client에서도 SSH 데몬이 실행 중이여야만 한다. SSH Server에서 SSH Client로 SSH 연결을 수립하기 때문이다.
Last login: Sun Sep 23 05:30:37 2018 from ssh-client
[root@ssh-client ~]#
SSH Client 측에서 로컬 호스트의 8585로 접근하면 127.0.0.1:80에 접근할 수 있다.
[root@ssh-client ~] curl localhost:8585-v
....
> User-Agent: curl/7.29.0
> Host: localhost:8585
> Accept: */*
>
< HTTP/1.1200 OK
< Server: nginx/1.15.3
< Date: Sun, 23 Sep 201809:40:40 GMT
....
3. 장단점?
SSH를 기반으로 하다 보니 보안, 데이터 압축, 암호화 등은 알아서 해줄 뿐만 아니라 간단하게 데이터를 주고 받을때는 편리하게 프록시 대신 사용할 수 있다는 장점이 있다. 그러나 대용량 데이터를 주고 받을때는 속도가 느려질 수 있다는 단점이 있다. 아래와 같이 iperf로 간단히 측정해보니 전송 속도가 약 두 배 정도 차이가 났다. (설마 이걸로 뭔가 대용량 데이터를 처리하는 사람은 없겠지...) 또한 TCP만 지원한다는 한계점도 있다.
1
2
3
4
5
6
[ 4] local127.0.0.1 port 5001 connected with 127.0.0.1 port 50764
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 1.34 GBytes 1.15 Gbits/sec
[ 4] local192.168.1.201 port 5001 connected with 192.168.1.200 port 43862
1번의 경우 개발시에 웹 서버를 별도로 셋팅하기 번거로울 경우 쉽게 사용할 수 있는 방법이고, 실제로 흔히 사용한다. 그러나 편의상 사용되며 성능과는 거리가 멀다. 따라서 여기서는 더 이상 언급하지 않기로 한다.
2번의 경우 10 여년 이상 사용해온 전통적인 방식이며LAMP 스택(Linux, Apache, MySQL, PHP)이란 이름으로 지금의 아파치와 PHP 를 있게 한 장본인이다.
3번의 경우 PHP-FPM 과 함께 최근에 주로 쓰이는 방식인데, FPM 은 FastCGI Process Manager 의 약자이며 PHP-FPM 은 PHP FastCGI 의 대안 구현으로 2010년 PHP 코어에 팩키징되고 2011년 실험적인(experiment) 딱지를 뗌으로써 사실상 PHP FastCGI 표준 구현으로 자리 잡았다. 특히 아파치에 비해 월등한 성능을 보이는 Nginx 와 손쉽게 연동되며 최근LEMP 스택(Linux, Nginx, PHP, MySQL/MariaDB)이란 이름으로 새로운 트렌드를 주도하고 있다.
그렇다면 3번 구현은 과연 새로운 트렌드로써 월등한 성능을 보여주고 있는지 직접 확인해보도록 한다.
테스트
테스트 서버의 사양은 아래와 같다.
Intel Xeon E312xx (Sandy Bridge) x 2
4G RAM
OS: Ubuntu 14.04
Apache, Nginx 모두 apt 를 이용한 기본 설치, 설정 변경 없음
요즘 기준으로 보면 웹 서버로 쓸 수 있는 거의 최소 사양인데 테스트 PHP 코드가 과연 얼만큼의 성능을 보여주는지 확인해본다.
성능
코드는 간단한 HTML 을 변수에 삽입한 다음 템플릿을 구성해서 내려주는 형태이며, 별도의 외부 서버나 DB 호출은 하지 않는다.
carrotw는 사내에서 만든 브라우저로 직접 부하 테스트가 가능한 성능 테스트 도구(외부에 공개되지 않은 사내 시스템이라 부득이하게 주소를 가림)다. 전통적인 쓰레드 방식으로 동작하며 여기서는 쓰레드를 200개 주어 최대 성능을 측정했다. 200개 쓰레드가 동시에 요청을 보내 응답을 받아오는 초당 평균 횟수/속도를 측정하는 방식이며 10초간 측정한 결과는 약 7,600 TPS 에, 평균 응답속도 25ms 수준이다.
아주 좋은 성능의 서버가 아님에도 불구하고 초당 7,600회 처리라는 준수한 성능을 보여준다. 그렇다면 과연 아파치는 Nginx 에 비해 어느 정도 성능이 나오는지 확인해본다.
동일한 200개 쓰레드에서 7,100 TPS, 27ms 가 나왔다. 이를 표로 정리하면 아래와 같다.
방식TPS응답 속도
Nginx w/ FastCGI
7,600 TPS
25ms
Apache w/ mod_php
7,100 TPS
27ms
단순 TPS 만 비교하면 Nginx 가 아파치 보다 약 7% 정도 성능이 더 좋은것으로 나온다. CSS, JS 등의 Static 파일이 압도적인 성능을 보여주는 것에 비하면 성능이 약간 높긴 하나 다소 실망스런 결과다.
따라서 CGI(PHP) 용도로 아파치나 Nginx 나 별 차이가 없다는 결론에 이른다. 그러나 전통적인 CGI(Traditional CGI) 방식과는 압도적인 성능 차이가 있음에 유의해야 한다. 아래는 여러가지 언어로 전통적인 CGI 를 구현하고 아파치 cgi-bin 에서 구동한 결과다.
방식TPS코드
Bash
870 TPS
Python
190 TPS
C
1,580 TPS
C++
1,100 TPS
PHP
250 TPS
예상했듯이 C 가 가장 빠르고 그 다음 C++ > Bash > PHP > Python 순이다. 전통적인 CGI 방식은 프로세스를 직접 실행한 결과를 보여주는 방식이기 때문에 미리 바이너리를 만들고 사이즈가 가장 작은 C 가 가장 빠르다.
그러나 이 역시도 mod_php 에 비하면 1/7 수준에 불과하다. 따라서 특수한 경우를 제외하곤 굳이 C 로 전통적인 CGI 를 만들어야 할 이유가 전혀 없다. 재밌는 점은 PHP 의 경우인데, 전통적인 CGI 에서는 250 TPS 밖에 나오지 않지만 mod_php/FastCGI 에서 돌리면 7,100 ~ 7,600 TPS 가 나온다. 거의 30배 이상 성능 차이가 난다.
결론
Static 파일과 달리 CGI(PHP) 방식에서 Apache w/ mod_php 와 Nginx w/ FastCGI 의 성능 차이는 크지 않다. 따라서 각자에게 편한 웹 서버를 사용해도 무방하다. 그러나 전통적인 CGI 방식과는 성능 차이가 매우 크므로 특수한 경우를 제외하곤 전통적인 CGI 방식은 사용하지 않는게 좋다.
- Tomcat 서버는 본연의 임무인 서블릿 컨테이너의 역할만 하고, Apache HTTP Server는 웹서버의 역할을 하도록 각각의 기능을 분리하기 위해 연동을 할 수 있다.
- Apache HTTP Server에서 제공하는 편리한 기능을 사용하기 위해서 연동을 할수 있다.
- 대규모 사용자가 사용하는 시스템을 구축할 때 웹 서버인 아파치와 연동을 하면 부하 분산의 효과를 가질 수 있다. mod_jk의 Load Balancing과 FailOver 기능을 사용하여 안정적으로 운영 할 수 있다.
- 아파치 내에서만 설정할 수 있는 부분이 있고, 아파치에서 제공하는 유용한 모듈들을 톰캣에서 사용할 수 없기 때문이다.
▶ 아파치 톰캣 연동하는 방법들 (참고)
Apache httpd web server 와 tomcat 을 연계하는 방법은 세 가지가 있다.
예전부터 많이 쓰던 방법은 tomcat connector(mod_jk)를 사용하는 방법이고 다른 하나는 mod_proxy를 사용하여 reverse proxy 기능을 사용하는 방법, 마지막은mod_proxy_ajp 를 사용하여 AJP Protocol을 reverse proxy 로 사용하는 방법이다.
mod_proxy 가 mod_jk 에 비해 설정이 간편하고 AJP 같은 특정 WAS 의존적인 프로토콜을 사용하지 않으므로 성능이 더 좋다고 하지만 mod_jk 가 오랫동안 써왔고 친숙해서 mod_jk 를 많이 사용하는 편
▶ 연동원리
아파치와 톰캣이 연동하기 위해선 AJP를 통해 서로 통신을 하여야 한다.
AJP란 아파치가 웹서버와 외부 서비스(톰캣 등)과 연동하기 위해 정한 규약(프로토콜) 이다.
아파치는 이를 사용하여 80포트로 들어오는 요청은 자신이 받고, 이 요청중 서블릿을 필요로 하는 요청은 톰캣에 접속하여 처리한다.
1) 아파치 웹서버의 httpd.conf 에 톰캣 연동을 위한 설정을 추가하고 톰캣에서 처리할 요청을 지정
2) 사용자의 브라우저는 아파치 웹서버(보통 80포트)에 접속해 요청
3) 아파치 웹서버는 사용자의 요청이 톰캣에서 처리하도록 지정된 요청인지 확인. 요청을 톰캣에서 처리해야 하는 경우
아파치 웹서버는 톰캣의 AJP포트(보통 8009포트)에 접속해 요청을 전달
4) 톰캣은 아파치 웹서버로부터 요청을 받아 처리한 후, 처리 결과를 아파치 웹서버에 되돌려줌
# cd /usr/local/src/tomcat-connectors-1.2.42-src/native/apache-2.0/
# cp mod_jk.so /usr/local/apache2/modules/
- 설정
# vi /etc/httpd/conf/httpd.conf
vi에디터 창에서 / 를 누르고 LoadModule을 찾아(엔터후 n버튼을 누르면 다음찾기가 된다.) 그 아래쪽에 다음의 내용을 추가합니다.
VirtualHost 쪽은 아직 못해봤다. 참고.
LoadModule jk_module modules/mod_jk.so
<VirtualHost *:80>
ServerName localhost
# 확장자 jsp, json, xml, do를 가진 경로는 woker tomcat으로 연결하는 구문.
JkMount /*.jsp tomcat
JkMount /*.json tomcat
JkMount /*.xml tomcat
JkMount /*.do tomcat
</VirtualHost>
<ifModule jk_module>
# 워커 설정파일 위치
JkWorkersFile conf/workers.properties
# 로그 위치
JkLogFile logs/mod_jk.log
# 로그레벨 설정
JkLogLevel info
# 로그 포맷에 사용할 시간 형식을 지정한다.
JkLogStampFormat "[%y %m %d %H:%M:%S] "
# Our JK shared memory file
JkShmFile logs/mod_jk.shm
JkMountFile conf/uriworkermap.properties
</ifModule>
# vi /usr/local/apache2/conf/workers.properties
다음 내용 추가
worker.list=instance1,instance2
worker.instance1.port=8009
worker.instance1.host=localhost
worker.instance1.type=ajp13
worker.instance1.lbfactor=1
worker.instance2.port=8109
worker.instance2.host=localhost
worker.instance2.type=ajp13
worker.instance2.lbfactor=1
worker 이름: worker 이름은 정하기 나름이지만 각각 뒷단의 Tomcat 서버를 구분할 수 있는 이름이여야 한다. 이 worker 이름은 나중에 로드밸런싱을 할때에 Tomcat 에도 적용되어지는 이름이기에 잘 설정해야 한다.
worker port: 여기서 말하는 port 는 뒷단 Tomcat 서버의 AJP 포트를 말한다.
worker type: 이건 ajp13 으로 설정하면 된다.
worker lbfactor: 부하분산을 위한 설정으로 뒷단 Tomcat 서버들에 연결 무게를 설정해준다.
▶ 로드밸런스 설정
앞선 작업들은 로드밸런스 설정과는 관계가 없다. 로드밸런스라고 하면 instance1 인스턴스가 응답하지 않을 경우에 다른 서버들이 그 역활을 대신하는 것을 말한다. 이를 위해서는 woker 설정을 변경해주고 urlworkermap 설정을 추가해주어야 한다.
# vim /usr/local/apache2/conf/uriworkermap.properties
다음 내용 추가
/*=balancer
로드밸런스는 특정 인스턴스가 죽었을 경우에 다른 서버가 그 역활을 대신하는 것이다. 이를 위해서 로드밸런스 역활을 위한 worker 이름을 정의하고 그 worker 에 로드밸런스를 위한 worker 이름을 정의해주면 된다. 기존의 worker 파일에 다음과 같이 로드밸런스 내용을 추가하면 된다.
