전체보기

바로 이전글에서 private 서브넷에 웹 서버 인스턴스를 생성하고 ALB로 연결까지 확인했었다. 이번에는 외부 인터넷단에서 유입되는 유해트래픽을 탐지하고 차단하는 솔루션까지 로드밸런서에 연동하는 작업을 진행한다. WAF Web Application Firewall, 웹 서버 자원에 대해 유입되는 HTTP(S) 트래픽을 분석하고 차단하는 방화벽의 솔루션으로 AWS의 서비스들에 대해 적용할 수 있다. 적용가능한 서비스에는 대표적으로 Cloudfront, API Gateway, Application 로드밸런서가 존재한다. 해당 서비스들의 앞단에 붙는 형식으로 Access Control list를 정의하고, 탐지 Rule을 설정함으로써 내부 자원을 보호한다. ※ WAF는 프리티어 혜택을 받지 못하는 서비스이므..

이전에 pfsense를 통해 간단한 인프라를 구성하고 suricata 패키지로 IDS/IPS 구동까지 진행했었다. pfsense도 충분히 좋은 솔루션이긴 하지만, 실제로 이런 구성의 인프라를 운영하다 보니 몇가지 큰 문제가 있었다. 1. HTTPS를 적용한 경우 suricata가 트래픽을 정상적으로 분석할 수 없음 이 점이 가장 치명적으로 다가왔었는데, 막상 다 구축해두고 Exploit을 날려보니 suricata의 alert에는 해당 내용이 없어서 계속 확인해 보니 HTTP로 들어온 공격은 잡았지만, HTTPS를 타고온 공격은 잡지 못한 것을 확인했다. 관련해서 내용을 찾은 결과, suricata는 ssl inspection을 제공해주지 않는다는 것을 알게되었다. SSL inspection(SSL 가시성..

관련 이전 글 : SSRF와 Cloud Metadata -1 'Capital One'에서의 SSRF Cloud Metadata leak을 간단하게 설명했었다. 이와 유사한 취약한 환경을 구축하고 탈취 시나리오를 간단하게 살펴보자 취약환경 구축 인스턴스를 생성 후 SSRF에 취약한 Application을 올린 후, S3 bucket에 대해 full_access 권한을 갖는 IAM role을 만들고 이 인스턴스에 연결해준다. 민감정보를 담을 S3 bucket을 생성하고 object를 넣어준다. (해당 bucket은 인터넷 open하지 않음) 정말 간단하게 취약환경을 구성해 보았다. 'Capital One'의 Exploit과 동일하게 SSRF로 Metadata를 탈취해 S3 bucket의 object까지 탈취..

SSRF Server Side Request Forgery의 약자로, 직역하면 서버측 요청 위조 서버 측에서 위조된 요청을 발생시켜 직접적인 접근이 제한된 내부 서버의 자원 등에 간접적으로 접근해 데이터 유출 및 오동작을 유발하는 공격이다. 외부로 공개된 서버와 내부망에 존재하는 서비스(DB 등)로 이루어진 구조에서 외부서버가 내부서버로 보내는 요청을 외부 사용자가 임의로 변조하는데, 이때 내부서버는 신뢰할 수 있는 위치에서 전달된 Request로 확인하기 때문에 변조된 Request에 대한 응답값을 반환해준다. 주로 내부 서버에 저장된 이미지와 같은 자원에 접근하거나 외부로 Request를 발생시키는 구간에서 자주 발생하고, 사용자가 제공한 데이터(입력값, 쿠키 등등)을 서버 측에서 별다른 검증 로직없..

CVE-2021-21311 [adminer Server-Side Request Forgery] 요약 : 로그인 시 에러메시지를 통해 SSRF Exploit 가능 오픈소스 데이터베이스 관리 툴인 Adminer는 단일 PHP페이지로 구성되어있다. 4.7.9 버전부터 패치가 되었음 (patch commit) Adminer는 각 데이터베이스에 로그인할 수 있는 모듈을 각각 별도로 제작함 취약점이 발생되는 구간은 ElasticSearch와 Clickhouse 로그인 모듈로, 로그인 오류 시 나타나는 에러메시지를 통해서 내부 서버의 자원에 접근할 수 있음 취약한 버전 Adminer 4.0.0 ~ 4.7.8 선행조건 없음 분석 1. 취약한 환경 구성 Victim : ubuntu 22.04 / apache 2.4.52..

보호되어 있는 글입니다.

이전에 탐지할 객체가 담긴 이미지를 라벨링하고, 학습을 진행했었다. 이제 학습 결과를 바탕으로 모델을 추출하고, 실제 detection까지 진행해보자 모델 추출(Export) 학습을 시작했을때 결과물들이 저장될 경로인 model_dir을 실행인자로 넣어주었다. 학습이 진행됨에 따라 해당 경로에 ckpt라는 파일이 점차 쌓이는데, 이를 체크포인트(checkpoint)라고 한다. 체크포인트는 Tensorflow를 통해 학습된 모델의 구조를 제외한 변수(가중치)만을 담고있는 파일이다. 그렇기 때문에 체크포인트를 바탕으로 재학습이 가능하고, 파일 크기가 크다는 특징이 있다. 이러한 체크포인트는 크기가 커 공유하거나 Tensorflow Serving과 같은 다른 환경으로 배포하기가 힘들다. 즉, 체크포인트를 모델..

배경 클라우드 상에 운영중인 외부 서비스의 로그 모니터링을 진행하고자 했다. 모니터링 할 대상은 WAF 로그, ALB 로그, DNS Query 로그가 있었고, 추가로 해외 IP 접근 이력, 관리자 페이지에 접근한 IP 등을 모니터링 해줄 것을 요청 받았다. 사실 Cloudwatch를 통해 모니터링이 가능하지만, 더 깔끔한 UI/UX와 모니터링 방법을 원하셨고, Splunk나 ELK의 구축에는 시간도 오래걸리고, 결정적으로 사내에 모니터링 인프라를 구축할 pc가 없었다. 이에 따라 로그모니터링을 위한 외부 서비스를 추천해주셨고, 그것이 바로 DataDog였다. 서비스 소개 DataDog는 on-premise환경부터 클라우드 환경의 서버까지 통합된 모니터링(로그,이벤트)을 할 수 있는 서비스로, 깔끔한 UI..