웹 애플리케이션
방화벽에 대해 좀 더 깊이 들어가보겠습니다
AWS WAF에서는 웹 ACL을 생성할 수 있는 옵션이 제공되며
그리고 여기서 규칙을 만드는데
여러분들이 악의적이라고 생각되는 방식으로 API를 악용하거나
접근하는 것을 방지하는 규칙을 생성하게 됩니다
또 하나 보여드릴 것은 IP 집합입니다
웹 ACL을 생성하기 위해
IP집합에서부터 시작하겠습니다
IP 집합은 IP의 집합으로
지금 이 UI에서는 리전을 선택해야 하기 때문에
예를 들어서 프랑크푸르트로 골라보겠습니다
Create IP set을 누르고
이 IP 집합을 MyCorportateIPS라고 부르겠습니다
이 IP 집합에 포함되어 있을 것으로 생각되는
IP의 집합을 작성할 것입니다
IPv4나 IPv6 형식입니다
그런 다음 CIDR을 정의하는데 10.0.0.0/32로 하거나
고유 IP를 등록할 수도 있습니다 예를 들어
165.44.35.32/32로 말이죠
그리고 아마 이것이 전체 CIDR일 수 있으니 /24나 원하는 아무 것이나 입력하면 됩니다
퍼블릭 IP나 프라이빗 IP 주소가 될 수 있습니다
한 줄에 CIDR을 하나 작성하면 됩니다
이 IP 집합을 곧 사용하겠지만
지금은 보시는 것처럼
프랑크프루트 리전에서 MyCorporateIPs를 생성했습니다
다음은 WAF의 Web ACLs를 살펴보겠습니다
다시 한 번 여러분이 있는 리전을 선택해야 합니다
저는 유럽 프랑크푸르트를 선택하겠습니다
왜 이게 오른쪽에 없는지 모르겠지만
어쨌든 시작 해보겠습니다
웹 ACLs를 생성해보겠습니다
이름을 MyDemoProtections라고 하고
이건 CloudWatch 지표와 연관이 있습니다
그리고 저희가 연결할 수 있는 리소스 유형 중 하나는
CloudFront 배포인데
그 경우 us-east-1에서 해야하며
다른 하나는 리전별 리소스입니다
Application Load Balancers, AWS AppSync GraphQL APIs,
Amazon API Gateway REST APIs,
혹은 Cognito user pools 중 보호하고 싶은 리소스를 선택하시면 됩니다
지금은 리전별 리소스를 보호하고 싶으니
리전을 선택하겠습니다
그리고 선택적으로 예를 들어 ALB를 생성했다면
이 UI나 여러분이 보호하고 싶은 것들을
추가하면 됩니다
이것을 시험삼아 추가할 수 있지만
하지만 Application Load Balancer를
여기 넣을 필요는 꼭 없습니다
WAF의 규칙 생성을
보여드리고 싶습니다
이제 연결된 ACLs를 생성했으니
규칙과 규칙 그룹을 추가해야 합니다
이건 WCUs라는 것인데
규칙 용량 단위를 지칭합니다
여기에는 5,500 단위가 초과되면 안되는데
그 이유는 그러지 않으면
너무 많은 처리 능력을 요구하고
실제로 요청을 처리하는 데
충분한 시간 내에 모든 규칙을 통과할 수 없기 때문입니다
이제 규칙을 추가해야 하는데
두 개의 옵션이 있습니다
먼저 관리형 규칙 그룹을 추가할 수 있는데
AWS 관리 규칙을 포함할 수 있고 살펴볼 수 있는데
예를 들어 Bot Control이나 무료 규칙 그룹이 있습니다
이것들은 유료이지만 아래 이것들은 무료입니다
그리고 이들 중 하나는 예를들어 Known bad inputs나
SQL database등이 있지만
최대이기 때문에
그래서 비용은 200 크레딧이 들거나
어떻게 WordPress 애플리케이션을 보호하는지 등이 있습니다
하지만 고유 사용자 지정 규칙을 생성할 수 있습니다
그리고 이것이 제가 보여드리려는 것입니다
여기 세 가지 옵션이 있는데
IP 집합으로 작동할 수 있습니다
어떤 경우에는 IP 집합을 선택할 수 있습니다
예를 들어 저희가 생성한
이 IP 집합은
단순히 Allow, Block, Count 그리고 CAPTCHA
혹은 challenge 작업이 있습니다
이건 꽤 간단합니다
허용하고 싶다면 Allow를 선택하면 되고
이 IP 집합에서 뭔가를 차단하고 싶다면
그것들도 차단할 수 있습니다
하지만 IP 집합 이외의 것을 차단하고 싶다면 어떻게 할까요?
이 UI에는 옵션이 없습니다
규칙 빌더를 사용해야 하는데
규칙 빌더를 사용하면
IP 집합 외의 모든 것들을
차단하라고 할 것입니다
그리고 이것은 일반 규칙이고 조건은
만약 요청이 설명과 일치하지 않고
설명이 제 IP 집합의 IP 주소에서 시작된다는 것입니다
그래서 저희는, "만약 이 요청이 제 IP 집합에 있는
IP에서 온 게 아니라면 차단하세요"라고 말하는 것입니다
이번 경우에는 IP 집합 외에는 모든 것을 차단합니다
이는 여러분들이 알아야 하는 것입니다
이것을 재생산 해야 한다면 말입니다
원본 주소로 사용할 IP 주소는
소스 IP 주소에 두는 것이 제일 낫습니다
헤더에 IP 주소로 사용할 수도 있고
헤더를 지정할 수도 있지만 헤더는 수정될 수 있으므로
더 위험합니다
저희는 소스 IP 주소를 사용할 것이고
이 규칙을 추가하겠습니다
이제 IP 집합 중 하나를 제외한
모든 IP 주소를 차단합니다
다음으로 다른 규칙을 추가할 수 있습니다 저만의 규칙을 추가할 수 있습니다
그리고 다음 규칙은 RateLimiting으로 하고
속도 관련 규칙을 생성하겠습니다
이번에는 저희가
"단일 IP 주소에 5분 내에 100개의 요청이 허용되기를 원합니다
그리고 만약 이 제한에 도달하면 차단되지만
5분 후에는 차단이 해제됩니다"라고 하는 것입니다
그리고 100에서 2천만 사이로 설정할 수 있는데
100을 사용하겠습니다
그리고 저희는
"이 요청이 어디서 오는지 파악하기 위해
소스 IP 주소를 찾아봐"라고 할 수 있습니다
그 후에 모든 요청을 count 하거나
요청의 특정 하위 집합과 일치하는 요청만 count할지 선택해야 하고
그리고 이것은 설명과 일치할 수 있으며
모든 정보를 가지고 있을 수 있습니다 예를 들어
국가, 쿠키,
쿼리 매개변수 혹은 경로,
Body, 그리고 Method 등이 있습니다
그래서 여러분은 "원하는대로 다 읽을 수 있지만
5분마다 100번만 게시할 수 있어"라고 하는 것입니다
이게 이 설명에서 여러분들이 가질
것들 입니다
하지만 저희는 모든 요청을 고려할 것이고
"이걸 한 다음에 차단해"라고 합니다
여러분들은 또한
"이게 bot이 아니라는 것을 확실히 하고
대신에 CAPTCHA나 challenge를 하지만
차단을 할거야"라고 할 수 있습니다
이제 "이 IP 집합을 제외하고 모든 것을 차단할거야
그런데 5분 동안 100개 이상의 요청은 처리할 수 없어"
라고 하는 것입니다
마지막으로, 저희가 데이터베이스를 사용한다는 것을 안다고 하고
SQL 주입에 대해 매우 걱정이 된다면
당연히 AWS 관리형 그룹을 사용할 수 있습니다만
여러분의 고유 규칙도 추가할 수 있습니다
다시 규칙 빌더 아래로 가면
"SQL 주입을 Body에서 차단해"라고 하면 왜 제가 Body에서 말하는지 알게될 것이며 일반 규칙을 따르고 있습니다
그리고 "만약 요청이 설명과 일치한다면 그 설명은,"
이라고 하고
밑으로 스크롤을 내려서
Body를 선택하고
저희가 "원하는 일치 유형은"
다시 스크롤을 내려서
"SQL 주입 공격을 포함한다"라고 합니다
그래서 "만약 Body에
SQL 주입 공격이 있는 것처럼 보이면
차단하세요"라고 하는 것입니다
그리고 민감도 수준은 거짓 긍정을 더 많이 혹은 더 적게 원하는지 여부를
감지하는 것입니다
Low가 더 나은 선택일 때는
SQL 주입에 대한 보호가 있고
거짓 긍정에 대한 허용오차가 낮을 때이지만
SQL 공격에 대한 보호를
가장 높은 수준으로 하고 싶다면
민감도 수준을 High로 설정해야 하지만
유효한 요청이 SQL 삽입 공격으로
간주될 가능성이 있습니다
시험해 보는 것은 여러분에게 달려있기 때문에 한 번 해보시고
추천하는 방법은 High로 설정하는 것입니다 그리고 텍스트 변환을 추가할 수 있는데
예를 들어 SQL 주입 공격으로
판단되기 전에 내용을 바꾸기 위해서입니다
그래서 "이 규칙을 추가해"라고 하는 것입니다
만약 요청이 너무 크면 어떤 일이 일어날까요?
아마 계속해서
크기 제한 내에서 콘텐츠를 검사하거나
좋은 시작이죠
일치 또는 일치하지 않을 수도 있습니다
결과를 즉시 얻고 싶다면 말입니다
그래서 이 규칙을 추가하고
Body에서 SQL 주입을 차단하고
고유의 규칙을 실제로 추가하거나
쿼리 문자열에서 SQL 주입을 차단할 수 있습니다
그리고 다시 여러분들이 선택해야 할 것은
"만약 쿼리 문자열 매개변수가 모두
SQL 주입 공격과 일치한다면
민감도를 High로 하고 차단하세요"입니다
그리고 다시 원하시는 만큼 규칙을 가질 수 있고
그리고 여러분만의 방식으로 모든 요청 구성요소와
모든 설명과 가능성을 자신만의 방식으로
탐색해 보시기를 바라겠습니다
스스로 많은 것을 배울 수 있기 때문입니다
이 규칙들이 있다면
여러분이 사용 중인 용량, 즉
1500개의 WCUs중 73개를 확인할 수 있습니다
그리고 어떤 규칙과도 일치하지 않는 요청에
무슨 일이 일어나고 있는가에 대해서는
차단을 하거나
허용을 할 수 있는데 원하시는 대로 하면 됩니다
다음으로 Next를 클릭하면 규칙 우선순위를 설정할 수 있는데
어떤 이유로든 특정 규칙이 먼저 평가되지만
지금은 이 순서를 유지하겠습니다
다음으로
CloudWatch 지표가 있는데
어떤 규칙이 얼마나 일치하는지 확인하기 위해서입니다
다음으로 요청 샘플링을 원하는가 선택하는 것입니다
그러면 요청을 확인하고 샘플링 할 수 있고
어떻게 처리되는지 애플리케이션 방화벽을 통해
확인할 수 있습니다
다음으로
그리고 웹 ACL을 생성하겠습니다
여러분은 웹 애플리케이션 방화벽에 대한
첫 번째 보호 집합을 생성했습니다
또 보셔야 할 것은 규칙 그룹인데 규칙 그룹은 여러분이 실제로
이 규칙들을 그룹으로 생성한 다음
웹 ACL에 그룹을 할당할 수 있습니다
그래서 규칙 그룹을 사용해 웹 ACL을 생성하는 것이
조금 더 빠르지만 보여드리고 싶은건
어떻게 웹 ACL을 직접 생성할 수 있는가 입니다
이제 제 웹 ACL이 생성되었고
사실상 완전 삭제하고 싶습니다
왜냐하면 돈이 들기 때문입니다
비록 어떤 리소스와도 연결되지 않아도 말이죠
그래서 우선 만약 어떤 리소스와 연결했다면
하지 않아도 됐었지만 말이죠
예를 들어 여러분의 Load Balancers에서
연결 해제를 해야합니다
그런 다음
웹 ACL 자체를 가져와서
삭제할 수 있습니다
delete라고 치고 난 후
마지막으로 여러분들의 IP 집합도
삭제하시면 됩니다
이번 강의는 여기서 마무리하겠습니다
다음 강의에서 뵙겠습니다