diff --git a/docs/sk-lim19f/2024-02-27.md b/docs/sk-lim19f/2024-02-27.md new file mode 100644 index 0000000..369f278 --- /dev/null +++ b/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 +``` diff --git a/docs/sk-lim19f/2024-02-28.md b/docs/sk-lim19f/2024-02-28.md new file mode 100644 index 0000000..f567ea6 --- /dev/null +++ b/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 +``` diff --git a/docs/sk-lim19f/2024-02-29.md b/docs/sk-lim19f/2024-02-29.md new file mode 100644 index 0000000..0d1c6f2 --- /dev/null +++ b/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로 설정 diff --git a/docs/sk-lim19f/2024-03-04.md b/docs/sk-lim19f/2024-03-04.md new file mode 100644 index 0000000..9517e37 --- /dev/null +++ b/docs/sk-lim19f/2024-03-04.md @@ -0,0 +1,134 @@ +# 다시 + +최근 과제 테스트를 하느라 책을 제대로 읽지 못했다. +오늘부터 다시 꾸준히 시작해야겠다. + +### 11.3.3 리눅스 본드 설정 및 확인 + +#### 11.3.3.1 CentOS에서 본드 설정 및 확인 + +- 네트워크 설정 파일이 있는 디렉토리에 bond 인터페이스 파일을 생성하고 bond로 묶일 인터페이스에 추가 속성을 설정하는 방식 + +``` +$ cd /etc/sysconfig/network-scripts +``` + +- bond 인터페이스 파일 ifcfg-bond0을 생성해 다음과 같이 설정 + +``` +ifcfg-bond0 + +DEVICE=bond0 +BOOTPROTO=none +onBOOT=yes +BOOTPROTO=static +IPADDR=10.10.10.11 +NETMASK=255.255.255.0 +GATEWAY=10.10.10.1 +``` + +- bond 인터페이스 파일을 설정했으면 물리 인터페이스 파일, ifcfg-eth0, ifcfg-eth1에도 bond 인터페이스 사용을 위한 추가 속성을 설정 + +``` +ifcfg-eth0, ifcfg-eth1 + +DEVICE=bond0 +BOOTPROTO=none +onBOOT=yes +MASTER=bond0 +SLAVE=yes +``` + +- 본드 인터페이스 설정을 마친 후에는 bonding 설정 파일 위치로 이동해 속성을 변경 + +``` +$ cd /etc/modprobe.d/ +``` + +- bonding 설정 파일 + +``` +bonding.conf + +alias bond0 bonding +options bond0 mode=4 miimon=100 +``` + +- mode는 본드 구성에 대한 모드 번호 +- miimon은 해당 밀리초마다 bond로 묶인 링크를 확인하는 옵션 +- bond 모드의 기본값이 0(라운드 로빈)이며 miimon 값은 0(또는 1[0.01초]) +- miimon이 0이면 인터페이스 상태를 체크하지 않아 페일오버가 동작하지 않으므로 반드시 확인해 0이 아닌 값으로 변경 +- 모드 1을 사용해 액티브-스탠바이 구성으로 본드를 구성할 때는 위의 옵션 값 외에 어떤 인터페이스를 액티브(Primary 속성)로 사용할지에 대한 옵션을 추가로 설정해야 함 +- 리눅스 커널에 본드 모듈 적재 + +``` +$ modprobe bonding +``` + +- 본드 인터페이스를 게이트웨이로 설정하고 싶다면 다음 설정을 추가 + +``` +/etc/sysconfig/network + +GATEDEV=bond0 +``` + +- bond 인터페이스를 설정하거나 수정한 후에는 네트워크를 다시 시작 + +``` +$ service network restart //CentOs 6 +$ systemctl restart network //CentOs 7 +``` + +- 본드 설정 및 네트워크 재시작 후에는 본드가 정상적으로 잘 구성되었는지 확인 + +``` +$ cat /proc/net/bonding/bond0 +``` + +> 본드 설정 후 인터페이스가 정상적으로 활성화 되지 않을 때 + +- 본드 설정 후 네트워크를 다시 시작하는 과정에서 본드 인터페이스가 정상적으로 활성화 되지 못하는 경우가 있음 +- 이때는 NetworkManager를 중지하고 실행 + +``` +$ service networkmanger stop +$ chkconfig networkmanger off +``` + +#### 11.3.3.2 우분투에서 본드 설정 및 확인 + +- 우분투에서 본드를 설정하려면 먼저 ifenslave 패키지를 설치 + +``` +$ apt-get install ifenslave +``` + +- 커널 모듈에 bonding 값이 있어야 함 +- 만약 없다면 /etc/modules 파일에 bonding이라는 값을 추가하고 재부팅해야 함 + +``` +/etc/modules + +bonding +``` + +- 본딩 설정을 위해 인터페이스 파일인 /etc/network/interfaces에 인터페이스 eth0과 eth1을 bond0 인터페이스로 만들기 위한 설정을 다음과 같이 함 + +``` +/etc/network/interfaces + +auto eth0 +iface eth0 inet manual + bond-master bond0 + +auto eth1 +iface eth1 inet manual + bond-master bond0 + +auto eth0 +iface eth0 inet static + address 192.168.1.10 + gateway 192.168.1.1 + netmask 255.255.255.0 +```