
네트워크 보안의 목표는 외부로부터 내부 네트워크를 보호하는 것이다. 이때 보호 받아야 할 네트워크를 Trust network, 외부 네트워크를 Untrust network, 내부 네트워크지만 외부 사용자에게 개방 해야할 네트워크를 DMZ network라고 하고, 인터넷에 공개되는 서비스를 DMZ에 배치한다.
네트워크 보안 분야를 트래픽의 방향과 용도에 따라 두 가지로 나누면 다음과 같다.
네트워크 보안 정책에 따라 두 가지로 분류할 수 있다.
DDoS 방어 장비는 Volumetric Attack을 막기 위해 네트워크의 내부와 외부 경계에서 공격을 방어한다.
Volumetirc Attack은 Traffic을 과도하게 발생시켜 회선 사용을 방해하는 공격이므로 회선 공급을 담당하는 ISP 또는 ISP와 연결되는 네트워크의 가장 바깥쪽에 위치시켜 공격을 방어 해야된다.
L4에서 동작하여 L3, L4 정보 기반으로 정책을 수립한다. 일반적으로 DDoS 장비 바로 뒤에 놓는다.
IDS(Intrusion Detection System), IPS(Intrusion Prevention System)는 Application 공격을 막는 장비로 현재 IPS로 통일해서 부른다.
Signature를 기반으로 차단하거나 모니터링 후 관리자에게 알리는 방식으로 동작한다. 이전엔 블랙리스트 기반 방어만 제공했지만 Application Control 기능이 추가되며 화이트리스트 기반 방어도 제공한다.
Web server 보호 전용 장비로, web protocol의 공격을 방어한다. IPS보다 범용성이 떨어지지만 protocol 단위에서 더 세밀히 방어할 수 있는데, HW, SW 형태로 제공된다. WAF는 IPS 회피 공격을 방어할 수 있다. WAF는 proxy 서버와 같이 packet을 데이터 형태로 조합해 처리하기 때문에 회피 공격이 쉽지 않다.
Network 접속 장치의 제어를 위해 개발된 장치.
할당된 IP를 관리하고 의도된 IP 할당이 아니면 정상적으로 동작하지 못하게 하기 위한 솔루션이다.
Firewall는 network 중간에 위치하여 통과하는 트래픽을 사전에 주어진 정책에 맞춰 허용 또는 차단하는 장치를 의미한다.
장비에 등록된 정책(ex. 5-tuple)만으로 패킷을 필터링하는 방식으로 동작했다. 불특정 다수 기반 정책을 정의할 때 ruleset이 복잡해지고 보안이 취약하다는 문제가 있다.
취약점이 존재하지만 동작이 간단하여 부하가 적다는 장점이 있어 현재는 SPI엔진으로 위 문제를 해결했지만, 초기 방화벽 모델을 사용하는 것이 아니라 블랙리스트 처리를 위해 내부 필터링 엔진과 함께 동작시킨다.
기존 packet filter에 그치는 것에서 넘어 세션 기반으로 동작하는 SPI엔진이 개발되었다. SPI는 packet 상태를 인지해 인과 관계를 파악할 수 있어 불특정 다수 기반 정책을 따르고 보안성을 확보할 수 있다.
SPI 기반 방화벽은 애플리케이션 헤더 정보를 인지할 수 없는데, FTP 같이 data protocol과 control protocol이 반대로 동작하는 고대 protocol 같은 경우는 정상적으로 통신이 불가능하다.
이 문제 해결을 위해 FTP는 기본 Active mode 대신 Passive mode가 개발됐는데, mode 전환이 안되는 application 또는 이미 개발된 서비스에 경우 변경이 불가능한 경우가 있다. 이를 위해 필요에 따라 세션을 인지해 port를 자동으로 열어주는 ALG(Application Layer Gateway)기능이 개발됐다. 현재는 이러한 상황을 고려해 개발하기 때문에 오래된 protocol을 제외하면 ALG 기능도 잘 쓰지 않는다.
방화벽은 L3, L4 정보를 기반으로 동작하기 때문에 애플리케이션 영역은 알지 못한다. 하지만 공격은 보통 애플리케이션 영역에서부터 시작되고 방화벽은 이 영역을 검사할 수 없기 때문에 worm, backdoor와 같은 공격을 방어할 수 없다. 이에 대한 해결책으로 IPS가 개발됐다.
방화벽은 L3, 4 방어만 가능하므로 한계점이 분명했다. 이를 위해 IPS가 등장했고 IPS는 L3부터 L7 Application 영역까지 방어가 가능하게 설계됐다.
기본적으로 Signature 기반 패턴 매칭 방식으로 운영되지만 Protocol Anomaly, Profile Anomaly 등 다양한 기법으로 공격을 방어한다.
Signature 기반 패턴 매칭 방식은 극미한 변화도 빠르게 반영할 수 있어야 의미가 있지만 그러지 못해 적절하지 않다. 이에 새롭게 개발된 방식이 Anomaly로 Signature와 달리 화이트 리스트 기반 방어 기법이고, 분명한 공격이 아니어도 특정 기준 이상의 행위를 이상으로 판단하고 방어한다.
이 기법은 profile, protocol anomaly로 구분한다.
네트워크상에서 빠른 속도로 애플리케이션 레벨까지 확인을 위해 Flow engin을 사용한다. 이는 packet의 흘러가는 상황을 모니터링해 공격을 탐지하는 장치여서 쉽게 우회할 수 있다.
또한 IPS는 오탐이 많아 초기 설치된 환경에 맞춰 튜닝을 오래 해줘야한다는 단점이 있다.
이러한 단점을 보완한 장비인 NGIPS(Next Generation IPS)가 출시됐다. APT 공격을 방어하기 위한 기능도 일부 탑재 되어 있고 다양한 외부 시스템과 연동이 가능하다.
SPI 엔진 개발 이후 공격자 단독으로 하나의 서비스 이용을 방해하는게 제한이 많기 때문에 다수 공격자를 만들어 DoS공격을 하는 DDoS 공격으로 발전했고, 이를 막기 위해 DDoS 전용 장비가 만들어졌다.
볼류메트릭 공격이 증가함에 따라 DDoS 공격 방어를 위한 별도 장비의 필요성이 대두됐고, DDoS 전용 방어 장비가 도입됐다. 주로 트래픽 프로파일링 기법을 사용하고, 다양한 공격 정보를 수집한 DB를 활용하기도 한다.
DDoS 방어장비는 크게 탐지 장비와 방어 장비를 구분한다. 공격을 탐지하여 공격 수행 IP를 넘기면 ISP 내부에서 IP를 버리는 것이 가장 흔한 방어 기법이다.
- 프로파일링 기법
평시 데이터 흐름을 학습할 때 대역폭, 세션량, 초기 접속량, 프로토콜별 사용량 등과 같은 정보를 학습하여 이와 일치하지 않는 과도한 트래픽이 들어오면 차단한다.
DDoS 공격 유형은 크게 세 가지로 나눌 수 있다.
서비스 제공을 위한 인프라의 목표는 더 가용성이 높은 서비스에 필요한 인프라를 안정적으로 제공하는 것이다.
이를 위해 인프라 설계시 SPoF(Single Point of Faliure)를 만들지 않아야 하는데, 하나의 장애가 전체 서비스로 퍼져 전체 서비스에 대한 장애가 발생할 수 있기 때문이다.
위와 같은 이유로 인프라를 구성하는 모든 요소에 대한 이중화는 필수적이다.
1990년대 각 벤더별 장비 간 대역폭을 늘리기 위해 독자적으로 구현했지만, 이는 다른 장치와 연결시 호환성 문제를 발생시켰다. 따라서 링크 계층의 표준화를 진행했는데, 이를 LACP라고 한다.
LACP는 대역폭 확장을 통해 다음 두 가지를 제공하는 것을 목표로 한다.
LACP를 통해 논리 인터페이스를 구성하려면 LACPDU(LACP Data Unit) 프레임을 사용한다. LACPDU는 src, dst, type, subtype, version 등을 포함해 매초 주고 받으며 LACP를 구성한다.
LACP 연결을 위해선 LACPDU를 주고받는 장비가 하나여야 한다. LACP 구성 두 개 이상의 물리 인터페이스가 서로 다른 장비에 연결되어 있다면 이중화 구성을 할 수 없다. 또한 LACPDU를 보내려면 LACP 설정이 있는 장비에서만 가능하다.
LACP 설정은 두 가지 모드가 있다.
PXE
PXE는 OS가 설치되지 않은 환경에서 네트워크를 통해 부팅할 수 있도록 하는 기술이다.
LACP는 Bonding, Teaming에서 active-active로 사용하기 위한 옵션이다. 하지만 Bonding과 Teaming은 서버 OS에서 설정하는 것이므로 PXE로 OS 설치시에는 사용할 수 없다. 따라서 일반 인터페이스로 설정하여 PXE로 os를 설치하고 이후에 다시 설정을 해줘야 한다.
서버에서 인터페이스 이중화하는 방식은 OS별로 다른데, 대표적으로 Window는 Teaming, Linux는 Bonding이라고 한다.
Linux Bonding은 0~4까지 있는데, 주로 mode1: Active-Standby, 4: LACP를 사용한다.
평시에 Active 인터페이스에서 통신을 하다가 Active에 장애가 생기면 standby 인터페이스가 자동으로 활성화 되어 통신을 이어가는 방식으로, Active 인터페이스가 다시 활성화 되면 자동으로 통신을 이어 받거나 수동으로 다시 설정할 때까지 Standby가 동작하는 방식이다.
Ubuntu에서 bond 설정을 위해 ifenslave패키지가 설치되어 있어야 한다.
apt-get install ifenslave
kernel module에 bonding이라는 값이 있어야 하고 없으면 /etc/modules에 bonding 값 추가 후 재부팅 한다. 이때 root 권한이 필요하다.
sudo vi /etc/modules # nano와 같은 editor 사용 가능
bonding
bonding 설정을 위해 /etc/network/interfaces에 eth0, eth1을 bond0 인터페이스로 만든다.
# In /etc/network/interfaces
auto eth0
iface eth0 inet manual
bond-master bond0
auto eth1
iface eth1 inet manual
bond-master bond0
auto bond0
iface bond0 inet static
address 192.168.1.10
gateway 192.168.1.1
netmask 255.255.255.0
bond-mode 4
bond-miimon 100 # 모니터링 주기
bond-slaves none
LAPC는 물리 인터페이스 다수를 하나의 논리 인터페이스로 묶어 단일 스위치에 연결하는 방식이다.
하지만 서버를 다수의 인터페이스로 구성하더라도 스위치 단에서 문제가 생기면 SPoF가 발생한다. 서버 인터페이스를 서로 다른 스위치를 연결하는 방식이 MC-LAG다.
MC-LAG는 단일 스위치로 LACP를 구성해 대역폭을 확장할 것인지, 서로 다른 스위치로 구성해 장비 이중화로 가용성을 확보할 것인지 선택할 수 있다.
MC-LAG의 구성 요소는 다음과 같다.
MC-LAG 구성에서 peer는 data, control 두 종류의 packet을 주고 받는데, 이때 두 종류를 같은 경로를 사용할 것인지, 별도 경로를 사용할 건지에 따라 두 가지로 구성 가능하다.
Case1은 각 peer의 VLAN 인터페이스 IP를 설정하여 이를 통해 통신하고, Case2는 새로운 인터페이스를 L3 인터페이스로 구성해 통신한다.
MC-LAG 설정을 마치면 peer들은 제어 패킷을 주고 받는다. 이후 두 대는 하나의 MC-LAG 도메인으로 묶이고 VMAC 주소를 장비 간 동일하게 생성한다. 이를 통해 LACP를 구성할 수 있다.
MC-LAG를 이용해 LACP 구성시 VMAC으로 설정하고 LACPDU를 전송한다. peer들끼리 동일한 주소를 사용하여 서로 다른 장비로 LACP를 통한 이중화가 가능하다.
외부 네트워크와의 통신은 gateway를 통해야 하는데 이런 통신을 L3 통신이라고 한다. 단일 gateway를 사용한다라고 할 때 gateway에 장애가 발생하면 외부 네트워크와의 통신이 단절될 것이다. 이에 대한 해결책이 Gateway 이중화다.
외부 네트워크와의 통신을 위해 사용되는 gateway 장비를 두 대 이상의 장비로 구성할 수 있는 프로토콜이다.
FHRP 그룹을 구성하는 gateway는 물리IP는 다르지만 가상 IP는 같게 설정한다. 그룹을 구성하는 Gateway는 그룹 ID 값을 설정하는데, VIP에 대한 MAC 주소를 생성하기 위함이다. host가 gateway 주소로 ARP request를 보내면 Broadcast되어 active 상태인 gateway가 응답을 하게 된다.
FHRP를 구성하는 gateway는 active-standby 형태로 존재하기 때문에 active 상태의 gateway가 장애를 일으키면 standby 상태 gateway가 active되어 동작하게 된다.
FHRP의 표준 프로토콜은 VRRP다. VRRP 그룹 구성을 위해 VRID 값을 할당하고, VRRP를 구성하는 switch는 각각 우선순위 값도 할당받게 된다. 이후 "Hello" packet을 1초마다 전달하고 우선순위를 비교해 master를 선출하게 된다. 이때 Multicast로 전달되고 224.0.0.18을 사용한다.
Master로 선출된 장비는 VRRP의 VIP, VMAC을 갖게된다.
만약 선출된 master에서 장애가 발생하면 그룹을 구성하는 다른 장비가 master 역할을 가져가고 MAC 테이블이 갱신된다. 이때 VIP, VMAC은 바뀌지 않는다.
다음은 VRRP 설정 방법이다.
interface Vlan10
ip address 1.1.1.2/24
vrrp 10
ip 1.1.1.1
priority 110
track 1 decrement 20
preempt delay minimum 60
track 1 interface ethernet 1/1 line-protocol
interface VLan10
ip address 1.1.1.3/24
vrrp 10
ip 1.1.1.1
preempt delay minimum 60
Load Balancer의 부하분산 동작을 그린 그림이다. client가 VIP로 요청을 보내면 서비스를 구성하는 각 서버의 상태를 확인하여 적절하게 요청을 분산 시킨다. VIP는 요청이 들어올 때 요청 전달을 어디로 할건지 그룹을 설정한다. 또한 서버에서 설정한 port와 VIP에서 서비스 port가 반드시 같을 필요없고, 각 그룹별로 다른 VIP로 구성하는 것도 가능하다.
부하 분산을 하는 각 서버의 서비스 상태를 체크하는 것을 health check라고 한다. 이를 통해 장애가 생긴 서버로는 트래픽을 보내지 않고 정상인 서버로만 트래픽을 보내 정상적으로 서비스를 운영할 수 있다.
Health check 주기는 응답시간, 시도 횟수, 타임아웃 등 다양한 타이머를 함께 고려한다.
부하 분산을 하는 방식을 알아보자. 여러 방식이 있지만 RR(Round Robin), Least Connection, Hash 세 가지를 보도록 하겠다.
특별한 규칙없이 번갈아 가면서 트래픽을 보내는 방식.
로드 밸런서에서 서버로 트래픽을 보내면 세션 테이블이 생성되어 연결된 세션 수를 확인할 수 있다.
이를 통해 가장 적게 연결된 장비로 서비스 요청을 보내는 방식이다.
RR, Least Connection 방식은 트래픽이 서로 다른 서버로 가게되는데, 만약 세션을 유지 해야하는 서비스일 때 이전 트래픽과 들어오는 트래픽이 다른 서버로 간다면 세션 유지가 안되서 정상적으로 서비스를 이용할 수 없다는 단점이 있다.
Hash는 src IP, dst IP, src port, dst port 값들을 이용해 해시 알고리즘 이용해 값을 내서 어떤 장비로 트래픽을 넘길지 결정하게 된다. 해시 알고리즘에 이용하는 값이 바뀌지 않는다면 항상 동일한 값을 내므로 같은 장비로 트래픽이 가게 되어 세션을 유지할 수 있다.
로드 밸런서를 구성하는 방식엔 로드밸런서 위치에 따라 One-Arm, InLine 두 가지로 나눌 수 있다.
로드 밸런서가 스위치 옆에 있는 형태를 말한다. 그림 상에 로드밸런서와 스위치가 단일 경로로 연결되어 있지만 인터페이스 하나가 아닌 다수의 인터페이스로 구성되어 있다.
부하 분산을 하는 트래픽만 로드밸런서를 거치고, 부하 분산을 하지 않는 트래픽이면 로드밸런서를 거치지 않고 트래픽이 이동되게 된다.
따라서 One-Arm 구성에선 불필요한 트래픽이 로드밸런서를 거치지 않기 때문에 부하를 줄일 수 있고, 스위치와 로드밸런서 간 대역폭을 최소화할 수 있다.
L3 Switch부터 서버까지 하나의 경로에 있는 형태를 말한다. 이 경우 부하 분산을 하지 않는 패킷도 로드 밸런서를 거쳐 가게된다. 부하 분산을 하지 않는 패킷은 로드 밸런서에 큰 부하를 주진 않지만 이 경우 로드밸런스의 기능과 packet throughput 성능을 구별해서 디자인 해야한다.
로드 밸런서의 동작 방식은 다음 3가지다.
Transparent or Bridge
로드밸런서가 L2 스위치처럼 동작하는 구성으로 VIP와 실제 서버가 동일한 네트워크를 사용.
기존 네트워크 대역을 그대로 사용하기 때문에 네트워크 재설계를 하지 않아도 되고, 부하 분산 트래픽만 로드밸런싱을 지원하고 나머지는 스위칭만 수행한다. One-Arm, InLine 구조에서 모두 사용 가능하지만, One-Arm 구조에서 응답 트래픽 경로가 문제가 될 수 있어 Source NAT가 필요함.
부하 분산 트래픽이 흐르는 요청 과정은 다음과 같다. (InLine)
Routed
로드 밸런서를 기준으로 사용자 방향과 서버 방향이 서로 다른 네트워크로 분리된 구성이다.
보안 강화 목적으로 서버쪽 네트워크를 사설로 구성하여 서버로 직접 접속하는 것을 막는 용도로도 사용한다.
요청시 사용자가 VIP로 서비스를 요청하면 실제 IP로 변경되고 이때 출발지, 목적지 MAC주소도 모두 변경된다.
응답시에는 출발지는 서버 IP, 목적지는 사용자 IP로 설정한다. 단, 도착지 MAC 주소는 로드밸런서의 주소로 설정한다. 로드밸런서에 패킷이 들어오면 사용자에게 보낼 때 출발지 IP를 VIP로 변경한다.
DSR(Direct Server Return)
사용자의 요청이 로드 밸런서를 통해 서버로 들어가면 응답시 로드밸런서를 거치지 않고 서버가 직접 사용자에게 응답하는 방식이다. 로드밸런서는 요청 패킷에 대해서만 관여하므로 One-Arm 방식으로 구성된다.
DSR 모드는 L2, L3 DSR로 구분하는데, 실제 서버의 네트워크 대역을 로드밸런서와 공유하면 L2, 공유하지 않으면 L3 DSR이다.
보통 요청 트래픽보다 응답 트래픽이 더 커서 DSR 모드는 로드 밸런서 부하 감소에 효과적이지만, 문제 발생시 확인이 어렵다는 단점이 존재한다. 또, 로드밸런서 외에 서버에도 추가 설정이 필요하다.
사용자 입장에서 응답을 받을 때 요청한 VIP와 다른 서버의 IP로 받게 되는데, 이는 비정상 패킷으로 처리된다. 따라서 로드밸런서가 요청을 받을 때 VIP 그대로 유지하고 목적지 MAC만 서버의 MAC으로 변경해서 전송한다. 이때 패킷 수신시 목적지 IP가 서버 주소와 맞지 않으면 폐기되므로 Loop-back interface로 VIP주소를 할당하고 Loop-back으로 설정된 IP라도 수신할 수 있도록 설정한다.
마지막으로 이 VIP는 로드밸런서와 동일한 IP가 중복 설정됐으므로 MAC 주소가 갱신되지 않도록 서버에 VIP에 대해선 광고하지 않는다.