🐾
개발자국
  • 🐶ABOUT
  • 🚲프로그래밍
    • 객체 지향 프로그래밍
    • 오브젝트
      • 1장: 객체, 설계
      • 2장: 객체지향 프로그래밍
      • 3장: 역할, 책임, 협력
      • 4장: 설계 품질과 트레이드오프
      • 5장: 책임 할당하기
      • 6장: 메시지와 인터페이스
      • 7장: 객체 분해
      • 8장: 의존성 관리하기
      • 9장: 유연한 설계
      • 10장: 상속과 코드 재사용
      • 11장: 합성과 유연한 설계
      • 12장: 다형성
      • 13장: 서브클래싱과 서브타이핑
      • 14장: 일관성 있는 협력
      • 15장: 디자인 패턴과 프레임워크
    • 도메인 주도 개발 시작하기
      • 1장: 도메인 모델 시작하기
      • 2장: 아키텍처 개요
      • 3장: 애그리거트
      • 4장: 리포지토리와 모델 구현
      • 5장: 스프링 데이터 JPA를 이용한 조회 기능
      • 6장: 응용 서비스와 표현 영역
      • 7장: 도메인 서비스
      • 8장: 애그리거트 트랜잭션 관리
      • 9장: 도메인 모델과 바운디드 컨텍스트
      • 10장: 이벤트
      • 11장: CQRS
    • 클린 아키텍처
      • 만들면서 배우는 클린 아키텍처
        • 계층형 아키텍처의 문제와 의존성 역전
        • 유스케이스
        • 웹 어댑터
        • 영속성 어댑터
        • 아키텍처 요소 테스트
        • 경계 간 매핑 전략
        • 애플리케이션 조립
        • 아키텍처 경계 강제하기
        • 지름길 사용하기
        • 아키텍처 스타일 결정하기
    • 디자인 패턴
      • 생성(Creational) 패턴
        • 팩토리 패턴
        • 싱글톤 패턴
        • 빌더 패턴
        • 프로토타입 패턴
      • 행동(Behavioral) 패턴
        • 전략 패턴
        • 옵저버 패턴
        • 커맨드 패턴
        • 템플릿 메서드 패턴
        • 반복자 패턴
        • 상태 패턴
        • 책임 연쇄 패턴
        • 인터프리터 패턴
        • 중재자 패턴
        • 메멘토 패턴
        • 비지터 패턴
      • 구조(Structural) 패턴
        • 데코레이터 패턴
        • 어댑터 패턴
        • 퍼사드 패턴
        • 컴포지트 패턴
        • 프록시 패턴
        • 브리지 패턴
        • 플라이웨이트 패턴
      • 복합 패턴
  • 시스템 설계
    • 1. 사용자 수에 따른 규모 확장성
    • 2. 개략적 규모 추정
    • 3. 시스템 설계 접근법
    • 4. 처리율 제한 장치
    • 5. 안정 해시
    • 6. 키-값 저장소
    • 7. 유일한 ID 생성기
    • 8. URL 단축기
    • 9. 웹 크롤러
    • 10. 알림 시스템
    • 11. 뉴스 피드
    • 12. 채팅 시스템
    • 13. 검색어 자동완성
    • 14. 유튜브 스트리밍
    • 15. 구글 드라이브
    • ⭐️. 캐싱 전략
    • ⭐️. 재고 시스템으로 알아보는 동시성이슈 해결방법
    • ⭐️. 실습으로 배우는 선착순 이벤트 시스템
  • 🏝️자바
    • 자바의 내부 속으로
      • Java 언어의 특징
      • JDK
      • JVM
        • 메모리 관리
        • Garbage Collector
          • 기본 동작
          • Heap 영역을 제외한 GC 처리 영역
          • (WIP) GC 알고리즘
        • 클래스 로더
      • 자바 실행 방식
      • 메모리 모델과 관리
      • 바이트 코드 조작
      • 리플렉션
      • 다이나믹 프록시
      • 어노테이션 프로세서
    • 자바의 기본
      • 데이터 타입, 변수, 배열
    • 이펙티브 자바
      • 2장: 객체의 생성과 파괴
        • item 1) 생성자 대신 정적 팩토리 메서드를 고려하라
        • item2) 생성자에 매개변수가 많다면 빌더를 고려하라
        • item3) private 생성자나 열거 타입으로 싱글톤임을 보증하라
        • item4) 인스턴스화를 막으려면 private 생성자를 사용
        • item5) 자원을 직접 명시하는 대신 의존 객체 주입 사용
        • item6) 불필요한 객체 생성 지양
        • item7) 다 쓴 객체는 참조 해제하라
        • item8) finalizer와 cleaner 사용 자제
        • item9) try-with-resources를 사용하자
      • 3장: 모든 객체의 공통 메서드
        • item 10) equals는 일반 규약을 지켜 재정의 하자
        • item 11) equals 재정의 시 hashCode도 재정의하라
        • item 12) 항상 toString을 재정의할 것
        • item 13) clone 재정의는 주의해서 진행하라
        • item 14) Comparable 구현을 고려하라
      • 4장: 클래스와 인터페이스
        • item 15) 클래스와 멤버의 접근 권한을 최소화하라
        • item 16) public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
        • item 17) 변경 가능성을 최소화하라
        • item 18) 상속보다는 컴포지션을 사용하라
        • item 19) 상속을 고려해 설계하고 문서화하고, 그러지 않았다면 상속을 금지하라
        • item 20) 추상 클래스보다는 인터페이스를 우선하라
        • item 21) 인터페이스는 구현하는 쪽을 생각해 설계하라
        • item 22) 인터페이스는 타입을 정의하는 용도로만 사용하라
        • item 23) 태그 달린 클래스보다는 클래스 계층구조를 활용하라
        • item 24) 멤버 클래스는 되도록 static으로 만들라
        • item 25) 톱레벨 클래스는 한 파일에 하나만 담으라
      • 5장: 제네릭
        • item 26) 로 타입은 사용하지 말 것
        • item 27) unchecked 경고를 제거하라
        • item 28) 배열보다 리스트를 사용하라
        • item 29) 이왕이면 제네릭 타입으로 만들라
        • item 30) 이왕이면 제네릭 메서드로 만들라
        • item 31) 한정적 와일드카드를 사용해 API 유연성을 높이라
        • item 32) 제네릭과 가변 인수를 함께 사용
        • item 33) 타입 안전 이종 컨테이너를 고려하라
      • 6장: 열거 타입과 어노테이션
        • item 34) int 상수 대신 열거 타입을 사용하라
        • item 35) ordinal 메서드 대신 인스턴스 필드를 사용하라
        • item 36) 비트 필드 대신 EnumSet을 사용하라
        • item 37) ordinal 인덱싱 대신 EnumMap을 사용하라
        • item 38) 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라
        • item 39) 명명 패턴보다 어노테이션을 사용하라
        • item 40) @Override 어노테이션을 일관되게 사용하라
        • item 41) 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라
      • 7장: 람다와 스트림
        • item 42) 익명 클래스보다는 람다를 사용하라
        • item 43) 람다보다는 메서드 참조를 사용하라
        • item 44) 표준 함수형 인터페이스를 사용하라
        • item 45) 스트림은 주의해서 사용하라
        • item 46) 스트림에서는 부작용 없는 함수를 사용하라
        • item 47) 반환 타입으로는 스트림보다 컬렉션이 낫다
        • item 48) 스트림 병렬화는 주의해서 적용하라
      • 8장: 메서드
        • item 49) 매개변수가 유효한지 검사하라
        • item 50) 적시에 방어적 복사본을 만들라
        • item 51) 메서드 시그니처를 신중히 설계하라
        • item 52) 다중정의는 신중히 사용하라
        • item 53) 가변인수는 신중히 사용하라
        • item 54) null이 아닌, 빈 컬렉션이나 배열을 반환하라
        • item 55) 옵셔널 반환은 신중히 하라
        • item 56) 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • 9장: 일반적인 프로그래밍 원칙
        • item 57) 지역 변수의 범위를 최소화하라
        • item 58) 전통적인 for문보다 for-each문을 사용하기
        • item 59) 라이브러리를 익히고 사용하라
        • item 60) 정확한 답이 필요하다면 float, double은 피하라
        • item 61) 박싱된 기본타입보단 기본 타입을 사용하라
        • item 62) 다른 타입이 적절하다면 문자열 사용을 피하라
        • item 63) 문자열 연결은 느리니 주의하라
        • item 64) 객체는 인터페이스를 사용해 참조하라
        • item 65) 리플렉션보단 인터페이스를 사용
        • item 66) 네이티브 메서드는 신중히 사용하라
        • item 67) 최적화는 신중히 하라
        • item 68) 일반적으로 통용되는 명명 규칙을 따르라
      • 10장: 예외
        • item 69) 예외는 진짜 예외 상황에만 사용하라
        • item 70) 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
        • item 71) 필요 없는 검사 예외 사용은 피하라
        • item 72) 표준 예외를 사용하라
        • item 73) 추상화 수준에 맞는 예외를 던지라
        • item 74) 메서드가 던지는 모든 예외를 문서화하라
        • item 75) 예외의 상세 메시지에 실패 관련 정보를 담으라
        • item 76) 가능한 한 실패 원자적으로 만들라
        • item 77) 예외를 무시하지 말라
      • 11장: 동시성
        • item 78) 공유 중인 가변 데이터는 동기화해 사용하라
        • item 79) 과도한 동기화는 피하라
        • item 80) 스레드보다는 실행자, 태스크, 스트림을 애용하라
        • item 81) wait와 notify보다는 동시성 유틸리티를 애용하라
        • item 82) 스레드 안전성 수준을 문서화하라
        • item 83) 지연 초기화는 신중히 사용하라
        • item 84) 프로그램의 동작을 스레드 스케줄러에 기대지 말라
      • 12장: 직렬화
        • item 85) 자바 직렬화의 대안을 찾으라
        • item 86) Serializable을 구현할지는 신중히 결정하라
        • item 87) 커스텀 직렬화 형태를 고려해보라
        • item 88) readObject 메서드는 방어적으로 작성하라
        • item 89) 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
        • item 90) 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라
    • 모던 자바 인 액션
      • 1장: 자바의 역사
      • 2장: 동작 파라미터화
      • 3장: 람다
      • 4장: 스트림
      • 5장: 스트림 활용
      • 6장: 스트림으로 데이터 수집
      • 7장: 병렬 데이터 처리와 성능
      • 8장: 컬렉션 API 개선
      • 9장: 람다를 이용한 리팩토링, 테스팅, 디버깅
      • 10장: 람다를 이용한 DSL
      • 11장: null 대신 Optional
      • 12장: 날짜와 시간 API
      • 13장: 디폴트 메서드
      • 14장: 자바 모듈 시스템
      • 15장: CompletableFuture와 Reactive 개요
      • 16장: CompletableFuture
      • 17장: 리액티브 프로그래밍
      • 18장: 함수형 프로그래밍
      • 19장: 함수형 프로그래밍 기법
      • 20장: 스칼라 언어 살펴보기
    • 자바의 이모저모
      • Javax
      • Objects
      • NIO
      • Thread
      • Concurrent
        • Atomic
        • Executor, ExecutorService
        • Interrupt
      • Assertions
    • Netty
      • 네티 맛보기
      • 네티의 주요 특징
      • 채널 파이프라인
      • 이벤트 루프
      • 바이트 버퍼
      • 부트스트랩
      • 네티 테스트
      • 코덱
      • 다양한 ChannelHandler와 코덱
      • 웹소켓
      • UDP 브로드캐스팅
    • 자바 병렬 프로그래밍
      • 2장: 스레드 안전성
      • 15장: 단일 연산 변수와 논블로킹 동기화
  • 🏖️코틀린
    • 코틀린 인 액션
      • 코틀린 언어의 특징
      • 코틀린 기초
      • 함수 정의와 호출
      • 클래스, 객체, 인터페이스
      • 람다
      • 타입 시스템
      • 연산자 오버로딩과 기타 관례
      • 고차 함수
      • 제네릭스
      • 어노테이션과 리플렉션
      • DSL 만들기
  • 🌸스프링
    • Spring Core
      • Cron Expression
      • Bean
        • Lifecycle
        • Aware
    • Spring MVC
    • Spring Security
      • 로그인 처리
      • 로그아웃 처리
      • JWT 인증 방식
      • 메소드별 인가 처리
    • Spring Data
      • Pageable
      • Spring Data Couchbase
      • Spring Data Redis
        • Serializer
    • Spring REST Docs
    • Spring Annotations
    • Spring Cloud
      • Service Discovery
      • API Gateway
      • Spring Cloud Config
      • MicroService Communication
      • Data Synchronization
    • Test
      • 테스트 용어 정리
      • JUnit
      • Spring Boot Test
      • Mockito
    • QueryDSL
      • 프로젝트 환경설정
      • 기본 문법
      • 중급 문법
      • 순수 JPA와 QueryDSL
      • 스프링 데이터 JPA와 QueryDSL
    • Lombok
      • @Data
      • @Builder
      • Log Annotations
  • 🕋DB
    • MySQL
      • CentOS7에서 MySQL 8 버전 설치하기
    • MongoDB
      • 
    • Redis
      • Sentinel
      • Cluster
      • Transaction
      • 자료구조
        • String
        • List
        • Set
        • Hash
        • Bitmaps
        • SortedSet
      • Lettuce 단일 서버, 클러스터 서버, 풀링 사용 방법
  • 📽️인프라
    • 리눅스
      • 주요 명령어 모음
    • Docker
      • Docker
      • Docker Compose
      • Docker Swarm
      • Docker Network
      • Linux에서 root 아닌 유저로 docker 실행하기
    • Kubernetes
      • 기초 개념
      • Pod
      • Configuration
      • ReplicationSet
      • Network
      • ConfigMap & Secret
      • Volume, Mount, Claim
      • Controller
      • Multi Container Pod
      • StatefulSet & Job
      • Rollout & Rollback
      • Helm
      • 개발 워크플로우와 CI/CD
      • Container Probes
      • Resource Limit
      • Logging & Monitoring
      • Ingress
      • Security
      • Multi Node/Architecture Cluster
      • Workload & Pod management
      • CRD & Operator
      • Serverless Function
      • K8S Cheat Sheet
    • Kafka
      • 카프카 개요
      • 카프카 설치 및 실습
      • Kafka Broker
      • Topic, Partition, Record
      • Producer
      • Consumer
      • Kafka Streams
      • Kafka Connect
      • MirrorMaker
  • AWS
    • AWS Console / CLI / SDK
    • IAM
    • EC2
      • EC2 Advanced
    • ELB / ASG
    • RDS / Aurora / ElastiCache
    • DynamoDB
    • DocumentDB / Neptune / Keyspaces / QLDB / Timestream
    • Route 53
    • Beanstalk
    • Solution Architect
    • S3
      • 보안
    • CloudFront
    • Global Accelerator
    • AWS Storage
    • Messaging
    • Container
    • Serverless
    • Data Analysis
    • Machine Learning
    • Monitoring
    • Security
    • VPC
    • Data Migration
    • 기타 서비스
  • 🏔️CS
    • 운영 체제
      • Introduction
      • System Structures
      • Process
      • Synchronization
      • Muitithreaded Programming
      • Process Scheduling
      • Memory Management
      • Virtual Memory
    • 네트워크
      • 네트워크 기초
      • 네트워크 통신 방식
      • OSI 7계층
        • 1계층: 물리계층
        • 2계층: 데이터 링크 계층
        • 3계층: 네트워크 계층
        • 4계층: 전송 계층
        • 5계층: 세션 계층
        • 6계층: 표현 계층
        • 7계층: 응용 계층
      • TCP/IP 스택
      • ARP
      • 데이터 크기 조절
      • WDM
      • NAT
      • DNS
      • DHCP
      • VPN
      • 네이글 알고리즘
      • 서버 네트워크
      • 네트워크 보안
        • 보안의 기본
        • 보안 장비
      • 이중화
    • 데이터베이스
      • 트랜잭션
    • 컴퓨터 구조
      • 개요
      • Instruction Set Architecture
      • Procedure Call & Return
      • Linking
      • Pipeline
      • Memory Hierarchy
      • Virtual Memory
      • Interrupt / Exception, IO
    • 자료 구조
      • Array
      • List
      • Map
      • Set
      • Queue
      • PriorityQueue
      • Stack
    • 웹 기술
      • HTTP
        • 쿠키와 세션
  • 🪂Big Data
    • Apache Hadoop
  • 🕹️ETC
    • Git
      • 내부 구조
      • 내가 자주 사용하는 명령어 모음
      • Commit Convention
    • 이력서 작성하기
    • Embedded
      • 라즈베리파이에서 네오픽셀 적용기
    • 기술블로그 모음집
Powered by GitBook
On this page
  • 보안 장비 배치
  • DDoS 방어 장비
  • DDoS 공격
  • DDoS 공격 타입
  • 동작 방식
  • 방화벽
  • 상태 기반 엔진(Stateful Packet Inspection)
  • 5-Tuple
  • 패킷 처리 순서
  • 방화벽 확인 및 관리
  • ALG
  • NGFW, UTM
  • NFV
  • IDS / IPS
  • IDS
  • IPS
  • WAF
  • 샌드박스
  • NAC
  • IP 제어
  • 접근 통제
  • VPN
  1. CS
  2. 네트워크
  3. 네트워크 보안

보안 장비

Previous보안의 기본Next이중화

Last updated 1 month ago

보안 장비 배치

  • 데이터 센터에서는 보안 장비를 디자인할 때 DDoS - 방화벽 - IPS - WAF 형태와 같이 여러 단계로 공격을 막도록 인라인 상에 여러 장비를 배치한다.

DDoS 방어 장비

  • DoS 공격이란 Denial of Service, 즉 다양한 방법으로 공격 목표에 서비스 부하를 가해 정상적인 서비스를 방해하는 기법이다. 공격 출발지로부터 공격을 하므로 탐지가 쉽고, 탐지를 하기만 한다면 IP 주소 기반으로 방어가 가능하다.

DDoS 공격

  • DDoS 공격이란 탐지를 회피하고 더 짧은 시간 안에 공격 성과를 내기 위해 다수의 봇(bot)을 이용해 분산 공격을 수행하는 기법이다.

  • 초기 DDoS 공격은 시스템이나 네트워크 장비의 취약점을 타겟으로 했지만, 점차 인프라 기반 서비스 제공 영역까지 확대되었다. 이후에도 다양한 DDoS 공격 형태가 생겨났다.

DDoS 공격 타입

  • DDoS 방어 장비는 Volumetric, Protocol 공격을 방어하는 것이 목표이다.

Volumetric Attack

  • 회선 사용량 이상의 쓸모없는 트래픽을 과하게 발생시켜 정상적인 트래픽이 회선 사용하는 것을 방해한다.

  • 보통 미리 악성 코드로 감염시켜둔 좀비 PC를 많이 확보해 특정 시간에 특정 타깃을 공격하는 형태가 주로 발생한다.

  • 증폭 공격이란 좀비 PC를 충분히 확보하지 못하거나 강력한 DDoS 공격을 위해 수백 Gbps ~ 1Tbps 이상의 높은 대역폭 공격을 하기 위해 수행된다. 공격자가 중간 리플렉터에 패킷을 보내면 타겟 네트워크로 수십~수백 배의 공격 트래픽이 발생하게 된다.

  • 증폭 공격의 경우 DDoS 장비 하나로 방어가 불가능하므로 ISP나 Cloud DDoS 솔루션을 이용해 서비스 네트워크로 트래픽이 도달하지 못하도록 조치해야 한다.

  • 클라우드 기반 서비스 사용 시 실제 서비스 네트워크가 가려지므로 별도 보안 장비 없이도 DDoS 공격을 방어할 수 있다.

  • ex) NTP 증폭, DNS 증폭, UDP Flood, TCP Flood

Protocol Attack

  • 3, 4계층 프로토콜 스택의 취약점을 악용해 공격 대상 장비의 CPU, 메모리 자원을 고갈시켜 정상적인 서비스가 불가능하도록 한다.

  • ex) Syn Flood, Ping of Death

Application Attack

  • 7계층 프로토콜 스택의 약점, 즉 애플리케이션 취약점을 공격한다.

  • 가장 정교한 공격이며 식별 및 완화에 까다롭다.

  • 타겟과 연결을 설정한 후 프로세스와 트랜잭션을 독점해 서버 자원을 소모시킨다.

  • ex) HTTP Flood, DNS 서비스 공격, Slowloris

동작 방식

  • Volumetric 공격을 막기 위해, 트래픽 프로파일링 기법을 주로 이용하며 데이터 센터 네트워크 내부와 외부의 경계에서 공격을 방어한다.

  • 회선을 공급해주는 ISP나 네트워크 ISP와 연결되는 데이터 센터 네트워크의 가장 바깥쪽에 배치된다.

  • 탐지와 방어를 한 장비에서 수행하는 인라인 방식과 서로 다른 장비에서 수행하는 아웃 오브 패스 방식이 존재한다.

  • 프로파일링 기법은 평소 데이터 흐름을 습득해 일반적인 대역폭, 세션량, 초기 접속량, 프로토콜별 사용량 등을 저장해두고, 데이터와 일치하지 않는 과도한 트래픽이 인입되면 알림을 발생시키고 차단한다.

  • IP 평판 데이터베이스 기반으로 DDoS 공격으로 사용된 IP는 차단하는 등의 방법을 사용할 수도 있다.

방화벽

  • 일반적으로 3, 4계층에서 동작하는 패킷 필터링 장비이다.

  • DDoS 방어 장비 바로 뒤에 배치한다.

  • 네트워크 중간에 위치해 해당 장비를 통과하는 트래픽을 사전에 정의된 정책에 부합하는지 확인하여 허용/차단한다.

  • ASIC이나 FPGA와 같은 전용 칩을 이용해 가속하므로 대용량을 요구하는 데이터 센터에서도 문제없이 사용할 수 있다.

상태 기반 엔진(Stateful Packet Inspection)

  • 초기에 사용되던 패킷 필터링 방화벽에는 상태 기반 엔진이 없어 패킷의 인과 관계를 확인하지 못하고 단순히 패킷을 필터링하여 인터넷과 같이 불특정 다수와 통신할 때에는 정책 관리가 복잡해지고 보안이 약화되는 문제가 있었다.

    • 예를 들어 3 way handshake를 거친 후 통신을 해야 하는 상황일 때

      • 목적지가 불특정 다수 웹이 될 수 있으므로 외부로 나가는 목적지에 대해 모든 패킷을 허용해야 한다.

      • 외부에서 내부로 들어오는 응답에 대한 정책도 추가해야 하는데, 외부 웹사이트는 특정할 수 없으므로 출발지가 모든 IP이고 목적지 서비스 포트는 모든 포트가 되어야 한다.

      • 이런 정책 설정은 방화벽이 있으나 마나 할 정도의 설정이다.

      • 또한 방화벽은 세션을 알 수 없어 ACK이 왔을 때 이미 SYN-ACK을 보낸 상태에서 ACK을 받은 건지 알 수 없어 취약하다.

  • SPI 엔진은 패킷의 인과 관계와 방향성을 인지해 정책을 적용할 수 있어 내부 네트워크에서 인터넷으로 통신할 때 유용하게 사용된다.

  • 내부에서 외부 인터넷으로 통신을 시도해 받은 응답과 내부로 직접 들어오려는 외부 패킷을 구분할 수 있다.

5-Tuple

  • 패킷의 3, 4계층 헤더 중 Source IP, Destination IP, Protocol No, Source Port, Destination Port 를 의미한다.

패킷 처리 순서

  • SPI 엔진을 가진 방화벽은 아래 방식대로 동작한다.

  • 세션 테이블을 확인한다. 조건에 맞는 세션 정보가 테이블에 있으면 포워딩 테이블을 확인하러 간다. 세션 정보가 테이블에 없다면 방화벽 정책을 확인하러 간다.

  • 방화벽 정책을 확인하여 패킷 차단 여부가 결정된다. 만약 허용 규칙이 있다면 내용을 세션 테이블에 저장하고, 없다면 암시적인 거부 규칙을 참고해 차단된다.

  • 포워딩 테이블에서 라우팅, ARP 정보를 확인하여 조건에 맞는 정보가 포워딩 테이블에 있으면 적합한 인터페이스로 패킷을 포워딩하고, 없으면 패킷을 폐기한다.

  • OSI 3, 4계층의 세부적인 필드도 함께 확인하여 TCP 컨트롤 플래그에 따라 동작 방식이 변하거나 시퀀스와 ACK 번호가 갑자기 변경되는 것을 인지해 세션 탈취 공격을 일부 방어한다. (TCP Anti-Replay)

  • 대부분의 방화벽은 통신 전체 세션을 로그로 저장할 수 있어 어떤 통신에 문제가 생겼는지 확인 가능하다.

방화벽 확인 및 관리

  • 서버 방화벽에 의해 네트워크 통신이 막히면 다음 현상이 발생한다.

    • 서버를 구축하여 ping으로 통신이 되는지 확인하지만 응답을 받지 못하는 경우가 발생한다.

    • 이 때 동일 네트워크의 다른 서버나 다른 네트워크와도 통신되지 않을 수 있다.

    • 외부에서 들어오는 구간의 보안 장비에 의해 차단된 것인지 확인하기 위해 보안 장비의 로그를 봐도 보안 장비에서는 서비스 요청이 정상적으로 통과된 것으로 보인다.

  • 운영체제에서 동작하는 서버의 방화벽은 최소한의 IP 주소와 서비스 포트만 열어둔 채 나머지는 차단하는 화이트리스트 기반 정책으로 관리된다.

  • 데이터 센터 서버의 접근 제한 및 이력 관리를 위해 사용하는 서버 접근 통제 솔루션이나 데이터베이스 서버의 접근 및 세부 쿼리(Query)에 대한 제어를 위해 사용하는 데이터베이스 접근 통제 솔루션을 사용하는 경우 방화벽을 반드시 사용해야 한다.

  • 운영 망에서는 서버 앞단에 방화벽이나 IPS, IDS 보안 장비가 운영되어 호스트 방화벽 자체를 내리기도 한다. 하지만 내부 보안 강화를 위해 기본 방화벽 룰을 운영하는 것이 최근 추세이다.

ALG

  • Application Layer Gateway

  • 세션 방화벽은 세션의 방향성이 중요한 요소인데, FTP 프로토콜의 경우 컨트롤 프로토콜의 초기 접속 방향과 반대로 데이터 프로토콜이 동작하여 방화벽을 정상 통과할 수 없다.

  • 이외에도 세션 방화벽 이전에 등장했던 고대 프로토콜은 통신 중간에 방화벽이 있을 때 정상적으로 통신할 수 없는 경우가 있다.

  • 이를 해결하기 위해 방화벽에서 애플리케이션 프로토콜을 확인하고 필요에 따라 세션을 인지해 포트를 자동으로 열어주는 기능을 제공한다.

  • 모든 프로토콜에 맞추어 개발될 수는 없으므로 ALG가 프로토콜이 방화벽을 통과하지 못하는 문제의 완벽한 해결책은 아니다.

  • 대부분 최신 애플리케이션이 방화벽이나 NAT을 고려해 개발되고 있고 STUN, 홀 펀칭 기술들이 발전하여 ALG 기능을 사용하지 않는 추세이다.

NGFW, UTM

  • New Generation Firewall, Unified Threat Management Firewall

  • 방화벽을 애플리케이션 영역까지 확장한 보안 장비

  • NGFW는 다양한 보안 장비의 기능이 논리적으로 통합되어 있고, UTM은 물리적인 여러 가지 엔진을 통합해 함께 동작하는 방식이다.

NFV

  • Network Function Virtualization

  • 네트워크 컴포넌트를 가상화해 범용 하드웨어에 적용하는 것을 의미한다.

  • 범용 x86 기반의 하드웨어에 가상화 서버 형태로 라우터, 방화벽, L4 스위치와 같은 장비를 탑재한다.

  • 전용 칩셋으로 성능을 높일 수는 없지만 서비스 체이닝 기술을 이용해 새로운 서비스를 손쉽게 추가, 삭제, 적용할 수 있다.

  • DPDK, SR-IOV와 같은 I/O 가속 기술들이 적용되면서 대형 사업자를 중심으로 실제 환경에 속속 적용되고 있지만 전용 어플라이언스(Appliance) 장비와 비교해 성능이나 기능 면에서 아직 한계가 있다.

IDS / IPS

  • 애플리케이션 공격을 방어한다.

  • IDS와 IPS는 트래픽을 적극적으로 차단하는지 침입 여부만 판별하는지와 적극적으로 회피 공격을 차단하기 위한 세션 이해 여부, Anomaly Detection로 능동적 방어를 하는지 등으로 구분된다.

  • 데이터 센터 영역의 보안을 위해 방화벽과 IPS 장비를 통합한 DCSG 장비 시장이 커지고 있다.

IDS

  • Intrusion Detection System, 침입 탐지 시스템

  • ‘방어’보다 ‘탐지’에 초점을 맞추어 개발되어 공격에 직접 개입하거나 방어하는 것이 아니라 트래픽을 복제해 검토하고 침입 여부를 판별한다.

  • 호스트 기반, 네트워크 기반 방식이 나뉜다. 호스트 기반은 운영체제에 설정된 계정에 따라 어떤 접근을 시도하고 작업을 했는지 기록을 남기고 추적한다.

IPS

  • Intrusion Prevention System; 침입 방지 시스템

  • 탐지에 초점을 맞춘 IDS와 달리 공격이 발견되면 직접 차단한다.

  • 사전에 공격 데이터베이스(Signature)를 제조사나 위협 인텔리전스(Threat Intelligence) 서비스 업체로부터 받는다.

  • 인입된 패킷이 공격 데이터베이스에 해당하는 공격일 때, 차단하거나 모니터링한 후 관리자에게 알람을 보낸다.

  • 기존에는 블랙리스트 기반의 방어만 제공했지만, 프로파일링 기반 방어 기법이 적용되고 애플리케이션 컨트롤 기능이 추가되어 이제는 화이트리스트 기반의 방어도 가능하다.

호스트 기반 vs 네트워크 기반

  • 일반적으로 네트워크 기반 시스템을 사용한다. (NIPS)

  • 클라우드 내부 네트워크에서 NIPS 배포가 어려운 경우 호스트 기반인 HIPS를 사용하였으나, 장애 발생 시 파악이 어렵고 서비스와 리소스를 공유해야 하는 점으로 인해 NIPS로 전환하는 추세이다.

패턴 매칭 방식

  • 기존 공격이나 취약점에 대한 방식을 데이터베이스에 습득하고 최신 내용을 유지하다가 공격이 들어오면 파악한다.

  • IPS는 많은 공격 데이터베이스를 보유하고 적용해야 한다. 최신 공격 방식을 공격 데이터베이스에 빠르게 반영하는 것도 중요하다.

  • 공격 데이터베이스를 얻는 과정은 다음과 같다.

    • 허니팟(HoneyPot)이라는 취약한 시스템을 구축해 해당 장비에 들어오는 공격을 로깅한다.

    • 공격 패턴을 분석해 공격 데이터베이스로 정보를 저장한다.

  • 코드 레드 웜이라는 공격을 받으면 공격 스트링을 가진 요청이 웹 서버에 도달하기만 해도 IIS의 취약점에 의해 웹 서버가 감염된다. 감염된 웹 서버는 다른 서버로 공격하기 시작한다. IPS에는 레드 웜의 공격 패턴 데이터가 존재하여 특정 문자열을 포함하는 패킷이 들어오면 차단하여 공격을 방어한다.

  • 공격 방식에 미세한 변화가 생기는 등 변종이 발생하면 적절한 타이밍에 대응하기 어렵다.

  • 공격이 인터넷 전체에 퍼지는 속도보다 데이터베이스 업데이트 속도가 느리기 때문이다.

Protocol Anomaly

  • 데이터베이스를 통해 분명하게 공격이라고 판단하지 않더라도, 특정 기준 이상의 행위를 이상하다고 판단하여 방어하는 것을 Anomaly 기법이라고 한다.

  • 평소 관리자가 정해놓은 기준이나 IPS 장비가 모니터링해 정해진 기준과 다른 행위가 일어나면 공격으로 판단한다.

  • 웜이 감염되면 다른 타겟에 대량의 트래픽을 발생시켜 감염시키는 행위를 반복하는 형태의 공격을 방어할 수 있다.

  • 이 기능은 동적 프로파일 기능이 강화되며 DDoS 방어 장비로 진화하였다.

Profile Anomaly

  • 서비스 포트에 맞지 않는 프로토콜을 사용하면 이를 차단한다.

  • SPI 방화벽과 NAT 기능이 대중화되어 일반 사용자의 PC를 직접 공격하기 어려워졌다. 이에, 내부 사용자의 PC에 사용자가 직접 악성 코드를 내려받아 실행하도록 유도하여 공격을 시도한다.

  • 감염된 내부 PC가 외부와 공격을 위한 통신을 할 때 실제 해당 서비스 포트에서 동작하는 프로토콜이 아닌 다른 프로토콜을 사용하는 경우가 많아 이를 파악해 적절히 제어해야 한다.

NGIPS

  • IPS 장비는 네트워크 상에서 빠른 속도로 애플리케이션 레벨까지 확인하기 위해 사용하는 flow 엔진은 패킷을 모아 데이터로 변환 후 검사하지 않고 패킷이 흘러가는 상황을 모니터링해 공격을 탐지한다. 따라서 IPS 장비를 비교적 쉽게 우회할 수 있다.

  • IPS에서 오탐이 많이 발생하므로 튜닝 작업이 필요하고 별도 인력이 장비를 모니터링하고 최적화 작업을 지속적으로 수행해야 한다.

  • NGIPS(Next Generation IPS) 장비는 이러한 문제를 해결하여 다음 장점을 가진다.

    • 애플리케이션을 인지하거나 다양한 시스템과 연동 가능하다.

    • APT 공격 방지를 위한 기능이 탑재되어있다.

WAF

  • Web Application Firewall

  • 웹 서버를 보호하는 전용 장비로, 웹 프로토콜에 대해 세밀히 방어 가능하다.

  • 다양한 형태의 장비/소프트웨어로 제공된다.

    • 전용 네트워크 장비

    • 웹 서버의 플러그인

    • DC 플러그인

    • 프록시 장비 플러그인

  • IPS에서 방어 불가능한 IPS 회피 공격을 방어할 수 있다.

회피 공격


  • 공격자가 시도한 공격이 보안 장비에서는 공격으로 판단되지 않고 정상적인 통신으로 확인되지만, 공격 타깃인 피해자(Victim)에게 도착하였을 때 공격으로 동작하는 모든 공격

  • 피해자가 패킷과 데이터를 처리하는 방법과 보안 장비의 다른 부분을 집중 공격한다.

  • 예를 들어 IPS는 ATTACK이라는 단어가 들어간 공격을 방어하기 위해 해당 단어를 탐지하거나 차단하게 되어있지만, 공격자는 IPS를 우회하기 위해 단어를 여러 패킷에 쪼개 보낸다.

  • 패킷을 데이터 형태로 조합 후 확인하기 때문에 회피 공격을 막을 수 있고 데이터의 일부를 수정, 추가하는 기능을 수행할 수 있다.

샌드박스

  • 악성 코드를 관리자 PC에 우회적으로 심고 이 악성 코드를 이용해 관리자 PC를 컨트롤하는 공격이 늘었다. 이런 공격을 받을 경우, 기존 방화벽에서는 내부 사용자가 외부 서버로 통신을 정상적으로 시도한 것으로 보이므로 이 공격을 검출하거나 방어할 수 없다.

    • APT(Advanced Persistent Threat; 지능형 지속 공격)와 ATA(Advanced Target Attack; 지능형 표적 공격)가 기본적으로 이러한 방식이다.

  • 샌드박스는 API 공격을 방어하는 대표적인 장비이다.

  • 악성 코드로 의심되는 실행 파일을 가상 운영체제라는 샌드박스 안에서 실행시키고 행동을 모니터링해 악성 코드 여부를 판별한다.

NAC

  • Network Access Control

  • 네트워크에 접속할 때 인가된 사용자만 내부망에 접속할 수 있고 인가받기 전이나 승인에 실패한 사용자는 접속할 수 없도록 제어한다.

IP 제어

  • 고정적으로 할당된 IP를 관리하고, 정확히 의도된 IP 할당이 아니면 네트워크를 정상적으로 사용하지 못하게 한다.

접근 통제

  • 서버나 데이터베이스에 대한 직접적인 접근을 막고 작업 추적 및 감사를 할 수 있는 접근 통제 솔루션

  • 에이전트 기반, 에이전트리스 등의 구현 방식이 있지만 대부분 Bastion Host 기반으로 구현된다.

  • Bastion Host

    • 서버 접근을 위한 모든 통신은 Bastion Host를 통해서만 가능하다.

    • 서버 호스트의 방화벽에 배스천 호스트에서 출발한 통신만 허용하고 다른 통신은 모두 방어하도록 설정하고 배스천 호스트의 보안, 감사를 높이면 보안을 강화할 수 있다.

  • 접근 통제 솔루션들은 단순한 접근 제어뿐만 아니라 감사, 보안 이슈 대응 등을 위해 사용자가 작업한 모든 이력을 저장한다.

VPN

  • VPN 장비는 사용자 기반의 VPN 서비스를 제공한다.

  • 방화벽이나 라우터 장비에 대부분 VPN 기능이 포함되어 있다.

  • IPSEC, SSLVPN을 가장 많이 사용한다.

리눅스 서버에서 방화벽 확인 및 관리 하려면 를 참고한다.

🏔️
여기