2월 5주차 회고

docs/sk-lim19f/2024-02-27.md

@@ -0,0 +1,61 @@
+# 10. 서버의 방화벽 설정/동작
+
+-   서버에 운영체제를 설치하면 리눅스나 윈도 서버 모두 운영체제의 자체 방화벽이 함께 설치됨
+-   운영체제에서 동작하는 서버의 방화벽은 서버 보안을 강화하기 위해 최소한의 서비스 포트만 열어둔 채 대부분의 서비스는 차단함
+-   방화벽은 일반적으로 필요한 IP 주소와 서비스 포트에 대해서만 열어주고 나머지는 모두 차단하는 화이트리스트 기반으로 정책을 관리함
+
+    10.1 리눅스 서버의 방화벽 확인 및 관리
+
+-   리눅스에서는 호스트 방화벽 기능을 위해 보통 iptables을 많이 사용
+
+### 10.1.1 iptables 이해하기
+
+-   시스템 관리자는 iptables을 통해 서버에서 허용하거나 차단할 IP나 서비스 포트에 대한 정책을 수립함
+-   이렇게 수립된 정책은 정책 그룹으로 관리함
+-   정책 그룹은 서버 기준의 트래픽 구간별로 만드는데 여기서 말하는 트래픽 구간은 서버로 유입되는 구간(INPUT), 서버에서 나가는 구간(OUTPUT), 서버를 통과하는 구간(FORWARD) 등을 말함
+-   그리고 이렇게 만들어진 방향성과 관련된 정책 그룹은 각 정책의 역할에 따라 다시 상위 역할 그룹에 속하게 됨
+-   정리하면 정책은 방향성에 따라 방향성과 관련된 정책 그룹으로 분류하고 이렇게 분류된 그룹들은 역할과 관련된 정책 그룹으로 다시 묶이게 됨
+-   iptables에서 개별 정책의 방향성에 따라 구분한 그룹을 체인이라고 하며 체인을 역할별로 구분한 그룹을 테이블이라고 함
+-   즉, 개별 정책의 그룹이 체인이 되고 체인 그룹이 테이블임
+-   iptables에는 필터 테이블, NAT 테이블, 맹글 테이블, 로 테이블, 시큐리티 테이블 이렇게 5가지 테이블이 있음
+-   패킷을 허용하거나 차단하는 데 사용하는 테이블이 필터 테이블
+-   여기서 다룰 리눅스의 호스트 방화벽은 이 필터 테이블을 통해 트래픽을 제어하는 것을 의미
+-   테이블에는 방향성과 관련된 그룹이 있다고 했는데 이 그룹이 체인
+-   필터 테이블에는 서버로 들어오는 트래픽, 나가는 트래픽, 통과하는 트래픽에 따라 INPUT 체인, OUTPUT 체인, FORWARD 체인이 있음
+-   각 체인에는 해당 체인에 적용될 방화벽 정책을 정의
+-   각 정책에는 정책을 적용하려는 패킷과 상태 또는 정보 값과의 일치 여부 조건인 매치와 조건과 일치하는 패킷의 허용(Accept)이나 폐기(Drop)에 대한 패킷 처리 방식을 결정하는 타깃으로 구성됨
+
+    -   Filter 테이블
+        -   iptables에서 패킷을 허용하거나 차단하는 역할을 선언하는 영역
+    -   INPUT, OUTPUT, FORWARD 체인
+        -   호스트 기준으로 호스트로 들어오거나 호스트에서 나가거나 호스트를 통과할 때 사용되는 정책들의 그룹
+        -   패킷의 방향성에 따라 각 체인에 정의된 정책이 적용됨
+    -   Match
+        -   제어하려는 패킷의 상태 또는 정보 값의 정의
+        -   정책에 대한 조건
+    -   Target
+        -   Match와 일치하는 패킷을 허용할지, 차단할지에 대한 패킷 처리 방식
+
+    10.1.2 리눅스 방화벽 활성화/비활성화
+
+-   CentOS 7, IPv4 기준
+
+```
+// firewalld 비활성화
+
+$ systemctl disable firewalld
+$ systemctl stop firewalld
+```
+
+```
+// iptables 설치
+
+$ yum install iptables-service
+```
+
+```
+// service 명령어나 systemctl 명령어로 iptables 서비스를 활성화
+
+$ service iptables start // CentOs 6
+$ systemctl start iptables.service // CentOs 7
+```

docs/sk-lim19f/2024-02-28.md

@@ -0,0 +1,186 @@
+### 10.1.3 리눅스 방화벽 정책 확인
+
+```
+// iptables의 설정값을 확인하는 명령은 -L (--list) 옵션을 사용
+
+$ iptables -L
+```
+
+```
+ACCEPT  all--  anywhere  anywhere  state RELATED, ESTABLISHED
+```
+
+-   INPUT 체인 1번 정책
+    -   첫 번째 허용 정책을 보면 RELATED, ESTABLISHED 상태인 모든 출발지에 대해 허용하도록 룰이 설정되어 있음
+    -   이미 세션이 맺어져 있거나(ESTABLISHED) 연계된 세션이 있을 때, 어떤 출발지나 목적지인 패킷이더라도 허용하는 정책
+    -   FTP는 원시적인 프로토콜이어서 컨트롤 프로토콜과 데이터 프로토콜이 별도로 동작
+    -   처음 연결된 이후 로그온, 항목 리스트 등의 실제 파일을 다운로드하기 전까지 컨트롤 프로토콜을 사용하고 실제로 데이터 다운로드 명령이 내려지면 별도로 세션을 만들어 다운로드를 시작
+    -   두 개의 연결이 별도로 이루어지다보니 방화벽 입장에서는 이 두 개의 연결을 연계시키지 못하면 제대로 통신을 할 수 없음
+    -   RELATE state를 이용해 이 두 가지의 연결을 하나로 간두하게 됨
+
+```
+ACCEPT  icmp--  anywhere  anywhere
+```
+
+-   INPUT 체인 2번 정책
+    -   ICMP에 대한 허용 정책
+    -   이 정책을 통해 ping과 같은 서비스를 사용할 수 있음
+
+```
+ACCEPT  tcp--  anywhere  anywhere  state NEW tcp dpt:ssh
+```
+
+-   INPUT 체인 4번 정책
+    -   신규 세션인 NEW state 중 목적지 서비스 포트가 SSH인 경우만 허용
+    -   간단히 표현하면 외부에서 서버로 SSH(22) 접속을 허용하는 정책
+
+```
+REJECT  all--  anywhere  anywhere  reject-with icmp-host-prohibited
+```
+
+-   INPUT 체인 5번 정책
+    -   다섯 번째 정책은 위의 첫 번째부터 네 번째 정책에 매치되지 않은 패킷들을 차단하는 정책
+    -   INPUT 체인 자체는 기본 정책이 ACCEPT로 선언되어 있지만 이 정책 때문에 화이트리스트 기반 방화벽처럼 동작하게 됨
+    -   REJECT는 곧바로 폐기하는 DROP과 달리 ICMP 프로토콜을 이용해 패킷 차단 이유를 출발지에 전달
+    -   iptables의 기본 룰에서는 icmp-host-prohibited 메시지를 이용해 해당 패킷이 차단되었음을 알려줌
+
+```
+ACCEPT  all--  anywhere  anywhere
+```
+
+-   INPUT 체인 3번 정책
+    -   iptables -L의 내용만으로 보면 모든 출발지의 모든 트래픽에 대해 허용하므로 마치 Any Open 정책처럼 보임
+    -   하지만 실제로 외부에서 들어오는 패킷은 해당 정책을 거치지 않고 최하단의 DROP 정책에서 대부분 걸러짐
+    -   iptables 설정확인
+
+```
+$ iptables -S
+```
+
+-   모든 정책에 대해 허용하는 것으로 되어 있지만 실제로 해당 정책이 적용되는 인터페이스가 루프백 인터페이스(lo)임을 알 수 있음
+-   실제 정책이 어떻게 정의되어 있는지 확인하려면 -S이나 iptables 파일을 직접 확인해야 함
+
+### 10.1.4 리눅스 방화벽 관리
+
+-   iptables에 웹 서비스가 가능하도록 http 서비스 포트를 열어주는 정책 추가
+
+```
+$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
+```
+
+-   정책을 추가하려면 -A나 --append 옵션을 사용
+-   옵션 뒤에는 어떤 체인에 적용할 것인지를 지정
+-   체인명 뒤에는 넣을 정책을 정의
+-   프로토콜을 지정하기 위해 -p(또는 --protocol) 옵션을 사용
+-   목적지 포트를 제어하기 위해 --dport 옵션을 사용
+-   출발지 포트는 --sport 옵션을 사용
+-   출발지나 목적지의 IP 주소를 제어하기 위해 -s(또는 --source), -d(--destination) 옵션을 사용
+-   IP 주소 설정을 별도로 하지 않으면 anywhere로 적용
+-   정책에 일치하는 패킷을 어떻게 처리할 것인지를 정하는 타깃 지정은 -j 옵션 사용
+-   iptables의 정책 삭제는 -A 대신 -D나 --delete 옵션을 사용
+
+```
+$ iptables -D INPUT -p tcp --dport 21 -j ACCEPT
+```
+
+-   정책이 너무 많을 때는 -L 옵션으로 일치하는 정책이 있는지 확인하기 어려우므로 -C나 --check 옵션을 사용해 해당 정책이 있는지 확인할 수 있음
+
+```
+$ iptables -C INPUT -p tcp --dport 21 -j ACCEPT
+```
+
+-   특정 위치에 정책을 추가하려면 정책의 줄 번호를 지정해야 함
+-   기본 정책 확인 명령어로는 방화벽 정책의 줄 번호를 확인할 수 없으므로 -L 옵션 뒤에 --line-number 옵션을 추가해 현재 정책의 줄 번호를 확인
+
+```
+$ iptables -L --line-number
+```
+
+-   기존 tables에 추가할 때는 -A 옵션을 사용했지만 특정 위치에 정책을 추가하기 위해서는 -I나 --insert 옵션을 사용
+
+```
+$ iptables -I INPUT 5 -p tcp --dport 80 -j ACCEPT
+```
+
+-   특정 서비스 포트에 대해 특정 IP만 허용
+
+```
+$ iptables -A INPUT -i eth0 -p tcp -s 172.16.10.10/32 --dport 22 -j ACCEPT
+$ iptables -A INPUT -i eth0 -p tcp --dport 22 -j DROP
+```
+
+-   IP 주소를 범위로 지정
+
+```
+$ iptables -A INPUT -p all -m iprange --src-range 192.168.0.0-192.168.255.255 -j DROP
+```
+
+-   iptable에서 주소를 범위로 지정하는 방법
+
+```
+-m iprange --src-range 시작 IP 주소-끝 IP 주소
+-m iprange --dst-range 시작 IP 주소-끝 IP 주소
+```
+
+-   서비스 포트를 범위로 지정
+
+```
+$ iptables -A INPUT -p tcp -m multiport --dport 3001:3010 -j DROP
+```
+
+-   -F 옵션을 사용하면 iptables에 적용된 정책을 한꺼번에 삭제 가능
+
+```
+$ iptables -F
+$ iptables --flush
+```
+
+-   -p 옵션은 각 체인의 기본 정책을 변경
+
+```
+$ iptables -P INPUT DROP
+$ iptables -P FOWARD DROP
+$ iptables -P OUTPUT DROP
+```
+
+-   iptables 정책 파일은 다음의 위치에 있음
+
+```
+/etc/sysconfig/iptables
+```
+
+### 10.1.5 리눅스 방화벽 로그 확인
+
+-   iptables도 일반 방화벽과 마찬가지로 로그를 통해 iptables 정책에 의해 차단되거나 허용된 내용을 확인할 수 있음
+-   iptables의 로그는 /var/log/messages에 남으므로 메시지 파일을 보려면 다음과 같이 로그 내용을 확인할 수 있음
+
+```
+$ tail -f /var/log/messages
+```
+
+-   하지만 메시지 파일에는 iptables 로그 외에 다른 로그들도 포함되어 있음
+-   iptables 로그만 확인하려면 다음과 같은 설정이 필요
+-   rsyslog.conf 파일에 다음과 같이 추가
+
+```
+kern.* /var/log/iptables.log
+```
+
+-   rsyslog 서비스를 재시작
+
+```
+$ systemctl restart rsyslog.service
+```
+
+-   warning 수준의 로그를 남기기 위해 log-level을 4로 하고 로그를 구분하는 식별자 추가
+
+```
+$ iptables -I INPUT LOG --log-level 4 --log-prefix '## ZIGI-Log ##
+```
+
+-   --log-prefix 옵션을 사용하지 않아도 로그를 남길 수 있지만 prefix를 정해두면 로그를 구분할 수 있음
+-   iptables 정책을 확인하는 -L 옵션 뒤에 -v 옵션을 사용하면 통과하는 패킷과 바이트 수를 확인할 수 있음
+
+```
+$ iptables -L -v
+```

docs/sk-lim19f/2024-02-29.md

@@ -0,0 +1,55 @@
+# 11. 이중화 기술
+
+-   끊김없는 안정적인 서비스를 제공하기 위해서는 네트워크, 서버, 스토리지와 같은 인프라뿐만 아니라 애플리케이션도 이중화(다중화) 기술을 적용해야 함
+-   이중화를 위해 동일한 역할을 하는 인프라를 두 대 이상 구성하거나 하나의 장비 내에 네트워크 인터페이스 카드와 같은 내부 구성요소를 다중으로 구성하기도 하고 동일한 역할을 하는 애플리케이션을 동시에 여러 개 띄워 서비스를 제공하기도 함
+-   이런 이중화 기술은 서비스 가용성을 높여주고 가용량을 확장해주기 때문에 안정적인 서비스 제공을 위해 이중화는 필수 요소
+
+## 11.1 이중화 기술 개요
+
+-   서비스를 제공하기 위한 인프라의 주요 목표 중 하나는 적시에 서비스를 출시하기 위해 인프라를 신속히 제공하는 것
+-   소위 타임 투 마켓을 위한 인프라의 민첩성
+-   하지만 인프라의 더 본질적인 목표는 더 가용성 높은 서비스에 필요한 인프라를 안정적으로 제공하는 것
+-   인프라를 설계할 때 가용성, 연속성, 안정성 등의 항목을 보는 것도 인프라를 안정적으로 제공하는 데 필요한 주요 지표
+-   따라서 인프라를 설계할 때, 단일 접점의 장애가 전체 서비스에 영향을 미치지 않도록 SPoF(단일 장애점)를 만들지 않아야 함
+
+### 11.1.2 이중화의 목적
+
+-   인프라를 구성하는 각 요소가 복수 개 이상으로 인프라를 구성해 특정 인프라에 문제가 발생하더라도 이중화된 다른 인프라를 통해 서비스가 지속되도록 해줌
+-   서비스에 필요한 출발 지점부터 끝 지점까지(End-to-End) 속하는 모든 인프라에 이중화 구성을 고려해야 함
+-   서비스를 위한 물리적 또는 가상 머신 서버, 서버와 네트워크 장비를 구성해주는 인터페이스, 서버에 연결된 스위치, 다수 서버의 부하 분산을 위한 L4/L7 스위치, 방화벽, 인터넷 게이트웨이, 인터넷 회선 등 모든 요소가 이중화 구성이 필요한 항목
+-   심지어 이 모든 요소가 속한 데이터 센터 자체도 이중화가 필요해 DR 센터나 액티브-액티브 데이터 센터를 구축
+-   인프라가 이중화되어 있다면 특정 지점에 문제가 발생하더라도 이중화된 인프라를 이용해 서비스 할 수 있음
+-   특정 인프라의 장애 상황에서도 서비스는 가능하므로 서비스의 연속성이 보장되고 이것을 폴트 톨로런스(장애 허용, 결함 감내)가 보장된다고 말하기도 함
+
+## 11.2 LACP
+
+-   1990년대 중반까지는 각 벤더별로 장비 간 대역폭을 늘리기 위해 독자적인 방법으로 구현했지만 벤더 독자적인 방법으로는 다른 장비끼리 연결할 때 호환성 문제가 발생해 이 문제를 해결하기 위해 상호호환 가능한 연결 계층(Link Layer) 표준화를 시작
+-   이 표준화가 LACP (Link Aggregation Control Protocol)
+-   링크 애그리게이션의 목적은 대역폭 확장을 통한 두가지를 제공하는 것
+    -   링크 사용률 향상(Improved Utilization of Available Link)
+    -   향상된 장애 회복(Improved Resilience)
+-   LACP를 사용하면 두 개 이상의 물리 인터페이스로 구성된 논리 인터페이스를 이용해 모든 물리 인터페이스를 액티브 상태로 사용
+-   이것을 통해 스위치와 스위치 또는 스위치와 서버 간 네트워크 대역폭이 물리 인터페이스 수량만큼 확장
+-   또한, 논리 인터페이스를 구성하는 물리 인터페이스 중 일부에서 문제가 발생하더라도 나머지 물리 인터페이스로 서비스를 유지
+-   액티브-스탠바이가 아니라 액티브-액티브 상태이므로 인터페이스 절체로 인한 지연 없이 서비스를 제공
+
+## 11.3 서버의 네트워크 이중화 설정
+
+-   인터페이스 이중화에 사용되는 기술 명칭은 윈도우와 리눅스에 따라 다음과 같이 다르게 부름
+    -   윈도우: 팀/team/티밍/teaming
+    -   리눅스: 본드/bond/본딩/bonding
+
+### 11.3.1 리눅스 본딩 모드
+
+-   리눅스 본딩 모드는 모드 0~4까지 있음
+-   실무에서는 이중화를 구성할 때, 액티브-스탠바이로는 모드 1을 사용하고 액티브-액티브로는 모드 4를 사용하며 나머지 모드는 보통 잘 사용하지 않음
+
+#### 11.3.1.1 모드1: 액티브- 스탠바이
+
+-   인터페이스를 액티브-스탠바이로 구성할 때는 모드 1을 사용
+-   평소 액티브 인터페이스로만 패킷이 전달되지만 액티브가 죽으면 스탠바이 인터페이스가 자동으로 활성화되어 패킷을 전송함
+-   원래의 액티브 인터페이스가 다시 살아나면 설정에 따라 액티브 인터페이스가 자동으로 다시 활성화(Auto Fail Back)되거나 수동으로 넘기기 전까지 스탠바이 인터페이스가 활성화 상태를 유지
+
+#### 11.3.1.2 모드4: LACP
+
+-   표준 프로토콜인 LACP를 이용해서 인터페이스를 액티브-액티브 방식으로 사용하고 싶을 때는 모드 4로 설정