Azure-300-301-exam

https://docs.microsoft.com/ko-kr/learn/certifications/azure-solutions-architect#certification-exam-disclaimers

Microsoft Certified: Azure Solutions Architect Expert 자격을 획득하려면 300-301 시험을 봐야한다. 그래야..별세개..

https://docs.microsoft.com/ko-kr/learn/paths/architect-great-solutions-in-azure/

이URL에서 무료교육을 할수있다.

센터에 있는 데이터를 사용한 심층 방어를 보여주는 일러스트레이션. 데이터 주변의 보안 링에는 애플리케이션, 컴퓨팅, 네트워크, 경계, ID 및 액세스, 물리적 보안이 포함됩니다.
  • 보안: 액세스 및 데이터 무결성 보호 및 규정 요구 사항 충족
  • 성능 및 확장성: 모든 시나리오의 요청에 대해 효율적으로 충족
  • 가용성 및 복구 기능: 가동 중지 시간 최소화 및 영구 데이터 손실 방지
  • 효율성 및 운영: 유지 관리 극대화 및 요구 사항 확인은 모니터링을 통해 충족

보안

 CIA 중 하나 이상을 구현할 수 있습니다.

# 예제 원칙
1데이터Azure Blob 스토리지의 미사용 데이터 암호화무결성
2애플리케이션SSL/TLS 암호화 세션무결성
3컴퓨팅정기적으로 OS 및 계층화 소프트웨어 패치 적용가용성
4네트워크네트워크 보안 규칙기밀성
5경계DDoS 보호가용성
6ID 및 액세스Azure Active Directory 사용자 인증무결성
7물리적 보안Azure 데이터 센터 생체 인식 액세스 제어기밀성

curl-openssl_4 to openssl_3

php-curl-openssl 모듈을 사용하게 될 경우 컴파일을 하면 문제가 생겼다.

ubuntu 16 / apache 2.4 / php 5.3 / curl 7.49 / openssl 0.9.8zh

모두 컴파일 된 상태였다.

이과정에서 php 는 CURL_OPENSSL_4 이 아닌 CURL_OPENSSL_3을 요구했고 수정하는 방법이다.

vi  curl-7.54.0/lib/libcurl.vers

HIDDEN
{
local:
__; _rest;
_save*;
};
CURL_OPENSSL_4 -> CURL_OPENSSL_3
{
global: curl_*;
local: *;
};

CURL_OPENSSL_4 부분을 CURL_OPENSSL_3 으로 수정해서 컴파일 하자.

./configure --prefix=/usr/local/curl --with-ssl=/usr/local/openssl --enable-versioned-symbols

mv /usr/lib/x86_64-linux-gnu/libcurl.so.4 /usr/lib/x86_64-linux-gnu/libcurl.so.4.orig

ln -s /usr/local/curl/lib/libcurl.so.4.4.0 /usr/lib/x86_64-linux-gnu/libcurl.so.4

aws-linuxer의 블로그 톺아보기

그 동안 블로그를 운영하면서 블로그에 이것저것 적용해 보느라 시간 가는줄 몰랐다.

대략적인 블로그의 구성도를 그려보았고 구성도를 하나하나 풀어보는 시간을 가져보려한다.

먼저 내블로그는 apm 으로 이루어진 상태였다. 프리티어로 도메인도 없는 상태였고 그냥 테스트 용도 였다.

그 블로그를 먼저 rds 로 분리를 진행 했다.

인스턴스한대에 apache + php + mariadb 였던 구성에서 mariadb 를 rds 로 옮겼다.
그리고 php를 php-fpm 으로 교체 했다.

이시기엔 그냥 구성만 진행하려던 시기라 뭔가 많이 붙이지 않았다. 이 다음 과정에서 로드벨런서를 붙였다.

ALB를 붙이고 나서 letsencrypt 로 인증서를 붙일가 구매를 할까 고민을 하였으나 결국 ACM을 사용하였다.

ALB는 여러개의 인증서를 사용할수 있고 ACM 은 한개의 인증서당 여러개의 도메인을 넣을수있다. 나는 linuxer.name / *.linuxer.name 루트도메인과 와일드카드로 이루어진 두개의 도메인을 acm으로 사용하고 있다.

이다음 진행한 설정을 s3 upload 다.

s3로 이미지를 업로드하고 cloudfront 로 응답한다. 블로그의 응답속도가 굉장히 올라갔다.

cdn.linuxer.name 도메인은 acm 을이용하는데 버지니아 북부에 acm을 설정해야 한다.

업로드 설정을 마친 다음에는 HA를 구성해 보았다. 이과정에서 redis 나 세션을 공유하기 위한 고민을 하였는데 사실 로그인은 나만해서 의미가 없었다. 또한 upload 도 s3로 해서 그냥 정말로 인스턴스만 만들고 대상그룹에 추가만 하면 바로 multi zone 구성이 바로 되었다. 단순한 wp! 칭찬해

그다음엔 지금도 수시로 테스트위해서 켜고 끄는RDS의 multiaz 진짜 고가용성을 위해선 아니고 그냥....썼다.

이부분은 두가지 이유떄문에 설정을 진행했는데, 먼저 중국의 해커가 너무 접근이 많았다. 또한 블로그에 매일 비아그라 광고가 봇도아니고 손으로 직접올리는 사림이 있었다. IP는 신기하게 매번 조금씩 달랐지만 댓글을 좀 지우다가 귀찮아서 결국 국가 차단을 계획했다.

지오로케이션을 지용하여 중국과 스패머의 국가를 Null 로 라우팅 하였다.

중국과 스패머의 국가 이외엔 cloudfront 로 접근된다.
일반적인 캐싱이나 CDN이 아니라 dynamic cdn 방식이다. 조금이라도 ALB로 빨리 접근하기 위한 방법이나 ...효과는 잘...아마 한국이라 그럴거다.

cf 는 버지니아 북부의 acm을 이용하여 도메인을 인증하고 인증된 도메인은 waf 연결된다. waf는 서울리전의 alb에 연결되어있다.

유저는 그럼 route53을통해 cf에 연결되어 waf 를 통과하고 alb에 연결되어 web ec2에 연결되고 rds의 데이터를 읽어서 페이지를 볼수있는거다.

생각보다 설명이 길었는데..아무튼 뭔가 많다.

대략적인 블로그의 구성도를 그리고 역할을 설명하였다.

내블로그지만 나름 재미있게 가꾼거 같다.

즐거운 저녁되시라!

aws-waf.ver2-review-2-test

Hostcenter 의 Acunetix 취약점 점검툴을 사용하였습니다.

https://www.hostcenter.co.kr/Security/security01.aspx

aws waf.ver2 관리형룰의 성능을 테스트 하고 싶었다.

마침 회사에 web 취약점 점검툴이 있었다. 그래서 테스트를 진행했다.

먼저 COUNT 모드로 점검을 진행했다.

총 점검시간 4시간 15000번의 리퀘스트가 있었다. 첫번째 테스트는 1월10일 두번째 테스트는 1월 30일 이었다.

빨리 진행하고 싶었는데 좀 바빳다.

1월10일 모니터링 모드 스캔 결과
1월 30일 차단모드 스캔결과

간략한 결과로만 봐도 high단계의 취약점이 사라리고 medium 단계의 취약점이 하나 사라졌다.

그럼 어떻게 막혔는지 리뷰를 해야하는데...

일단 테스트시간에 막힌 리퀘스트는 3000개 정도. 15000만건중 20%정도가 막혔다.

Description
Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications and common Common Vulnerabilities and Exposures (CVE).
Capacity: 700

룰중 가장 많은 Capacity 를 사용하는 AWS-AWSManagedRulesCommonRuleSet 룰에서 역시나 많은 지분을 차지했다.

분석결과를 설명하기 보단 waf 를 사용해서 확인한 취약점리포트의 일부를 공개하는쪽으로 블로깅을 마친다.

waf 사용전

waf 사용후

블로깅이 좀 애매한데 다음엔 로깅을 남겨서 다음 포스팅을 준비해보겠다.

aws-waf.ver2-review-1-setup

waf 가 리뉴얼 되어 ver2로 돌아왔다.

그동안엔 cloudformation을 이용하여 waf 사용했는데 이젠 그럴필요가 없어졌다.

https://github.com/aws-samples/aws-waf-sample
이전에 사용하던 방법

또한 매니지드 룰을 제공하여 어느정도 패턴까지 지원해서 아주 긍정적이고 사용이 간단하며, 비용 또한 여타 웹 방화벽들보다 굉장히 싼편이라 적극 추천을 한다.

미사여구는 여기까지. 먼저 설정하는 방법을 설명하겠다.

불편한 점은..

ACL 확인시에 페이지르 변경하게 되면 리전설정을 매번 다시해줘야한다는거..

overview 가 갱신이 느리다는거...완전 답답..그래도 거의 실시간으로 차단된부분을 보여주는거나

이렇게 그래프에서 드래그를 하면 그시간대에 발생한 로그만 따로 보여주는점 등은 매우 사용자 친화적이라 할수있다. 그리고.

이런식의 차단내용을 보여주는것을 보면 Waf 로의 역할을 다한거라 생각한다. 물론
로그설정을 하지 않으면 3시간 분의 로그만 보여주는점을 생각하면...좀 불편한 점도 있지만 가격이 모든것을 말해준다. 먼저 ACL 5$ rule 하나당 1$ 내가 사용하는 룰이 7개니까 12$ 100만건당 0.6$ 거의 13$면 한달동안 waf를 사용할수 있는거다.

셋팅은 두가지로 나뉜다.

Resource type를 cloudfront 로 설정하면 cf에 적용되고 regional 로 설정하면 리전기반 ALB 나 API gw에 연결된다.

acl을 생성하고 리소스를 연결하는 것을 추천한다. 가끔이 아니라 생성하면서 여러차례 연결에러가 발생했다. 생성은 잘되는데 연결하다 에러가 나서 단계별로 하자.

관리형 룰을 사용할수 있고 IP차단의 경우엔 own rule 로 설정할수 있다.

관리형룰은 4가지로 나눠지며 나는 aws 관리형 룰만 사용중이다.

Add to web ACL 을 활성화 하면 룰을 사용하게된다. 바로 차단모드로 작동한다. 그렇기에 모니터링을 진행한 후에 차단하고 싶다면 Set rules action to count 를 활성화해서 count 모드로 사용한다. 매우중요하다.

관리형룰은 WCUs라는 단위로 사용할수있다. 기본으로 1500을 사용가능하다. 사실 룰을 덕지덕지 발라서 테스트하려고 했으나...까였다..

증가 안해줬다ㅠㅠ

22일정도 사용중인데 심플한 사용법이 일반사용자도 편하게 만들어져서 긍정적이라 생각한다 또한 cloudwatch로 공격이나 룰의 사용지표를 확인할수 있다.

이건 사용후기고 이 다음 포스팅은 웹취약점 점검툴로 waf의 관리형 룰을 테스트한 내용을 포스팅 하겠다.