이전 자료
Reference
목표
•
해커로 인해 서비스가 직면할 수 있는 공격에 대해 소개
•
암호화의 작동 원리와 Go의 표준패키지를 활용해 서비스를 안전하게 유지하는 방법을 소개
•
애플리케이션을 보호하는 안전선에 대해 배우는 단원
시작!
•
마이크로서비스에서 보안은 지뢰밭이다.
•
데이터를 전송하는 과정에서 데이터를 보호하는 방법은 암호화 하는 방법이다.
암호는 수학을 사용해 데이터를 암호화하고 해독하는 과학이다. 암호화는 중요한 정보를 저장하거나
안전하지 않은 네트워크(인터넷과 같은 회선)를 통해 중요한 정보를 전송할 수 있게 해 의도된
수신자를 제외한 모든 사람이 읽을 수 없도록 한다. -암호화 입문-
JavaScript
복사
대칭 키 암호화(Symmetric-Key Encryption)
•
Symmetric-Key Encryption
•
비밀키 또는 전통적인 암호화
•
즉 암호를 풀때에 이것이 있어야지 가능하며 역으로 암호를 걸때에도 이것이 필요하다.
•
그래서 이거 누출되면 난리난다.
공개 키 암호화(Public-key Encryption)
•
공개 키 암호화는 암호화를 위해 한 쌍의 키를 사용하며 공개 키는 정보를 암호화 하는데 쓰이고 비밀 키는 정보를 해독하는데 쓰이는 방식이다.
•
공개 키는 오픈 한다.
디지털 서명
•
디지털 서명은 개인 키로 암호화 하고 공개 키로 복호화가 가능하면 상대방이 보내는 메시지가 참임을 확실하는 방법이다.
디지털 서명의 단점
•
중간자 공격에 취약하다.
•
키가 공용 네트워크를 통해 전송되는 경우 취약하다.
•
즉 가짜 공개키를 제공하고 자신이 진짜 수신자라고 포장이 된다.
•
이를 위한 보안점은 X.509 디지털 인증서이다.
•
디지털 인증서에는 다음 세 가지가 포함된다.
1.
공개키
2.
소유자 이름 또는 ID와 같은 인증 정보
3.
하나 이상의 디지털 서명
SSL: 보안 소켓 계층(Secure Sockets Layer, SSL)
•
SSL은 웹사이트와 브라우저(혹은, 두 서버) 사이에 전송된 데이터를 암호화하여 인터넷 연결을 보안을 유지하는 표준 기술입니다.
•
이는 해커가 개인 정보 및 금융 정보를 포함한 전송되는 모든 정보를 열람하거나 훔치는 것을 방지합니다.
TLS: 전송 계층 보안(Transport Layer Security, TLS)
•
TLS는 가장 최신 기술로 더 강력한 버전의 SSL입니다. 그러나 SSL이 더 일반적으로 사용되는 용어이기에, 여전히 보안 인증서는 SSL이라 불립니다.
•
DigiCert에서 SSL을 구매하시면 가장 높은 신뢰성을 가진 최신 TLS 인증서를 획득 하시게 됩니다.
•
TLS는 대칭 키 암호화를 사용해 동작하며 클라이언트와 서버 양측이 암호화 및 복호화에 사용되는 키를 가지고 있다.
HTTPS: 하이퍼 텍스트 프로토콜 보안(Hyper Text Protocol Secure, HTTPS)
•
HTTPS는 웹사이트를 SSL/TLS 인증서로 보안하는 경우 URL 창에 표시됩니다.
•
사용자는 브라우저 바의 잠금 기호를 클릭하여 인증서 발행, 웹사이트 소유 기업명을 포함한 인증서의 세부 내용을 확인할 수 있습니다.
외부에 대한 보안
•
외부에 대한 보안은 시스템을 안전하게 유지하기 위한 첫 번째 방어선이다. (일반적으로 2계층이나 3계층에서 동작하는 방화벽, DDOS 보호, 웹 애플리케이션 방화벽 등이 있다.)
•
네트워크 2계층은 3계층과는 달리 IP 주소를 인식하지 않고 MAC 주소만 사용하기 때문에 IP 주소는 처리하지 않는다.
•
2계층은 라우팅에 사용된다.
•
3계층은 일반적으로 시스템 내부로 들어가는 첫 번째 진입점인 경계 방화벽에 사용된다.
Heartbleed
•
2014년 4월 세계는 오픈SSL에서 치명적인 취약점이 있음을 알게 됐다. CVE-2014-0160으로, 하트블리드라는 이름으로 더 잘 알려져 있다.
•
익스플로잇 될 경우, 아무런 흔적 없이 민감한 정보를 가져갈 수 있게 해준다. “오픈SSL을 사용함으로써 통신이 안전하게 보호되고 있다고 철썩같이 믿고 있다가 뒤통수를 가격당하는 것이 하트블리드 취약점의 문제입니다.” 당시 하트블리드를 발견했던 전문가들이 발표한 내용이다.
•
하트블리드 취약점을 통해 노출되는 정보는 1) 사용자 이름, 2) 비밀번호, 3) 암호화 되기 전의 콘텐츠였다. 공격자는 사실상 통신을 엿들을 수 있게 되고, 그러면서 데이터 탈취 및 신원 도용도 가능하게 된다. 이런 소식이 나오자마자 하트블리드를 익스플로잇 하는 실제 공격이 여기 저기서 발생했고, NSA와 같은 정보 기관은 이 취약점을 진즉부터 알고 있었다는 주장도 나왔다. 물론 NSA는 이를 부인했다.
•
하트블리드 이후 보안 전문가들은 오픈SSL에 깊은 관심을 갖기 시작했고, 그에 따라 의미 있는 변화들이 생겨났다. 하트블리드 최초 발견 이후부터 2016년 말까지, 2년이 조금 안 되는 기간 동안 10개가 넘는 고위험군 취약점이 오픈SSL에서 발견됐고 해결됐다. 2017년에는 딱 한 개의 고위험군 취약점이 발견됐고, 2018년과 2019년에는 저위험군으로 분류되는 것들만 발견됐다.
•
오픈SSL 관리 위원회(OpenSSL Management Committee)에 소속된 맷 카스웰(Matt Caswell)은 “하트블리드 발견 이후 오픈SSL 내부적으로도 엄청난 변화가 있었다”고 증언한다. “하트블리드 전에는 취약점과 패치를 풀타임으로 전담하는 인력이 없었습니다. 그 분야를 소홀히 했다기보다, 자원이 없었던 것이죠. 하지만 하트블리드 이후로는 자원을 추가로 할당해 인력을 새로 고용해야만 했습니다.” 현재 취약점과 패치 전담 인원은 0명에서 2명으로 는 상태다.
•
커뮤니티의 참여도 확대됐다. “2013년에는 약 30명의 참여자들이 469개의 커밋(commit)을 제출했습니다. 2014년 이후 커뮤니티의 관심이 높아진 이후로 이 숫자는 꾸준히 증가했습니다. 그래서 2019년에는 150명의 전문가들이 1800개가 넘는 커밋을 제출했습니다. 이처럼 커뮤니티 전체의 관심이 높은 수준으로 올라갔음을 내부적으로 체감할 수밖에 없습니다.”
•
또한 코드의 질을 높이는 필수 리뷰 과정도 추가됐다. “커뮤니티의 커밋은 최소 2명의 전문 개발자의 검토를 받도록 되어 있습니다.” 코드베이스의 외부 감사가 다단계로 증가된 것도 주요한 변화다. “감사는 퍼즈 테스팅, 정적 분석, 트래비스(Travis)와 앱베이어(AppVeyor)의 통합으로 인한 지속적 실험 등으로 구성되어 있습니다. 이런 변화 덕분에 2016년까지 수많은 취약점들이 발견되고 패치된 겁니다.”
•
하지만 예산 확보에는 아직도 어려움이 있다고 카스웰은 말한다. “하트블리드 사태 직후에는 여러 기관과 조직에서 예산이 들어왔습니다. 리눅스재단(Linux Foundation)도 그 중 하나였고요. 하지만 이제 여러 해가 지났고, 예산은 다시 원점으로 복귀했습니다. 아직도 안정적인 예산 공급처를 찾고 있습니다. 물론 이는 어느 조직에서나 어려운 일이겠죠.”
•
오픈SSL은 현재 해커원이 호스팅 된 인터넷 버그바운티에도 참여 중이다. 오픈SSL 코드에서 취약점을 찾아낸 전문가들에게 보상금을 주기 위함이다. 현재까지 3만 1천 달러의 상금이 지출됐다. “통신을 보호하는 오픈SSL에 대한 보안 전문가들의 관심이 더 많이 필요합니다. 그래야 인터넷 전체가 안전해지는 것이니까요.”
•
3줄 요약1. 7년 전 전 세계 뒤흔들었던 오픈SSL의 취약점, 하트블리드.2. 암호화 된 통신을 침해해 민감한 정보를 획득할 수 있게 해주는 취약점.3. 2014년 이후로 보안 전문가들의 관심 높아졌지만, 아직 안정적인 예산 확보는 숙제.
웹 애플리케이션 방화벽(WAF : Web Application Firewall)
•
웹 애플리케이션 방화벽은 HTTP 애플리케이션을 위한 애플리케이션 방화벽이다.
•
이 방화벽은 HTTP 통신에 일련의 규칙을 적용한다.
•
이러한 규칙들은 XSS 및 SQL 주입과 같은 일반적인 공격을 다루고 있다.
•
프록시는 클라이언트를 보호하지만 WAF은 서버를 보호한다.
•
WAF은 특정 웹 애플리케이션 또는 웹 애플리케이션의 집합을 보호하기 위해 배포된다.
•
WAF를 역방향 프록시로 생각할 수도 있다.
•
WAF는 어플라이언스, 서버 플러그인 또는 필터의 형태로 제공될 수 있으며, 애플리케이션에 맞게 사용자가 정의할 수 있다.
•
이처럼 사용자에 맞추어 규칙을 정의 하려는 노력은 중요할 수 있으며, 애플리케이션이 수정될 떄 마다. 함께 유지 관리해야 한다.
API 게이트웨이
•
API 게이트웨이는 공개 API를 백엔드 서비스로 라우팅 하는 목적과 네트워크 경계에서의 토큰 유효성 검증이나 입력값의 검증 및 변환과 같은 일부 추가 기능을 제공하는 두 가지 목적으로 사용된다.
•
API 게이트웨이는 아래의 기능을 구현할 수 있다.
1.
요청 유효성 검사
2.
권한 부여
3.
속도 제한
4.
로깅
5.
캐싱
6.
요청 및 응답의 변환
•
WAF와 API 게이트웨이 사이에 겹치는 요소가 있기는 하지만 두 가지는 분리된 별개의 인프라 요소로 생각해야한다.
•
MSA(마이크로 서비스 아키텍쳐, 이하 MSA)와 함께 근래에 떠오르고 있는것이 API 게이트 웨이이다. API 게이트웨이는 API서버 앞단에서 모든 API 서버들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능에서 부터 메세지에 따라서 여러 서버로 라우팅 하는 고급기능 까지 많은 기능을 담당할 수 있다.
•
API 게이트웨이의 시작은 MSA가 SOA(서비스 지향 아키텍쳐)에서 시작한것 처럼 ESB (Enterprise Service Bus)에서 부터 시작 되었다. 그래서 ESB의 대부분의 컨셉을 많이 승계했는데, ESB의 실패와 단점을 보완해서 만들어진 사상이 API 게이트웨이이다. ESB가 SOAP/XML 웹서비스 기반의 많은 기능을 가지는 구조였다면, API 게이트 웨이는 JSON/REST 기반에 최소한의 기능을 처리하는 경량화 서비스 이다. 그리고 ESB는 SOA의 사상에서 개념적으로 탄생한 솔루션이라면, API 게이트 웨이는 ESB의 실패와, MSA, REST 구현 사례를 통해서 필요에 의해서 탄생한 솔루션이기 때문에, 그 실용성이 차이가 난다.
•
MSA 아키텍쳐 구현을 위한 API Gateway 보충자료
DDoS 방지
•
Mirai 소스코드
•
MIRAI BOTNET에 취약한가?
1. 23번 포트(Telnet)를 쓰고 있다
2. ID/PW가 추측하기 쉽다.
•
이러면 기본적으로 MIRAI BOTNET 에 취약하다
•
해결책은?
1. 최대한 (특히 쉘을 제공하는) 포트를 열지 않는다.
2. 아이디 / 패스워드를 어렵고 길게 만든다.
•
출처
MIRAI -> IoT 기기 공격 분석
1. Injection
•
공격 방식은 아이디/패스워드 테이블에서 랜덤하게 뽑아서 대입해 보는 것이다.
•
Burpsuite 의 Intruder로 따지자면 Pitchfork 형태가 된다.
•
이 Parameter는 add_auth_entry("아이디", "패스워드", "가중치") 로 설정하는데,
•
가중치가 높을수록 공격시 랜덤으로 뽑힐 가능성이 높아진다.
•
가장 가중치를 높게( 10 ) 설정 한 부분의 난독화를 풀면
•
add_auth_entry("root", "xc3511", 10) 이다.
•
아이디가 root이면서 패스워드가 xc3511 인 IoT 기기가 특히 많은 것을 확인 할 수있다.
2. Port
•
보시면 Packet Header 를 설정하는데, dest 는
•
23번 (Telnet) 포트로 고정하고,
•
src는 1024 이하에서 랜덤으로 설정합니다.
•
이 부분이 중요합니다.
•
MIRAI BOTNET은 23번 포트만 스캐닝 합니다.
•
1, 2 번이 끝나고 3번부터는 계속 루프를 돌면서 스캐닝을 합니다.
3. IP
IP는 랜덤하게 가져옵니다.
다만 정말 마구잡이로 랜덤하게 설정하는 것은 아닙니다.
아래처럼,
Class별로 IP처럼 생긴 숫자만 뽑아서 랜덤하게 만듭니다.
4. Scan
이제 Syn Raw Packet을 만들어 쏘고, Syn +Ack 패킷 받는 걸 계속합니다.
방식은 하나씩 시도 해보는게 아니라
커넥션을 128개까지 만들어서 syn 패킷을 보내놓고,
한꺼번에 처리하는 방식입니다.
5. Attack
Connection이 성립하면 공격을 하는데,
이 부분을 BruteForce라고 부르기가... 좀 애매합니다.
왜냐하면 62개 정도 밖에 안되는 ID / PW 셋을
모두 다 시도 해보는 것도 아니고
아래처럼 가중치에 따라 랜덤하게 뽑아서 시도 해보기 때문입니다.
다만 Connection 이 살아있다면, 10번 정도 더 시도 해보긴 합니다.....
DDOS 공격 유형
1.
UDP 단편화 : 공격자가 네트워크상의 데이터그램 단편화 방식을 악용하는 것이다.
2.
DNS : DNS 공격은 UDP 플러드를 이용해 DNS 서버를 무력화 한다.
3.
NTP : NTP는 NTP 서버에 내장된 기능을 활용한 또 다른 증폭 공격이다.
4.
Chargen : 문자생성프로토콜로 불리며 이 공격은 또 다른 반사 증폭 공격이다.
5.
UDP 플러드 : 조작된 발신지 주소를 가진 UDP 패킷을 특정 IP 주소로 대량 전송함으로써 작동한다.
6.
SYN : SYN 플러드는 고전적인 DDOS 공격으로 연결이 닫히지 않도록 패킷을 대량 전송한다.
7.
SSDP : 플러그 앤 플레이 장치 검색에 주로 사용되는 단순 서비스 검색 프로토콜이다.
8.
ACK : ACK 플러드는 클라이언트가 서버에 연결할 때 사용하는 3방향 핸드쉐이크를 이용한다.
애플리케이션 보안
•
암호화의 동작 방식과 인프라의 취약점에 기술을 넘어 애플리케이션의 경우에도 보안에 신경을 써줘야한다.
•
ThoughtWorks사에서 사용하는 마이크로서비스 보안 모델을 제안한다.
1.
예방 : 안전한 통신, 인증 및 권한을 부여하는 기술이다.
2.
탐지 : 탐지는 애플리케이션 로그 및 ModSecurity 로그와 관련 되며 에러를 찾기위한 목적 뿐만 아니라 악의적인 탐지를 방어하기 위해 로깅 방식에 대해서도 생각을 해봐야 한다.
3.
대응 : 대응은 침해 상황에 침착하게 대처하는 방법을 말한다.
4.
복구 : 새로운 인프라로 재 구축하는 방법이다.
•
권한혼동 : 한 시스템이 다른 시스템과 신뢰를 악용해 평상시에는 할 수 없는 명령을 실행할 수 있게 되는 것이다.
•
공격자가 방화벽을 우회할 수 있는방법 : 공격자는 자신의 도구 상자에 보안 시스템을 우회하기 위한 여러 가지 도구를 가지고 있기에 항상 이에 대한 준비를 해야한다.
•
예시로 공격자가 프론트엔드 표현을 위해 사용된 탬플릿 엔진에서 원격 코드 실행 취약점을 발견할 수 있다. 상기 시스템이 쿠버네티스에서 실행중이며 공격에 성공한 컨테이너 내부에서 제어 API를 사용할 수 있다는 것을 알아냈다는걸 가정하에 이건 매우 실제적인 위협이지만 GO에서는 공격자를 힘들게 만들 수 있는 기능을 제공한다.
•
입력 유효성 검사 : 공격자가 원격 코드 실행 익스플로잇을 사용해 공격 대상에 접속한다고 가정하면 WAF 이후의 첫번째 방어선은 입력 유형성 검사이다. 모든 데이터는 경계값을 설정하기 위해 유효성을 검사한다.
•
퍼징 : 입력 유효성 검사의 경계값을 테스트 하는 매우 효과적인 한 가지 방법은 테스트 중에 퍼저를 사용하는 것이다. 퍼저는 애플리케이션을 중단시키거나 예기치 않은 출력을 생성하려는 의도가 있는 임의의 입력을 생성하여 미리 예방한다.
•
TLS : 모든 트래픽이 암호화 되지 않았다고 가정하에 가짜 호출을 막을려고 하는 방법이다.
◦
개인키 생성
◦
X.509 과 같은 인증서 생성
•
데이터 저장소 보안 : 우리가 만든 시스템이 사용자 계정과 같은 것을 저장하기 위해 데이터베이스에 연결되었다고 가정하면, 공격자는 암호의 데이터베이스에 완벽하게 접근할 수 있다.
◦
해결 방법중에 무식한 방법은 데이터를 암호화 하는 것인데 이것은 비용이 많이 들어간다.
◦
마이크로서비스를 활용하여 기능과 데이터를 분리하여 한다면 조금 유리하다.
•
OWASP : 실용적인 웹 보안에 대한 조언을 구할 때에 항상 OWASP가 첫번째 호출 포트로 하면 된다.
◦
URL에 세션 토큰 저장 금지
◦
XSS, CSRF
◦
안전하지 않은 객체 직접 참조
•
인증 및 권한 부여 : 인증은 사용자의 이름과 암호가 한 쌍인지 확인하는 것처럼, 어떤 것이 참인지 확인하는 프로세스나 동작을 의미한다. 권한 부여는 사용자와 관련된 접근 권한이나 정책을 지정하는 기능이다.
•
JWT : JSON 웹 토큰은 특정 환경에 있는 사용자의 권한 요청이나 데이터를 안전하게 전달하는 표준이다. 매우 인기가 많고 Go에서도 쓰일수 있다.
◦
주요장점은 다음과 같다.
▪
하나는 권한 요청에 대한 표준 형식이므로 신뢰할 수 있는 프레임워크에서 사용할 수 있다는 점이다.
▪
다른 하나는 비대칭 암호화를 사용한다는 점이다.
유지보수
•
시스템을 안전하게 유지하기 위한 중요한 방법은 모든 최신 보안 패치를 업데이트 된 상태로 유지하는 것이다.
•
컨테이너 패치 : 컨테이너를 안전하게 유지하는 가장 간단한 방법 중 하나는 정기적으로 컨테이너를 빌드하고 배포하는 것이다.
•
소프트웨어 업데이트 : 호스트와 Docker 이미지에서 소프트웨어를 패치하면 OpenSSL에서 발견된 하트블리드와 같은 취약점으로 부터 안전하게 보호하는 데 도움이 될 것이다.
•
애플리케이션 코드 패치 : 호스트의 소프트웨어를 업데이트 해야하는 것과 마찬가지로 애플리케이션 코드도 업데이트를 해야 항상 최신 업데이트가 적용된다.
•
로깅 : 암호를 보호하고 적절한 보안을 구현했다 하더라도 언제 위협을 받고 있는지 알아야할 필요가 있다.