'SSL'에 해당하는 글 4건

Tomcat 80 to 443 port

Server/AWS 2018. 8. 8. 12:42

미션. http://mydomain.com -> https://mydomain.com


간만에 톰캣 단독 서버를 만들면서 포트 포워딩에 대한 노가다를 해보았다.

톰캣은 기본적으로 8080 포트와 8443(SSL) 포트를 사용하기 때문에 대부분의 경우 80 포트나 443 포트로 변경하기를 원할 것이다.

도커 등의 각종 컨테이너 서비스를 사용하면 포트 걱정할 일은 없지만, 포트 포워딩이 아닌 포트 변경이 가능한 방법을 찾아봤다.


> server.xml 


<Connector port="8080" protocol="HTTP/1.1" ... redirectPort="8443" ...
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" ...
cs


톰캣이 실행중일 때 netstat 로 listen 중인 포트를 확인해 보면 8080, 8443 포트가 열려 있는 것을 확인할 수 있다.

server.xml 파일에 설정되어 있는 포트 때문인데, 이 포트들을 원하는 포트로 변경한다고 해서 모두 동작하지는 않는다.

1024 이하의 TCP/UDP 포트(well-known) 로 변경하려 할 경우 root 권한을 필요로 하기 때문에 기본 세팅으로는 well-known 포트로 변경 할 수 없다.

(이를 가능하게 하는 것이 authbind 이다.)


이러한 이유로 우리는 tomcat 유저로 톰캣을 실행시킬 경우 포트를 80 이나 443 등으로 바꾸려는 무모한 짓으로 시간을 낭비하지 말아야 한다.

이를 확인하려면 tomcat8.conf 파일의 TOMCAT_USER 를 root 로 설정하면 server.xml 에 설정한 대로 포트가 변경되는 것을 확인할 수 있다.

하지만 운용시 생성되는 모든 파일, 배포 디렉토리 및 log 파일까지 모두 root 로 설정되기 때문에 일반 유저로는 접근할 수 없어 좋은 방법이 될 수 없다.

그 어떤 서비스도 해당 그룹과 권한을 설정하여 사용하지, root 로 실행하라고 권하는 서비스는 없다.


결국 깔끔한 방법은 포트 포워딩이다.



80->8080, 443->8443 포트 포워딩


$ sudo vi /etc/init.d/iptables 
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 8443
 
$ sudo /etc/init.d/iptables restart
cs


이렇게 iptables 로 포트 포워딩을 하면 80 과 443 을 사용할 수 있다.


http://mydomain.com (80)   -> http://mydomain.com (8080)

https://mydomain.com (443) -> https://mydomain.com (8443)


iptables 대신 firewalld 를 사용할 수도 있다.


$ sudo firewall-cmd --zone=public --add-forward-port=port=80:proto=tcp:toport=8080 --permanent
$ sudo firewall-cmd --zone=public --add-forward-port=port=443:proto=tcp:toport=8443 --permanent $ sudo firewall-cmd --reload
cs



80->443 포트 포워딩


이 상태에서 80 포트으로 접속했을 때 무조건 443 포트로 포워딩하려면 web.xml 파일을 수정한다.


$ sudo /etc/tomcat8/web.xml
      ...
      <security-constraint>
            <web-resource-collection>
                  <web-resource-name>Automatic SSL Forward</web-resource-name>
                  <url-pattern>/*</url-pattern>
            </web-resource-collection>
            <user-data-constraint>
                  <transport-guarantee>
                        CONFIDENTIAL
                  </transport-guarantee>
            </user-data-constraint>
      </security-constraint>
 
</web-app>
cs



http://mydomain.com -> https://mydomain.com:8443


여기서 server.xml 파일의 redirectPort 를 443 으로 바꿔주면,


http://mydomain.com -> https://mydomain.com


firewalld 를 사용할 때는 http 접속시 https 로 자동변경 되지 않아 server.xml 파일에 추가 설정이 필요했다.


<Connector port="8080" redirectPort="443" ... />
<Connector port="8443" proxyPort="443" ... />
cs



8443 포트 막기


마지막으로 https://mydomain.com:8443 같은 식의 8443 포트로 직접 접근을 막기 위해 iptables 를 한번 더 수정한다.


$ sudo vi /etc/init.d/iptables 
iptables -A PREROUTING -t mangle -p tcp --dport 8443 -j DROP
 
$ sudo /etc/init.d/iptables restart
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

인증서 오류

Daily/Prog 2017. 8. 7. 23:31


아래 게시물은 2016년 정도부터 각 인증서 발급 기관별로 기능을 추가하여 현재는 모두 정상적으로 작동함을 다시 알립니다.^^

- 2019년 1월 16일



일반적으로 http 통신을 이용하는 도메인은, http://www.example.com 과 같은 형식으로 나타낼 수 있다. 

설정에 따라 example.com 으로만 접속해도 같은 결과를 볼 수도 있다.

하지만 SSL/TLS 보안서버를 구축하고 나면 https 통신을 해야 하고, http 요청 또한 https 로 전환을 해주어야 한다.


https://www.example.com 만을 필요로 하는 나를 힘들게 한건 바로 https://example.com 과 같은 식의 URL 요청이다.

대부분 *.example.com 같은 도메인으로 인증서를 발급하기 때문에, 2차 도메인을 제외한 example.com 을 별도로 구매하지 않았다면

https://example.com 식의 URL 로 접근할 경우, 보안 인증서에 문제가 있다는 브라우저 경고를 만나뵐 수 있다.

서버로의 진입점에서 바로 경고가 발생한 것이므로, 소스에서 자바스크립트나 meta 태그, 각종 프레임워크 등을 이용한 리다이렉션 하는 등의 뻘짓은 무의미하다.


내가 한 회심의 뻘짓은 바로 rewrite 를 이용한 것이었다. 안될 줄 알았지만 혹시나 한번 해봤다ㅋ

Apache 에서는 많이 사용해 봤지만 Tomcat 에서는 처음이라 기록해 본다.


우선 server.xml 의 <host> 나 context.xml 파일에 아래 지시자를 넣는다.


<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />
cs


그리고 어플리케이션의 /WEB-INF 디렉토리 안에 rewrite.config 파일을 넣고 rewrite 명령어들을 이용해서 리다이렉션을 구성한다.


RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}$1 [R=301,L]
cs


짠~

이것은 요청 URL 이 example.~~~ 로 시작한다면 앞에 https://www. 을 URL 앞에 붙여 리다이렉트 시키는 명령문이다.

따라할 필요는 없다. 어짜피 경고는 그대로 나타나니까. 더 앞 단에 뭔가를 해줘야 하는데 난 모르겠다.

위의 오류를 발생시키지 않기 위한 방법?? 그냥 깔끔하게 돈 더 내고 인증서에 도메인 하나 더 추가하는 것이다ㅋ


IE 나 파폭에서 https://naver.com 을 들어가보라

네이버도 경고 뜬다...ㅋㅋ






WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

ERR_SSL_OBSOLETE_CIPHER

Daily/Prog 2016. 9. 21. 22:30



https://www.oops4u.com/main 접속


# 사이트에 보안 연결할 수 없음

# https://www.oops4u.com 에서 지원되지 않는 프로토콜을 사용합니다.

# ERR_SSL_OBSOLETE_CIPHER


ERR_SSL_OBSOLETE_CIPHER... SSL 구식암호라... 

어제 크롬을 최신버전으로 업데이트 하고나서 발생한 오류.

지원되지 않는 프로토콜을 사용합니다... 라니...

단순히 https 일 뿐이고, IE / FF / 구크롬에서는 잘 되는 페이지인데 최신크롬에서만 안된다니!

server.xml 의 Connector 설정에는 TLS 프로토콜을 사용하도록 설정되어 있다.


현재 크롬 버전 : 53.0.2785.116 m


ERR_SSL_OBSOLETE_CIPHER 에 대해서 검색을 해봤다.

딱히 도움되는 내용은 없다 ㅡㅡㅋ 

cipher 로 검색했더니 톰캣에서는 ciphers 리스트 기본값에 보안이 취약한 cipher 가 포함되어 있어서 직접 설정하는 것을 권장(?)했다.

https://www.openssl.org/docs/manmaster/apps/ciphers.html 에서 필요한 프로토콜의 suite 를 긁으면 된다.

server.xml 파일에 아래처럼 cipher 값들을 넣어줬더니 해결되었다.



<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"

...

ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,

TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,

TLS_DHE_RSA_WITH_AES_256_CBC_SHA,

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,

TLS_DHE_RSA_WITH_AES_128_CBC_SHA,

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,

TLS_RSA_WITH_AES_256_GCM_SHA384,

TLS_RSA_WITH_AES_256_CBC_SHA256,

TLS_RSA_WITH_AES_256_CBC_SHA,

TLS_RSA_WITH_AES_128_GCM_SHA256,

TLS_RSA_WITH_AES_128_CBC_SHA256,

TLS_RSA_WITH_AES_128_CBC_SHA,

TLS_RSA_WITH_3DES_EDE_CBC_SHA"

...

/>


L4, ELB 에 붙은 실서버들은 멀쩡한데, 왜 똑같은 Tomcat8 설정에 유독 이 개발서버 한대만 이런일이 발생했는지 모르겠지만

어쨌든 크롬에서는 이번 업데이트에 https 보안에 대해 조금더 신경을 쓴 것 뿐이고,

나처럼 cipher 설정이란 것을 모르고 있는 기업들에서는 열라 땀 삐질한 것 뿐이고,

크롬 오랫동안 참 좋게 봤는데, 이런 건방진 수준의 업데이트 할 줄이야...



WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  2개가 달렸습니다.
  1. 정말 정말 정말 정말 감사합니다.!!!!ㅠㅠㅠ
secret

Mac ssh

Server/MacOSX 2016. 2. 2. 09:11

맥에서 ssh 접속하기.

맥에는 기본으로 Terminal 이 있지.

하지만 나는 Putty 를 찾았지. 등록할 서버가 한 두대가 아니니깐.

Putty 홈페이지를 가봤지. Mac 용은 없었지.

구글링에서는 터미널을 두고 왜 Putty 를 찾냐고들 했지.

결국 난 서버의 ip 를 모두 외워야 했지. 일치하는 pem 파일도 외워야 했지.

정녕 이 방법뿐인 것인가. mac 에서는 하지 말아야 하는 것인가...ㅜㅜ


# ssh -i ./myec2.pem ubuntu@123.123.123.123
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for './myec2.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "./myec2.pem": bad permissions
Permission denied (publickey).
cs


권한이 너무 많다고...


# chmod 600 myec2.pem
cs


난 여러 서버를 바로 접속할 수 있는 이런 화면이 필요하단 말이얏!





WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  1개가 달렸습니다.
  1. 지나가다가 우연히 보게 되었는데요. putty 랑 동일하진 않지만, terminal에서 셸 -> 새로운 원격 연결 하시면, 보안셸에 저장해놓고 쓸수 있습니다. pem 으로 접속하는 것도, 동일하게 사용가능해요. 저는 요즘엔 이클립스에로 사용하긴 하지만, 한동안은 터미널도 많이 썼어요
secret