방화벽 (FireWall)

방화벽

1. 내부 시스템과 외부 시스템 간 필터링 기능을 수행하는 프로세스

2. 보안 정책 구현

1) 외부에서 내부로의 접근 통제

2) 내부에서 외부로의 접근 통제(허용)

3) 외부의 특정사이트로만, 특정사이트에서 접근만 허용

4) 인터넷 서비스를 선별적으로 지원 등 통제

3. 요구사항

1) 접근 통제 : 

- 사내넷으로부터 모든 인터넷 접속은 방화벽에 있는 프록시를 통해 발생

- 디폴트로 명시되지 않은 모든 서비스는 금지

2) 보증 :

- 방화벽과 프록시는 민감한 호스트로 설치

- 사용자의 직접적인 로그인 방지

- 정책과 구성은 정확하게 문서화, 정기적인 모니터링

3) 로깅 :

- 상세 로그를 보존

- 치명적 에러는 경고음

4) 가용성

- 가용성을 제공하면서 이에 필요한 일(백업/복원) 수행

4. 기능

1) 접근 통제 :

- 통과 시킬 접근과 차단할 접근을 명시하고 이에 따라 수행

2) 로깅, 감사추적 (audit) : 

- 통과하는 이름과 목적에 대해 기록

- 사고 발생시 정보 확인 후 추적

3) 인증 : 

- 메시지 인증 : VPN과 같은 신뢰 가능한 통신 트래픽 메시지에 대한 신뢰성 보장

- 사용자 인증 : 패스워드,  OPT, TOKEN으로 보증

- 클라이언트 인증 : 틍정 호스트가 합법적인 호스트인지 확인

4) 데이터 암호화

- 방화벽 사이에서 전송되는 트래픽을 암호화해서 전달

5. 위협

1) IP 스푸핑

2) ICMP 폭탄

3) 위장

4) 취약하게 구성된 내부 시스템 접근

6. 방화벽이 차단할 수 없는 것

1) 바이러스 :

- 방화벽은 패킷의 IP 주소와 포트번호로 접근 제어를 수행

- 데이터  내용 자체를 검사하지는 않음

2) 악의적인 내부 사용자의 공격 

- 경계에 대한 보안 정책만 수행할 뿐 내부공격자에 대한 보안정책의 적용이 불가능함

7. Depth pf Defense (방어의 깊이)

1) 단일 지정의 한계로 (single point) 넷이 함락되는 경우가 없어야 한다.

- 가능한 한 사용자와 넷에서 보이지 않아야 하며 신뢰성 측면에서 중복 라우팅, 클러스터, RAID 등이 가용성을 위해 제공되어야 한다.

2) 자신을 통과하지 않는 통신에 대해 제어 역시 불가능 하다.

- 내부 사용자가 방화벽을 통과하는 선로가 아닌 무선이나 사설 통신을 이용하여 통신을 할 경우 우회가 가능하다.

3) 전혀 새로운 공격을 막지 못한다.

- 예측된 접속에 대한 규칙을 세우고 이에 대한 방어를 실시한다. 새로운 형태의 공격에 대한 능동적인 적용이 불가능하다.

8. 방화벽의 장점

1) 위협이 취약한 서비스에 대한 보호

- 안전하지 않은 서비스를 필터링 한다. -> 위험 감소

2) 호스트 시스템에 대한 엑세스 제어 

- 외부 네트워크에서 내부 네트워크에 있는 호스트로 접속하고자 할 때 접근 제어를 한다.

3) 보안 집중과 경제성 

- 원하는 호스트에 방화벽을 설치할 수 있다는 점에서 실제적으로는 경제적이다.

4) 네트워크 사용에 대한 로깅과 통계자료

- 엑세스를 로그에 저장하여 통계자료를 제공하여 의심이 가는 활동에 대해 적절하게 경고한다.

5) 보안 정책 구현

- 사용자와 서비스에 대한 엑세스 제어가 가능하고 엑세스 접근은 방화벽에 의해 구현된다.

6) 방화벽 메커니즘 

- 프록시 프로그램을 시작한다.

- 인바운드, 아웃바운드 패킷 필터를 수행한다.

- 모든 인바운드 트래픽은 방화벽을 직접 통과하도록 한다

- 모든 아웃바운드 트래픽은 방화벽으로 부터 시작하도록 한다.

9. 방화벽 제한점

1) 성능 측면 : 

- 방화벽이 네트워크 사용에 방해가 된다.

2) 제한성 측면 : 

- 버그가 있는 소프트웨어나 나쁜 프로토콜 등의 실제적인 문제를 해결할 수 없다. 

- 서비스 공격을 예방할 수도 없고 내부 공격을 막을 수도 없다.

3) 관리적 측면 :

- 많은 상용 방화벽의 환경설정이 매우 복잡하다.

10. 방화벽 종류

1) 패킷 필터링 : IP Layer, Transport Layer

- IP Header, Protocol(TCP, UDP, ICMP 등) 헤더의 정보 (송/수신 IP주소, 포트 번호)를 이용하여 사전에 설정된 보안 정책에 따라 해당 패킷의 통과 여부를 결정

- 강력한 로깅 및 사용자 인증을 제공하지 못한다.

2) 응용 계층 게이트웨이 방화벽 : Application Layer

- 특정 애플리케이션 서비스에 대해 내부망과 외부망을 연결해주는 중간 매개자 역할을 수행한다. 

- 클라이언트에게는 애플리케이션 서버, 애플리케이션에게는 클라이언트로부터 동작하여 둘 사이의 통신을 중계한다.

- 프록시 데몬, 프록시 게이트 웨이라고도 한다. (응용 프로그램 사용을 기록, 감사추적에 사용한다.)

- 7계층에 존재한다. (보안성 上, 성능 下, 유연성 下)

3) 서킷 게이트 웨이

- 5계층 ~ 7계층 사이

- 7계층으로 부터 패킷을 받아 커널레벨을 통해 전달한다.

- 7계층에 수정된 클라이언트가 필요하다.

4) 회선 계층 방화벽 - TCP Layer

- 세션에 기반하여 클라이언트와 서버간 가상 채널을 형성하여 데이터를 중계한다.

5) 상태 기반 패킷 검사    

- 패킷 헤더 정보에 패킷 콘텐츠 전체를 해석하여 접근 규칙을 적용

- 모든 계층으로부터 관련 정보를 획득 -> 접근 통제를 수행

- 해당 첫 패킷만을 접근 통제 규칙과 비교하여 통과 여부 결정

6)  여러 계층 조합 방식

11. 방화벽 구축 형태

1) 스크리닝 라우터

- IP/ TCP/ UDP의 헤더 부분만 분석 -> 네트워크 계층에서만 동작, 속도 下

- 상위계층 방어X, 로깅관리 X

2) 배스천 호스트 -> 방화벽이 설치된 호스트(로깅, 프록시, 방화벽 기능)

- 방화벽 역할을 수행하는 서버로 유닉스 워크스테이션이나 윈도우 NT서버가 이해 해당

- 인터넷 등의 외부 네트워크와 내부 네트워크를 연결해 주는 방화벽 시스템 역할을 수행

- 접근 제어와 인증 및 로그 기능을 제공

- 베스천 호스트가 손상되거나 로그인 정보가 누출되면 내부 네트워크를 보호할 수 없다.

- 2계층 공격 우회 가능

3) 듀얼 홈드 호스트 -> 배스천 호스트에 랜카드 2개를 설치 (내부용, 외부용)

- 베스천 호스트에서 IP 패킷 필터링X -> 프록시 기능부여

- 패킷 외부망과 내부망 간에 직접 통신 X

- 보안성 上, 투명성 下

4) 스크린드 호스트 

- 내부와 외부 네트워크에 대한 시스템

- 사용자 및 서비스 인증

- 네트워크 & 응용계층에서 방어 => 보안성, 융통성 上

- 스크리닝 라우터의 라우팅 테이블만 변경되면 방어할 수 없음

- 배스천 호스트 + 스크린 라우터 라고 보면 됨

5) 스크린드 서브넷

- 가장 보편성이 뛰어나지만, 구현하기가 어렵고, 서비스 속도가 느리다.

- 스크린드 호스트 + 듀얼홈드

12. Stateful Firewall

1) Stateless

- UDP

- IPS, Firewall가 RST 패킷을 보내면 클리어한다.

- DDOS 공격을 받으면 RST 패킷을 서버, 클라이언트에게 보낸다.

2) Stateful

- Telnet, FTP가 exit를 보내기 전까지 세션연결을 한다.

- HTTP의 경우 'get req'를 보내면 걍 끊어 버리면 된다.

- 여기서 FTP에 대해 알아보면

- 서버 : 21port       클라이언트 : 1099

- 서버 : 22port       클라이언트 : 1011

- 위와 같이 21번 포트를 기본적으로 쓰지만 데이터를 주고 받을 시에는 

- 서버는 22번 포트를 

- 클라이언트는 ANY를 쓴다.

- 따라서 연결하면 모든 포트를 허락한다는 문제점이 존재한다.

13. 방화벽 가이드라인

1) 복잡한 규칙으로 커뮤니케이션 프로토콜을 필터링을 해야 한다.

2) 통과하거나 막힌 트래픽에 대해 로깅을 제공해야 한다.

3) 방화벽은 공용인터넷의 유일한 입구와 출구여야 한다.

4) 방화벽 운영체제는 내부와 외부의 공격에 충분히 버틸 수 있어야 한다.

5) 방화벽은 LAN의 주소, 이름 등이 드러나서는 안된다.

6) 방화벽은 오로지 방화벽의 서비스만 제공해야 한다.

14. 방화벽 취약점

1) 디도스, 도스에 취약함

 - 작은 패킷, 프래그먼트 패킷

 - 해결방법: 방화벽을 로드 밸런싱, 네트워크 백업, 업그레이드 한다.

 - 안티 디도스 장비를 사용한다

2) Well-known weakness

 - 웹쉘 백도어 컨트롤

 - P2P

 - 웹하드

15. High Availablity

높은 가용성을 위해선??

1) DNS라운드 로빈

 - 실제로 공평하게 분배되지는 않는다.

2) L4 스위치 로드 밸런싱

 - 균형을 맞춰준다.

3) 방화벽 로드 밸런싱

 - 걸러지는 것을 가지고 균형을 맞춘다.

 - 하지만 널리 사용되지는 않는다. 

 - 보통은 L4, L7밸런싱을 쓴다. 

 - 많은 접속이 들어올 시 방화벽은 모든 연결을 할 수 없고 다운되어 버린다. 

 - 그러면 모든 연결된 네트워크는 고립되어 버리기 때문에 네트워크는 반드시 살아있어야 한다.

4) 바이패스 스위치

 - 방화벽이 살아있는지 계속 확인한다. 

 - 만약 다운될 시 우회경로를 통해 그냥 바로 스위치로 연결시킨다.  

 - 일단 살아있어야 하는 것이 중요하기 때문에..

5) L2 fallback

 - IPS, WAF, 방화벽이 되어 모두 체크한다. 

 - 들어오는 트래픽을 체크하고 퍼포먼스도 체크 한다. 

 - 모든 기능을 포기하게 되면 L2스위치가 되어 바로 통신한다. 

 - 만약 CPU가 95퍼센트가 되면 자동적으로 L2 스위치모드로 변경된다.

6) 방화벽 + L4/L7 스위치

- 방화벽을 여러대 두어 L4/L7이 공평하게 분산시켜 준다

- 만약 분산되다가 한쪽이 죽을 경우 자기가 맡고 있는 것을 다 날려주고 죽는다.

7) 만약 L4 스위치가 없다면

 - L4스위치는 매우 비싸다. 

 - 따라서 스위칭 없이 2개의 방화벽이 서로 대화하면서 서로의 상태를 체크한다. 

 - 만약 한쪽이 최대에 도달하면 대답할 수도 없는 지경에 이른다. 

 - 그렇기 때문에 방화벽의 성능이 낮아지게 된다.

8) L4/L7을 이용한 로드 밸런싱

 - L4/L7 스위치도 위험하니까 로드밸런싱을 해준다.

 - 하지만 돈이 많이 들고 문제가 생기면 어느쪽에서 문제가 생긴지 알 방법이 없다.. 

16. 차세대 방화벽

 - 이제 방화벽이 각각의 어플리케이션프로토콜을 알아서 막아야 한다. 

 - 커스텀필터를 제공하여 관리자가 그 기능을 넣는 방식으로 가야한다. 

 - 1계층부터 7계층 까지 모든 패킷을 볼 수 있고 지속적으로 네트워킹할 수 있어야 한다.

 - 정보누출, 내부위협, 복잡한 패킷교환 때문에 차세대방화벽은 80번포트를 제외하고 

 - 그외 포트는 모두 막으면서 유연한 방식과 사람의 행동에 근접하게 바뀌어야 한다.

 - 차세대방화벽은 웹방화벽이 아니다. 

 - 왜냐하면 WAF는 오로지 HTTP만 방어할 수 있기 때문에 일반적이지 않기 때문이다.

17. WAF (web application firewall)

1) surgical control of web traffic (IP주소, 메소드, 파라미터, 페이지 이런 것을 방화벽에 저장?)

2) high performance

3) HTTPS 모니터링, 발견하고 블록 기능..