Skip to main content

4 posts tagged with "network"

View All Tags

· 5 min read

Web Application Firewall​

AWS에서 제공하는 서비스인 WAF는 Web Application Firewall의 약자이지만, WAF라는 용어는 AWS에서 새로 만든 것은 아니다. 따라서 WAF, 그 이전에 Firewall이 무엇인지 아주아주 간략하게나마 이해할 필요가 있다.

Firewall(이하 방화벽)은 일반 인터넷과 내부 네트워크를 분리하는 HW/SW의 조합으로, 패킷을 허용 또는 차단하는 방식으로 동작한다. 최초의 방화벽은 패킷의 정보(IP 주소, 포트 번호, ACK 비트 등)와 정해진 정책에 따라 패킷을 필터링하는 기능을 수행하였으나, 점차 다양한 방향으로 발전하였다.

이 중 애플리케이션이나 서비스에 적용되는 L7 트래픽을 제어하는 방화벽을 Appplication Firewall이라고 불린다. 따라서, WAF는 웹 애플리케이션에 적용되는 Application Firewall을 말한다.

AWS WAF​

AWS WAF는 규칙 기반(Rule-based)으로 특정 AWS resource의 인/아웃바운드 트래픽을 제어할 수 있는 서비스이다.

WAF로 제어 가능한 AWS resource는 아래와 같다.

  • Amazon CloudFront distribution
  • Amazon API Gateway REST API
  • Application Load Balancer
  • AWS AppSync GraphQL API responds to HTTP(S) web requests

Web ACL, Rule, Rule Group​

WAF는 일종의 규칙 목록인 Web ACL을 관리할 resource에 연결하는 방식으로 동작한다. Web ACL은 여러 개의 Rule을 가질 수 있으며, 사용자는 다양한 Statement를 조합하여 Rule이 원하는 대로 동작하도록 구성할 수 있다. 또, 여러 개의 Rule을 Rule Group이라는 resource로 묶어서 관리할 수 있는데, Web ACL 역시 Rule들의 집합이라 볼 수 있으므로 Rule Group과 Web ACL의 관계는 처음 이해할 때 개인적으로 굉장히 헷갈리는 부분이었다.

AWS resource에 연결된 Web ACL은 WAF 관점에서 해당 resource를 추상화한 인터페이스로 볼 수 있다. 즉, 어떤 Web ACL에 어떤 규칙을 추가하는 것은 곧 그 Web ACL이 연결된 AWS resource에 그 규칙을 적용하는 것과 같다.

반면, Rule Group은 함께 사용되면 편리한 Rule들을 한 번에 적용하기 위한 관리 단위로, Rule Group을 AWS resource에 적용하기 위해서는 Web ACL에 이를 'Rule Group을 참조하는 Rule' 형태로 추가하여 사용한다.

다만 Web ACL과 AWS resource의 대응 관계는 1:N으로, 하나의 resource에는 하나의 Web ACL만 연결할 수 있지만, 하나의 Web ACL을 여러 resource에 연결하여 재사용하는 것은 가능하다. (단, CloudFront Distribution에 연결된 Web ACL은 다른 종류의 resource들에 연결할 수 없다.)

Web ACL Capacity Unit(WCU)​

모든 Rule은 전부 그 복잡도에 따라 사용하는 컴퓨팅 파워의 양을 나타내는 척도를 갖는데, 이를 WCU라 한다. 각 Web ACL은 1500의 WCU 상한선(Support 요청을 통한 상향 조정은 가능)을 가지므로, 이를 고려하여 resource 관리 체계를 구성하여야 한다.

Rule Group을 최초 생성 시 변경 불가능한 WCU 상한선(Capacity)을 지정하여야 하는데, Rule Group이 갖는 Rule들의 WCU 총합(Used Capacity)은 (당연하게도) Capacity를 초과할 수 없다.

Web ACL에 Rule Group을 추가하게 되면 Rule Group의 Capacity(Used Capacity 아님)가 Web ACL의 WCU 사용량을 잡아먹는다. 따라서 Rule Group의 Capacity를 필요 이상으로 크게 생성하면 WCU 상한선을 넘겨서 Rule Group을 다시 생성하여야 하므로, 적정 수준의 Capacity를 설정하는 것이 바람직하다.

출처​

컴퓨터 네트워킹: 하향식 접근 - 제6판 (Kurose, Ross / Pearson / 2012) https://en.wikipedia.org/wiki/Firewall_(computing) https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html

· 3 min read

SSH Port Forwarding과 그 종류​

  • SSH Tunneling이라고도 부름
  • 특정 포트를 다른 연결에 forwarding하는 행위
  • 프록시와 유사한 역할을 수행
  • Local, Remote, Dynamic 포트 포워딩이 있음

Local Port Forwarding​

Local port forwarding은 말 그대로 localhost(SSH 클라이언트)의 특정 포트를 다른 연결로 forward한다.

ssh -L <local port>:<target server>:<target port> <username>@<remote server>
  • <local port>: SSH 터널링의 시작점으로 사용될 SSH 클라이언트가 동작하는 호스트의 포트
  • <target server>: 최종 목적지 서버
  • <target port>: <target server>의 포트
  • <remote server>: SSH 터널링을 통해 도달하는, Gateway(Bastion) 역할을 하는 서버(SSH 서버)

즉, 클라이언트 환경에서 위와 같은 프로세스가 실행되면, localhost:<local port>로 전달되는 요청은 username@<remote server>에서 <target server>:<target port>에 보내지는 요청으로 처리된다.

ssh -L 123:localhost:456 root@1.2.3.4

이미지 출처: https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot

위 예시는 target server를 localhost, 즉 자기 자신(gateway server, SSH server, 1.2.3.4)으로 지정한 경우이다. 이 때는 접근이 허용된 어느 호스트(자기 자신을 포함하여)에서든 프로세스를 실행한 클라이언트의 123번 포트(아래 이미지의 your host:123)로 요청을 보내면, 해당 요청은 ssh 터널을 통해 root@1.2.3.4 --> 127.0.0.1:456 연결로 forward된다.

ssh -L 123:<farawayhost>:456 root@1.2.3.4

이미지 출처: https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot

반면 위와 같이 target server를 다른 farawayhost로 지정하여 포트 포워딩을 실행할 경우, 클라이언트의 123번 포트로 보내진 요청은 ssh 터널을 통해 1.2.3.4 --> farawayhost:456으로 forward된다.

즉, Local Port Forwarding은 아래와 같은 기능을 수행한다.

<some_host> --> <client_host>:<client_port> 를 아래 연결로 forward한다. <remote_host> --> <target_host>:<target_port>

Local Port Forwarding의 이점​

Local port forwarding을 통해, 불특정 다수(<some_host>)의 <target_host>:<target_port>로의 접근 제어를 <client_host>:<client_port>로의 접근 제어를 통해 관리할 수 있다. 즉 <target_host>:<target_port>는 <remote_host>(Bation Host의 역할을 수행)로부터의 접근만 허용하면 된다는 점에서 <target_host>를 보다 안전하게 관리할 수 있고, 보안/시스템적 제약 사항을 우회하는 데에도 자주 쓰인다. 컨테이너 기반 환경에서는 특히 이러한 Local Port Forwarding을 요긴하게 사용할 수 있다.

출처​

https://linux.systemv.pe.kr/ssh-%ED%8F%AC%ED%8A%B8-%ED%8F%AC%EC%9B%8C%EB%94%A9/ https://blog.naver.com/PostView.naver?blogId=alice_k106&logNo=221364560794 https://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS5064906327 https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot https://www.ssh.com/acadeclient/ssh/tunneling/example

· 8 min read

Stateless에게 State를​

HTTP는 무상태(stateless) 프로토콜이다. 하지만 클라이언트와의 상호작용을 위해서는 서버가 클라이언트(사용자)의 상태(state)를 알 수 있어야 한다. 이를 위해 등장한 기술이 몇 종류 존재하는데, 쿠키, 세션, 웹 스토리지가 그것이다.

쿠키(Cookie)​

쿠키는 서버가 클라이언트를 식별하고 클라이언트의 상태를 저장하기 위해 사용하는, 클라이언트에 대한 정보를 저장한 파일이다. 브라우저는 서버의 응답으로부터 쿠키를 전달받아 클라이언트 환경에 key-value 형태로 저장하였다가, 추후 HTTP 요청 시 해당 도메인으로부터 등록된 모든 쿠키를 요청과 함께 전달한다.

클라이언트 입장에서, 쿠키에 자신의 정보가 저장되는 것은 탈취당할 요소를 추가하는 것이므로 보안적인 위협이 된다.
반면, 쿠키를 관리/전달하는 주체는 클라이언트이므로 클라이언트 쪽에서는 이를 얼마든지 위/변조하여 서버에게 전달할 수 있고, 따라서 서버 입장에서도 클라이언트가 전달하는 쿠키가 보안적 위험 요소로 작용할 수 있다.

위와 같은 단점이 존재함에도 불구하고, 쿠키는 여전히 널리 사용된다. 서버가 클라이언트를 식별하고 클라이언트의 상태에 따라 동작하기 위해서는 클라이언트의 정보가 반드시 어딘가에는 저장되어 있어야 하므로, 이를 위한 가장 간편한 해결책인 쿠키는 보안에 민감한 정보가 아닐 경우에 한해 가장 먼저 고려할 수 있는 수단이다.

세션(Session)​

위에서 쿠키 방식의 단점 중 하나는, 클라이언트 쪽에서 위/변조 또는 탈취한 쿠키를 사용할 경우, 서버 쪽에서 이를 탐지하고 해당 요청을 거부할 수 없다는 것이었다. 따라서, 그런 중요한 정보를 클라이언트 쪽에서 전달하는 대로 믿지 않고 서버에서 직접 사용자의 정보를 관리하는 해결책을 떠올릴 수 있고, 이를 일반적으로 세션 방식이라고 부른다. 다만 앞서 설명한 것처럼 HTTP는 stateless 프로토콜이므로 서버에서 일방적으로 클라이언트를 식별할 수 있는 방법은 없다. 따라서, 서버에 필요한 정보를 저장하여도 해당 정보와 그 주인(특정 클라이언트)를 매칭시키기 위해서는 클라이언트를 식별하기 위한 식별자 정보가 필요하고, 이를 위해 서버는 클라이언트 식별자로 사용할 수 있는 쿠키를 발급한다.

즉 쿠키 방식과 세션 방식이라고 흔히들 말하는 것에 반해, 엄밀히 따지자면 쿠키와 세션은 대립되는 선택지가 아니다. 세션 방식에서도 쿠키를 사용하기 때문이다. (쿠키를 사용하지 않는 경우도 있다고 하나, 쿠키를 사용하여 세션을 관리하는 방식이 가장 널리 쓰인다고 한다.) 하지만 세션을 사용한 사용자의 인증은 중요한 정보가 서버 측에 저장되어 불특정 클라이언트로부터의 위/변조가 어렵고, 클라이언트의 정보가 탈취당한다 하여도 세션이 만료된다면, 즉 클라이언트의 브라우저가 종료되거나 서버 쪽에서 설정한 세션 시간이 경과되면 해당 값은 사용할 수 없는 값이 되어버리므로 비교적 안전하다.

물론 브라우저가 종료되면 사용자의 정보는 모두 사라지는 점은 때로는 단점으로 작용하여, 이를 유지하기 위해 쿠키를 사용하여야 할 때도 있다. 또 대규모 시스템의 경우, 가용성을 확보하기 위해 여러 대의 서버를 사용하여 부하를 분산하게 되는데, 이러한 경우 한 클라이언트가 보내는 연속적인 요청을 한 서버가 맡아서 처리하지 않으면 사용자가 시스템을 정상적으로 사용할 수 없으므로, 세션 정보만을 처리하는 별도의 서버를 분리하여 운영하기도 한다.

웹 스토리지(Web Storage)​

웹 스토리지는 비교적 최근에 등장한 기술로 HTML5 표준에서 정의되었으며, 쿠키와 유사하면서도 장/단점이 존재하지만 쿠키의 단점을 보완해줄 수 있는 기술이다. 웹 스토리지는 만료 시간이 없는 로컬 스토리지와 탭 단위 휘발성을 갖는 세션 스토리지로 구분되어 데이터의 용도에 따라 저장 장소를 선택하여 데이터의 생애 주기를 보다 효과적으로 관리할 수 있어 보다 안전하다. 또, 존재하는 모든 정보가 매번 무조건 전송되는 쿠키와 달리, 웹 스토리지에 있는 데이터 중 어떤 데이터를 전송할 지 선택할 수 있으며, string값만 저장할 수 있었던 쿠키와 달리 Javascript 객체를 저장할 수 있게 되었다는 점도 보다 다양한 방식으로 HTTP를 사용할 수 있는 여지를 준다.

출처​

https://kamang-it.tistory.com/entry/Web%EC%A1%B0%EA%B8%88-%EB%8D%94-%EC%9E%90%EC%84%B8%ED%9E%88%EB%8F%84%EB%8C%80%EC%B2%B4-%EC%99%9C-%EC%9D%B4%EB%A6%84%EC%9D%B4-%EC%BF%A0%ED%82%A4%EC%9D%B8%EA%B1%B8%EA%B9%8C-%EC%83%81%ED%83%9C%EB%A5%BC-%EC%A0%80%EC%9E%A5%ED%95%98%EB%8A%94-http-cookie https://kamang-it.tistory.com/entry/Web%EC%A1%B0%EA%B8%88-%EB%8D%94-%EC%9E%90%EC%84%B8%ED%9E%88%EC%84%9C%EB%B2%84%EC%99%80-%ED%81%B4%EB%9D%BC%EC%9D%98-%EC%97%B0%EA%B2%B0%EA%B3%A0%EB%A6%AC-%EC%83%81%ED%83%9C%EB%A5%BC-%EC%84%9C%EB%B2%84%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%98%EB%8A%94-http-session-cookie%EC%99%80%EC%9D%98-%EB%B9%84%EA%B5%90 https://kamang-it.tistory.com/entry/Web%EC%A1%B0%EA%B8%88-%EB%8D%94-%EC%9E%90%EC%84%B8%ED%9E%88cookie%EB%8A%94-%EB%84%88%EB%AC%B4-%EA%B5%AC%EC%8B%9D%EC%95%84%EB%83%90-%EC%9D%B4%EC%A0%9C%EB%B6%80%ED%84%B4-Web-Storage https://kcizzang.tistory.com/entry/SessionStorage-%EC%99%80-LocalStorage-%EC%B0%A8%EC%9D%B4%EC%A0%90

· 10 min read

SSL/TLS란?​

  • SSL(Secure Socket Layer)은 암호 기반의 인터넷 보안 프로토콜
  • 여러 번의 보완이 있었으며, 넷스케이프와 무관한 IETF가 이를 관리하면서 TLS(Transport Layer Security)로 이름이 변경
  • HTTP가 이를 사용하여 HTTPS(HTTP over TLS)를 제공하며, SNMP, FTP 등 다른 프로토콜에서도 SSL/TLS를 사용
  • 현재 SSL은 업데이트가 중단되어 많은 보안 취약점이 있고, 대다수의 웹 브라우저는 SSL을 지원하지 않는다.
  • 따라서 대부분의 경우 엄밀하게 말하자면 TLS라 표기하는 것이 맞지만, SSL이 TLS를 지칭하는 용어로 자주 혼용된다.

SSL/TLS의 기능​

  • Encryption: 웹 상에서 전송되는 데이터를 암호화하여, 전송 중인 데이터를 탈취하여도 의미없게 만든다.
  • Authentication: Handshake라는 두 기기 간 인증 절차를 거침으로서 서로가 서로임을 보장해준다.
  • Integrity: 디지털 서명을 통해 데이터 무결성, 즉 데이터가 변조되지 않았음을 검증한다.

SSL certificate(TLS certificate)란?​

  • 웹사이트의 서버 또는 앱 서버에 저장되어 웹사이트를 인증해주는 일종의 신분증이다.
  • 인증서에는 아래와 같은 정보가 포함되어 있다.
    • 도메인 네임
    • 발급받은 주체(개인, 단체, 기기)
    • 발급 주체(CA)
    • CA의 디지털 서명
    • 적용받는 서브도메인들
    • 발급 날짜
    • 만료 날짜
    • 퍼블릭 키
  • 인증서에는 웹사이트의 퍼블릭 키가 포함되어 사용자 디바이스는 이를 통해 웹사이트와 안전한 연결을 할 수 있도록 한다.
  • 웹사이트는 별도 관리하는 프라이빗 키로 사용자가 전달한 퍼블릭 키로 암호화된 데이터를 복호화한다.
  • CA(Certificate Authorities)는 SSL 인증서를 발급해주는 기관이다.

SSL certificate validation level​

  • Domain Validation
    • 가장 낮은 수준의 검증
    • 비용 저렴
    • 해당 도메인의 control 여부만 증명: 이는 보통 DNS 레코드나 이메일을 통해 검증
  • Organization Validation
    • CA가 직접 인증서를 발급받는 주체와 접촉하여 검증
    • 인증서에는 해당 단체의 이름과 주소 등을 포함
  • Extended Validation
    • SSL 인증서 발급 전, 해당 환경과 단체에 관한 폭넓은 검증
    • 단체가 정말 존재하며 법적 문제 없이 등록되어있느지 등을 조사
    • 시간과 비용 필요

안전한 상태란?​

  • 클라이언트가 신뢰할 수 있는 상태의 인증서
  • 안전한 설정
    • 안전한 프로토콜 제공(Protocol support)
    • 안전한 암호(Secure Cipher Suites) 설정

클라이언트가 신뢰할 수 있는 인증서​

  1. 서비스 도메인에 적합한 인증서 유형의 확인

    • FQDN(Fully Qualified Domain Name: Subdomain부터 TLD까지 포함하는 완전한 도메인 이름)에 대한 개별 인증서
    • SAN(Subject Alternative Name) 인증서: 여러 FQDN에 대한 신뢰를 한번에 제공
    • Wildcard 인증서
      • '*'을 접두사로 사용하여 서브도메인 전체에 대한 신뢰 제공
      • 첫 번째 레벨 서브 도메인에 대해서만 커버 가능: 두 번째 이하 레벨은 신뢰하지 않음

  2. 신뢰할 수 있는 root CA의 선택

  3. 인증서 프라이빗 키를 안전하게 보관

    • 인증서를 발급받을 경우 보통 아래와 같은 파일들이 생성 |Index|Purpose|Filename| |------|---|---| |1|CA로부터 서명 받은 인증서(X.509 형식)|cert.pem| |2|인증서의 개인키(Certificate’s private key)|privkey.pem| |3|중간 CA의 인증서|chain.pem| |4|Fullchain(1+3 combined)|fullchain.pem|
    • 2번 파일인 인증서의 개인키는 안전한 곳에서 최초 생성 후 접근 불가하도록 설정
    • 나머지 파일들은 클라이언트가 접속할 때 전달

  4. 웹서버에서 적절한 중간 CA 인증서 설정: 클라이언트에서 Chain of Trust 확인

    • 위 테이블의 3, 4번 파일
    • 클라이언트가 인증서를 신뢰할 수 있는 근거를 전달하는 절차
    • 클라이언트는 접속할 서버에서 보낸 인증서 내용 확인 후 신뢰할 수 있는 CA의 서명을 확인
    • 클라이언트가 전달받은 leaf 인증서를 서명한 중간 CA 정보와, 중간 CA를 서명한 root CA가 이미 신뢰하는 root CA의 목록에 있는지 차례대로 확인(Chain of Trust)하여 검증
    • 따라서, 중간 CA 정보를 클라이언트에 전달하지 못하면 root CA에 대한 신뢰관계를 검증하지 못할 수도(대부분 클라이언트들은 신뢰하는 중간 CA 정보도 설정하기 때문에 문제가 없는 경우가 많음) 있기 때문에 중간 CA 정보를 설정하는 것이 좋음
    • root CA와 중간 CA를 굳이 분리하는 것은 신뢰구조 전체가 무너지는 것을 방지하기 위함이며, root CA는 중간 CA를 서명하기 위해서만 제한적으로 사용되고 실제 발급되는 leaf 인증서의 발급(서명)에는 중간 CA를 사용하는 구조가 보편적.
    • CSR(Cross Signed Root): 클라이언트의 신뢰하는 root CA 목록에 해당 root CA가 포함되지 않을 수 있는데(클라이언트 환경이 오래되었거나, root CA가 비교적 최근에 작성되었을 경우), 이 경우 대부분의 클라이언트가 신뢰하는 root CA에게 별도로 서명을 받아두기도 하며 이를 CSR이라 한다.
    • SNI(Server Name Indication): 여러 도메인을 하나의 웹 서버로 서비스할 때, 접속하고자 하는 호스트네임을 요청하여 적절한 인증서를 받아 오기 위해 SNI를 지원하는 클라이언트 환경이 요구될 수 있다.

안전한 설정​

  1. 사용하는 OpenSSL 라이브러리의 지속적인 업데이트
    • 라이브러리 커플링: 웹서버 설치 시 OpenSSL 라이브러리를 정적으로 빌드하면 업데이트할 시 웹서버를 새로 빌드/배포해야 하므로, 시스템 라이브러리를 사용하여 웹서버와 분리할 것을 권장
  2. 안전하지 않은 프로토콜의 배제
    • TLS는 지속적으로 보안 수준을 높여가고 있으므로 최신 버전 프로토콜만 사용하도록 하는 것이 바람직하나, 호환성을 고려하여 상황에 따라 결정
  3. 안전한 cipher suite 설정
    • Cipher Suite: 안전한 연결 생성을 위한 4개의 암호화 알고리즘
      1. 키 교환(Key exchange/agreement)
      2. 접속 시 상대 확인(Authentication)
      3. 기밀성을 위한 블록 암호화(Block/stream cipher)
      4. 메시지 무결성을 위한 암호화(Message authentication)
    • cipher suite를 구성하는 알고리즘을 결정하는 데 있어 대규모 트래픽 처리 시 성능을 고려해야 할 때도 있으므로 테스트를 해보는 것이 좋음

출처: https://www.cloudflare.com/learning/ssl/what-is-ssl/ https://www.cloudflare.com/learning/ssl/what-is-an-ssl-certificate/ https://engineering.linecorp.com/ko/blog/best-practices-to-secure-your-ssl-tls/