일반적으로 :
방화벽 구성을보고 수정하려면 root제한된 포트 번호 범위에서 서비스를 여는 것처럼 관리자 권한 ( )이 필요 합니다. 즉 , 루트로 로그인하거나 명령을 루트로 실행하는 데 root사용해야 sudo합니다. 이러한 명령을 optional으로 표시하려고합니다 [sudo].
내용:
- 주문 문제 나 사이의 차이
-I와-A
- 현재 방화벽 구성 표시
- 출력 해석
iptables -L -v -n
- 환경을 알고
- INPUT 및 FORWARD 체인
- 커널 모듈
1. 주문 문제 나 사이의 차이 -I와-A
기억해야 할 것은 방화벽 규칙이 나열된 순서대로 확인된다는 것입니다. 패킷이나 연결을 허용하거나 허용하지 않는 규칙이 트리거되면 커널은 체인 처리를 중지합니다.
내가 생각하는 가장 일반적인 실수 초보자 방화벽 관리자들이는 아래와 같은 새로운 포트를 열어 올바른 지침을 따르이다 :
[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT
그런 다음 적용되지 않습니다.
그 이유는 기존의 모든 규칙 뒤에-A 옵션이 새 규칙을 추가
하고 기존 방화벽의 최종 규칙이 종종 허용되지 않는 모든 트래픽을 차단 하는 규칙 이었기 때문에
...
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
8 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
또는 iptables-save와 동일합니다.
...
iptables -A INPUT -j REJECT
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
TCP 포트 8080을 여는 새로운 규칙에 도달하지 않습니다. (카운터가 0 패킷과 0 바이트로 완고하게 남는 것으로 입증 됨).
-I새 규칙으로 규칙을 삽입하면 체인에서 첫 번째 규칙이되어 작동합니다.
2. 현재 방화벽 구성을 표시합니다
방화벽 관리자는 사용자 친화적 인 도구로 방화벽 문제를 진단하는 대신 Linux 커널이 실행중인 실제 구성을 살펴 보는 것이 좋습니다. 기본 문제를 이해 한 후에는 해당 도구가 지원하는 문제로 쉽게 해결할 수 있습니다.
명령 [sudo] iptables -L -v -n은 당신의 친구입니다 (그러나 어떤 사람들은 iptables-save더 좋아합니다). 구성을 논의 할 때 종종 --line-numbers번호 줄뿐만 아니라 옵션 을 사용하는 것이 유용합니다 . 규칙 #X를 참조하면 다소 토론하기가 쉽습니다.
참고 : NAT 규칙은 iptables-save출력에 포함 되지만 -t nat옵션 을 추가하여 별도로 나열해야합니다 ( 예 :) [sudo] iptables -L -v -n -t nat --line-numbers.
명령을 여러 번 실행하고 카운터 증가를 확인하면 새 규칙이 실제로 트리거되는지 확인하는 데 유용한 도구가 될 수 있습니다.
[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 784K 65M fail2ban-SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
2 2789K 866M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
3 15 1384 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
7 2515K 327M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num pkts bytes target prot opt in out source destination
Chain fail2ban-SSH (1 references)
num pkts bytes target prot opt in out source destination
1 0 0 REJECT all -- * * 117.239.37.150 0.0.0.0/0 reject-with icmp-port-unreachable
2 4 412 REJECT all -- * * 117.253.208.237 0.0.0.0/0 reject-with icmp-port-unreachable
또는의 출력은 iptables-save위의 방화벽 구성을 재생성 할 수있는 스크립트를 제공합니다.
[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT
이해하기 쉬운 것을 선호하는 것이 중요합니다.
3. 출력의 해석 iptables -L -v -n
정책 기본 동작을 체인 사용하는 명시적인 규칙 일치를 설정합니다. 에서 INPUT모든 트래픽을 허용하도록 설정되어 체인.
INPUT 체인의 첫 번째 규칙은 즉시 흥미로운 규칙이며 TCP 포트 22로 향하는 모든 트래픽 (소스 0.0.0.0/0 및 대상 0.0.0.0/0) tcp dpt:22을 SSH의 기본 포트로 사용자 지정 대상 ( fail2ban-SSH)으로 보냅니다. . 이름에서 알 수 있듯이이 규칙은 fail2ban (시스템 로그 파일에서 남용 가능성이 있는지 검사하고 남용자의 IP 주소를 차단하는 보안 제품)에 의해 유지됩니다.
이 규칙은 iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHiptables-save의 출력 과 비슷 하거나 유사한 iptables 명령 행에 의해 작성되었을 것 -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH입니다. 종종 문서에서 이러한 표기법 중 하나를 찾을 수 있습니다.
카운터는이 규칙이 784'000 개의 패킷 및 65MB의 데이터와 일치했음을 나타냅니다.
이 첫 번째 규칙과 일치하는 트래픽은 fail2ban-SSH체인에 의해 처리되며 체인은 비표준 체인으로 OUTPUT 체인 아래에 나열됩니다.
이 체인은 차단 된 (가있는 reject-with icm-port-unreachable) 각 가해자 (소스 ip- 주소 117.253.221.166 또는 58.218.211.166)에 대해 하나씩 두 가지 규칙으로 구성됩니다 .
-A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable
차단 된 호스트에서 얻지 않은 SSH 패킷은 아직 허용되거나 허용되지 않으며 이제 사용자 지정 체인이 완료되었으므로 INPUT 체인의 두 번째 규칙에 따라 검사됩니다.
포트 22로 향하지 않은 모든 패킷은 INPUT 체인의 첫 번째 규칙을 통과했으며 INPUT 규칙 # 2에서도 평가됩니다.
입력 규칙 번호 2는 연결을 추적 하는 상태 전체 방화벽 이되도록 합니다. 이는 몇 가지 장점이 있지만, 새로운 연결에 대한 패킷 만 전체 규칙 세트에 대해 검사해야하지만 일단 허용 된 연결이나 관련 연결에 속하는 추가 패킷은 추가 확인없이 허용됩니다.
입력 규칙 # 2는 열려있는 모든 관련 연결 및 해당 규칙과 일치하는 패킷을 더 이상 평가할 필요가 없습니다.
참고 : 상태 저장 방화벽 구성의 규칙 변경은 기존 연결이 아닌 새 연결에만 영향을 미칩니다.
반대로 간단한 패킷 필터는 연결 상태를 추적하지 않고 모든 규칙 집합에 대해 모든 패킷을 테스트합니다. 이러한 방화벽에서는 상태 키워드가 사용 되지 않습니다 .
입력 규칙 # 3은 상당히 지루하며 루프백 ( lo또는 127.0.0.1) 인터페이스에 연결하는 모든 트래픽 이 허용됩니다.
입력 규칙 4, 5 및 6은 새 연결에 대한 액세스 권한을 부여하여 TCP 포트 22, 80 및 443 (SSH, HTTP 및 HTTPS의 기본 포트)을 여는 데 사용됩니다 (기존 연결은 이미 입력 규칙 2에서 허용됨).
상태 비 저장 방화벽에서 이러한 규칙은 상태 속성없이 나타납니다.
4 44295 2346K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
5 40120 2370K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
6 16409 688K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0
또는
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
마지막 INPUT 규칙 # 7은 INPUT 규칙 1-7에서 액세스 권한이 부여되지 않은 모든 트래픽을 차단하는 규칙입니다. 상당히 일반적인 관습 : 허용되지 않는 모든 것은 거부됩니다. 이론적으로이 규칙은 기본 POLICY를 REJECT로 설정하여 생략 할 수 있습니다.
항상 전체 체인을 조사하십시오.
4. 환경을 알고
4.1. 소프트웨어 방화벽의 설정은 네트워크의 다른 곳에서 유지되는 보안 설정에 영향을 미치지 않습니다. 즉 iptables라우터의 수정되지 않은 액세스 제어 목록을 사용 하여 네트워크 서비스를 열었더라도 네트워크의 다른 방화벽은 여전히 트래픽을 차단할 수 있습니다 ...
4.2. 수신 대기중인 서비스가 없으면 방화벽 설정에 관계없이 연결할 수 없으며 연결 거부 오류가 발생 합니다. 따라서:
- 서비스가 올바른 네트워크 인터페이스 / ip 주소를 수신하고 있고 원하는 포트 번호를
[sudo] netstat -plnut사용 하고 있거나 다른 방법으로 사용 중인지 확인하십시오 ss -tnlp.
- 서비스가 아직 실행되고 있지 않은 경우 netcat과 같은 간단한 리스너를 에뮬레이트
[sudo] nc -l -p 123하거나 openssl s_server -accept 1234 [options] TLS / SSL 리스너가 필요한 경우 ( man s_server옵션 확인 ).
- 당신은 그 자체, 즉 서버에서 연결할 수 있는지 확인
telnet <IP of Server> 123하거나 echo "Hello" | nc <IP of Server> 123TLS / SSL 보안 서비스를 테스트 할 때 또는 openssl s_client -connect <IP of Server>:1234원격 호스트에서 동일한 작업을 시도하기 전에.
4.3. 서비스에서 사용하는 프로토콜을 이해하십시오. 충분히 이해하지 못하는 서비스를 제대로 활성화 / 비활성화 할 수 없습니다. 예를 들어 :
- TCP와 UDP 중 어느 것을 사용합니까 (DNS와 같이)?
- 서비스가 고정 기본 포트를 사용합니까 (예 : 웹 서버의 TCP 포트 80과 같은 것)?
- 또는 다이나믹 포트 번호를 선택할 수 있습니까 (예 : 포트 맵에 등록하는 기본 NFS와 같은 RPC 서비스)?
- 악명 높은 FTP는 수동 모드를 사용하도록 구성된 경우 고정 및 동적 포트 번호의 두 포트 를 사용합니다.
- 서비스, 포트 및 프로토콜 설명이
/etc/services반드시 포트를 사용하는 실제 서비스와 일치하지는 않습니다.
4.4. 커널 패킷 필터 만이 네트워크 연결을 제한 할 수있는 것은 아닙니다.
- SELinux는 네트워크 서비스를 제한 할 수도 있습니다.
getenforceSELinux가 실행 중인지 확인합니다.
- 약간 불분명 한 TCP Wrappers는 여전히 네트워크 보안을 강화하는 강력한 도구입니다. 확인
ldd /path/to/service |grep libwrap및 /hosts.[allow|deny]제어 파일.
5. INPUT또는 FORWARD사슬
체인의 개념은 여기에 더 자세히 설명되어 있지만 그 단점은 다음과 같습니다.
INPUT열려 및 / 또는 당신이 iptables 명령을 발행 할 경우 서비스를위한 주변 네트워크 포트가 호스트에 로컬로 실행 곳에 체인입니다.
FORWARD당신이 당신의 리눅스 머신은 브리지, 라우터, 하이퍼 바이저의 역할 및 / 또는 네트워크 주소를 수행되어 다른 시스템에 커널에 의해 전달됩니다 필터 트래픽 규칙, 실제 시스템뿐만 아니라 도커 용기 및 가상 게스트 서버 서버를 적용 할 경우 체인입니다 번역 및 포트 포워딩.
일반적인 오해는 도커 컨테이너 또는 KVM 게스트가 로컬에서 실행되므로 적용되는 필터 규칙은 INPUT 체인에 있어야하지만 일반적으로 그렇지 않습니다.
6. 커널 모듈
패킷 필터는 Linux 커널 내에서 실행되므로 실제로 여러 모듈 인 동적 모듈로 컴파일 할 수도 있습니다. 대부분의 배포에는 netfilter가 모듈로 포함되며 필요한 netfilter 모듈은 필요에 따라 커널에로드되지만 일부 모듈의 경우 방화벽 관리자가 수동으로로드해야합니다. 이는 주로 nf_conntrack_ftp로로드 할 수있는 연결 추적 모듈과 관련 이 있습니다 insmod.
현재 실행중인 커널에로드 된 모듈은로 표시 될 수 있습니다 lsmod.
재부팅시 모듈이 지속적으로로드되도록하는 방법은 Linux 배포판에 따라 다릅니다.
