Monthly Archives: September 2009

psad 관리

Posted on by
Reply

 * psad 의 시작과 종료

 psad 와 함께 제공되는 초기화 스크립트는 레드햇, 페도라, 슬랙웨어, 데비안, 맨드레이크, 젠투 리눅스 시스템에서 동작한다. 다수의 다른 세스템 데몬(syslog나 아파치)처럼 psad는 보통 init 스크립트를 통해 시작하고 종료한다.

User image
 psad가 init 스크립트를 통해 시작되면 주 psad 데몬, kmsgsd, psadwatch와 같은 세 개의 데몬도 시작된다. kmsgsd는 psad가 iptables 로그를 실시간으로 분석할 수 있게 /var/lib/psad/psadfifo 명명된 파이프로부터 모든 iptables 로그 메시지를 읽어 와서 별도의 파일인 /var/log/psad/fwdata 에 기록한다. 이를 통해 psad는 iptables 로그 메시지만을 포함하는 데이터 스트림을 제공받는다.

 * psad는 설치 시에 시스템 syslog 데몬이 info 우선순위를 가지는 모든 커널 메시지(또는 syslog 용어로 kern.info 메시지)를 명명된 파이프 /var/lib/psad/psadfifo 에 기록하게 재설정한다.

 psadwatchd 데몬은 단순히 psad와 kmsgsd 데몬이 실행 중인지 확인하고 그렇지 않으면 이들을 재시작한다. psadwatchd 는 두 데몬 중 하나를 재시작해야 하면 /etc/psad/psad.conf 파일에 있는 메일 주소로 경고 메일을 전송한다.

 * 데몬 프로세스의 유일성

 psad 가 시작되면 세 개의 psad 데몬은 각기 자신만의 프로세스 ID(PID)를 /var/run/psad 내의 파일에 기록한다. 명령 행에서 수동으로 데몬을 시작하면 해당 데이몬은 우선 ㅇ다른 인스턴스가 실행 중인지 확인하고 실행 중이라면 새로운 인스턴스는 바로 종료한다. 이를 통해 이미 존재하는 psad 프로세스를 그대로 유지할 수 있다.

 * iptables 정책 설정

 기본적으로 psad 는 로그 분석기다. psad는 자신이 설치된 시스템상의 iptables 정책이 기록 후 버리기 전략으로 설정됐다고 가정한다. 이는 iptables 가 네트워크의 동작을 위해서 꼭 필요한 패킷만을 수용하게 보장해주며 다른 모든 패킷은 기록 후 버린다. 포트 스캔, 백도어 프로그램을 위한 탐사, 시스템을 전복시키는 애플리케이션 명령(iptables 는 애플리케이션 계층 데이터를 필터링할 수 있다.), 기타 불법적인 것들이 수용 가능한 네트워크 트래픽 목족에서 제외되므로 이런 정책으로부터 나온 iptables 기록은 보통 전용 침입 탐지 시스템에 가치 있는 데이터를 제공할 수 있다.

 psad 는 로컬 iptabels 정책이 INPUT 과 FORWARD 체인 모두에서 기본 LOG와 DROP 규칙으로 설정됐는지 확인해주는 자동 기법을 제공한다. 이 기법은 /usr/sbin/fwcheck_psad 에 위치한 전용 스크립트로(psad 실행 시 –no-fwcheck 명령 행 스위치를 주거나 psad 가 별도의 syslog 서버에서 실행 중이지 않는 한) psad가 시작할 때 실행한다. fwcheck_psad 스크립트는 IPTables::Parse 펄 모듈을 사용해 로컬 iptables 정책의 표현(representation)을 얻어오며 LOG와 DROP 규칙이 포함됐는지 알아보기 위해 이를 해석한다. 포함돼 있지 않다면 psad 는 iptables 정책이 알맞게 설정되지 않았다는 것을 알려주기 위해 설정 경고 메일을 전송한다.

 예를 들어 현재 어떤 iptables 규칙도 인스턴스화돼있지 않다면 fwcheck_psad 는 경고 메일을 생성한다.

 * iptables 정책은 매우 복잡할 수 있기 때문에 정책이 로그와 버리기 전략을 가지는지 결정하는데에 IPTables::Parse 모듈의 구문 분석 기능이 항상 충분하지는 않다. 검사가 실패하더라도 psad 는 여전히 동작할 수 있으며, psad 의 효과는 iptables 가 기록하는 패킷의 유형에 따라 달라진다. 실제로 SMB 와 같은 프로토콜은 필요 없는 내용을 너무 많이 포함하기 때문에 기록하기에 부적절하며, 이런 프로토콜을 통해 전송된 패킷은 주로 LOG 규칙과 일치될 수 있기 전에 받아들이거나 버린다. fw_check_psad 가 올바로 구문 분석할 수 없을 정도로 복잡한 iptables 정책을 실행 중이라면 /etc/psad/psad.conf 의 ENABLE_FW_LOGGING_CHECK 변수를 N으로 설정해서 이 검사를 비활성화할 수 있다.

 * syslog 설정

 psad를 위해 iptables 정책 설정에 반드시 필요한 것을 잘 이해했다면 이제 psad가 iptables 로그 메시지를 얻는 과정을 살펴보자. 패킷이 iptables 내에서 LOG 규칙에 매칭되면 커널은 커널 로깅 데몬인 klogd 를 통해 이 사실을 보고한다. 이렇게 전달된 커널 로그 메시지는 보통 보고서 파일에 기록되기 위해 명명된 파이프나 버클리 소켓 인터페이스를 통한 별도의 시스템으로 전달된다. 이는 모두 syslog 데몬이 제공하는 기능과 syslog 이 어떻게 설정됐는지에 따라 달라진다.

 syslogd와 syslog-ng 데몬은 psad와 호환되며, psad는 metalog도 제한된 방식으로 지웒ㄴ다. syslogd와 syslog-ng 는 명명된 파이프로 로그 메시지를 기록할 수 있으며, psad 는 이를 이용하기 위해 모든 kern.info 로그 메시지가 명명된 파이프 /var/lib/psad/psadfifo 에 기록되게 설정한다. 이곳으로 전달된 로그 메시지는 kmsgsd 가 이용한다. kmsgsd 는 psadfifo 를 통해 syslog 메시지를 받으면 이 syslog 메시지가 iptables 에 의해 생성됐다는 것을 보장하기 위해 두 개의 부분 문자열(IN= 과 OUT=)을 포함하는지 확인한다. 메시지가 이 검사를 통과하면 kmsgsd는 이를 psad 가 볼 수 있게 파일 /var/log/psad/fwdata 에 기록한다. 많은 kern.info syslog 메시지가 iptables 와 아무런 관계도 없는 커널 일부에 의해 생성될 수 있으며, kmsgsd 는 iptables 메시지만이 psad 에 의해 분석되게 보장한다.

 * syslogd

 syslogd 가 설치된 시스템에서 psad 가 실행 중이라면 설치 시 /etc/syslog.conf 설정파일에 다음과 같은 내용이 추가된다. 이는 syslogd 가 kern.info 메시지를 /var/lib/psad/psad 에 기록하게 설정한다.

User image
 * syslog-ng

 반명 로컬 시스템의 syslog 데몬이 syslog-ng 라면 설치 시 /etc/syslog-ng/syslog-ng 설정파일에 추가된다.

 * whois 클라이언트

 마르코 디트리(Marco d’Itri)가 만든 훌륭한 whois(후이즈) 클라이언트가 psad 소스와 함께 제공된다. 이 클라이언트는 주어진 IP 주소에 대해 거의 항상 올바른 넷블록(netblock)을 질의하며, psad는 (–no-whois 명령 행 스위치를 주지 않는 한) IP 주소 소유 정보를 질의해서 메일 경고에 포함시키기 위해 이 클라이언트를 이용한다. 이런 정보를 가지면 스캔이나 기타 다른 공격이 탐지된 네트워크의 관리자 식별 과정이 단순해진다.

psad 설치

Posted on by
Reply

 * 역사

 psad 소프트웨어 프로젝트는 1999년 가을, 바스티유 개발팀이 바스티유가 경량의 네트워크 침입 탐지 컴포넌트를 제공해야 한다고 결정했을 때 Bastille 리눅스의 일부로 시작했다. 당시 피터 왓킨스는 지금까지도 Bastille와 함께 제공되는 매우 뛰어난 방화벽 스크립트를 개발 중이었으므로 방화벽 로그가 제공하는 정보에 기반한 IDS 도구를 개발하는 것은 자연스러운 다음 작업이었다. 또 당시 PortSentry(http://sourceforge.net/projects/sentrytools 참조)에는 기본 버리기 전략으로 설정된 방화벽과 함께 사용하기에는 부적절한 구조적 설계 문제가 있었다.

 이에 2001년 마이클 래쉬(이 글의 원 저자)는 바스티유-NIDS 프로젝트가 바스티유를 설치할 필요 없이 독립적으로 실행될 수 있게 별도의 프로젝트로 분리시키고 포트 스캔 공격 탐지기(Port Scan Attack Detector)라고 명명했다. psad의 개발 주기는 매우 활발하며 평균 3~4달에 한 번씩 새로운 배포판이 나온다.

 * 방화벽 로그를 분석하는 이유

 좋은 네트워크 보안은 기본 네트워크 연결성과 서비스를 허용하기 위해 절대적으로 필요한 만큼만 허용하게 적절히 설정된 방화벽에서 시작된다. 방화벽은 인라인 장치이므로 네트워크 트래픽에 필터링 로직을 적용하기 좋다. 컴퓨터 네트워킹의 문맥에서 인라인 장치란 네트워크를 통해 패킷이 라우팅될 때 패킷의 직접적인 경로에 존재하는 하드웨어를 의미한다. 인라인 장치 내의 하드웨어나 소프트웨어가 오작동해서 기기의 네트워크 트래픽 전달 기능에 영향을 미친다면 네트워크 통신은 더 이상 동작하지 못한다. 인라인 장치의 예로는 라우터, 스위치, 브리지, 방화벽, 네트워크 침입 방지 시스템(IPS)이 있다.

 방화벽의 기능이 좀 더 완전해지고 복잡해짐에 따라 점차적으로(애플리케이션 계층 검사와 같이) 전통적으로 침입 탐지 시스템의 범주였던 기능을 제공하고 있다. 이런 기능이 트래픽을 필터링하는 기능에 더해지면서 방화벽은 명백한 침투와 복잡한 정탐 시도로부터 서비스를 보호하고 웜 트래픽으로부터의 잠재적인 피해를 제한할 수 있는 효과적인 기법을 제공할 수 있는 양질의 침입 탐지 데이터를 생성할 수 있게 됐다. 광범위한 로깅과 필터링 기능을 갖춘 iptables와 같은 방화벽은 무시해선 안 되는 가치 있는 보안 데이터를 제공할 수 있다.

 스노트와 같은 전용 침입 탐지 시스템이 굉장히 많은 기능과 네트워크 공격을 기술하기 위한 광범위한 규칙 언어를 제공하는 반면 iptables는 항상 네트워크 트래픽에 인라인되서 자세한 패킷 해더 로그를 제공한다. 철저한 방어의 원리가 적용되므로 iptables의 로그를 주의 깊게 보는 것이 좋다.

 * psad의 기능

 현 버전의 psad는 Nmap과 같은 도구를 이용한 포트 스캔, 다양한 백도어 프로그램을 위한 탐사, 분산 서비스 거부 공격(DDoS) 도구, 네트워킹 프로토콜을 악용하려는 시도와 같이 다양한 유형의 의심스러운 트래픽을 탐지할 수 있다. psad는 fwsnort와 함께 사용하는 경우 애플리케이션 계층 데이터를 조사해야 하는 규칙을 포함해서 스노트 2.3.3 전체 규칙의 60% 이상을 탐지하고 경고할 수 있다.

 psad의 좀 더 흥미로운 기능 가운데 하나는 스캔이나 기타 악의적인 트래픽이 시작되는 원격 운영체제를 수동적으로 핑거프린팅할 수 있는 기능이다. 예를 들어 누군가가 윈도우 머신에서 TCP connect() 스캔을 시작하면 psad는 (대개) 스캔이 윈도우 XP, 2000, NT 중 어떤 시스템으로부터 온 것인지 구분할 수 있다. 심지어 일부 경우 psad는 원격 시스템의 서비스 팩 버전까지 탐지할 수 있다. psad가 사용하는 핑거프린트는 p0f에서 나온 것이다. 더욱이 psad는 자세한 메일과 syslog 경고, 위험 수준 임계치에 기반한 IP 자동 차단 기능(이 기능은 기본적으로 비활성화되어 있다.), 통합된 whois 지원, DShield 보고 등을 제공한다.

 * psad의 설치

 psad 설치에 관련한 자세한 내용은 http://www.cipherdyne.org/psad/download 를 참고하기 바란다. 참고로 우분투/데비안 시스템의 경우 아래의 명령어 하나만으로 psad의 설치를 진행할 수 있다.

 # apt-get install psad

 직접 소스를 다운받아 설치를 하는 경우 install.pl 스크립트를 이용하게 되는데, install.pl 스크립트는 메일 경고가 전송될 메일 주소, 시스템에서 현재 실행 중인 syslog 데몬의 유형(syslogd, syslog-ng, metalog), psad가 특정 로깅 접두어를 포함하는 iptables 로그 메시지만을 분석하게 할지에 대한 결정, 로그 데이터를 DShield 분산 IDS로 전송할지에 대한 결정 등과 같은 몇 가지 사용자 입력을 필요로 한다. 직접 정보를 입력하거나 기본 값(그냥 엔터 키를 누름)을 그대로 사용할 수 있다.

 * psadsms iptables 방화벽과 긴밀히 연계하기 때문에 아직 리눅스 이외의 운영체제로는 포팅되지 않았다. 그러나 psad의 능동적 응답 기능을 사용할 생각만 없다면 다른 운영체제를 실행 중이지만 별도의 리눅스 시스템으로부터 iptables 로그 메시지를 받아들이고 있는 syslog 서버에는 psad를 설치할 수 있다.

 리눅스에 psad를 성공적으로 설치하고 나면 로컬 파일시스템에 다량의 새 파일과 디렉토리가 생성된다.

 펄은 주요 psad 데몬을 개발하는데 쓰인 프로그래밍 언어로, 핵심 펄 모듈에는 포함되지 않는 몇 개의 펄 모듈이 사용된다. 이러한 펄 모듈을 /usr/lib/psad 에 모두 설치함으로써 psad는 이미 시스템 펄 라이브러리 트리에 설치된 펄 모듈과 psad가 필요로 하는 모듈을 완전히 분리시켜 유지할 수 있다.

 psad에는 다음과 같은 모듈이 필요하다.

 Data:Calc
 Net::Ipv4Addr
 Unix::Syslog
 IPTABLES::Parse
 IPTABLES::ChainMgr

 psad, kmsgsd, pasdwatchd 와 같은 세 개의 시스템 데몬이 psad 를 구성한다. 이 데몬은 모두 /usr/sbin 에 설치되면 /etc/psad 의 psad.conf 파일을 참조한다.

 psad 설치 프로그램은 /etc/psad/archive 디렉토리도 생성해서 현재의 psad 데몬 설정 파일을 복사한다. 이는 psad 를 재설치할 때 이전의 설정을 보존하기 위한 것이다. install.pl 프로그램은 현재의 psad 설정 값을 새로운 설정 파일로 통합할 수 있으며, 이를 통해 업그레이드 비용을 최소화할 수 있다.

 설치 프로그램은 /var 에도 몇 개의 파일과 디렉터리를 생성한다. 우선 /var/lib/psadfifo 에 명명명 파이프를 생성하고 /var/log/psad 디렉토리와 파일 /var/log/psad/fwdata 를 생성한다. 끝으로 install.pl 스크립트는 설치 로그를 /var/log/psad/install.log 에 유지한다. 실행 시 psad 의 주요 동작 디렉토리(수상한 네트워크 트래픽과 관련된 IP 주소를 기록하는 디렉토리)도 /var/log/psad 다.

 

iptables 방화벽 설정 관련…

Posted on by
Reply

 요즘 공부하고 있는 iptables 를 이용한 방화벽 구축 관련하여…

 한가지 문제가 되는 부분이 있었다.

 그것은 바로 방화벽을 설정하게 되면 이상하게 네임서버 질의가 안되는 것.

 문제의 발단은 다음의 스크립트를 이용하여 방화벽을 설정하는 것 부터 시작이었다.

#!/bin/sh

IPTABLES=/sbin/iptables
MODPROBE=/sbin/modprobe

### 기존 규칙을 제거하고 체인 정책을 DROP으로 설정한다.
echo “[+] Flushing existing iptables rules…”
$IPTABLES -F
$IPTABLES -X
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
### load connection-tracking modules
$MODPROBE ip_conntrack
$MODPROBE ip_conntrack_ftp

###### INPUT 체인 ######
echo “[+] Setting up INPUT chain…”
### 상태 추적 규칙
$IPTABLES -A INPUT -m state –state INVALID -j LOG –log-prefix “DROP INVALID ” –log-ip-options –log-tcp-options
$IPTABLES -A INPUT -m state –state INVALID -j DROP
$IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

### ACCEPT 규칙
#ftp
$IPTABLES -A INPUT -i eth0 -p tcp –dport 20 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A INPUT -i eth0 -p tcp –dport 21 –syn -m state –state NEW -j ACCEPT
#ssh
$IPTABLES -A INPUT -i eth0 -p tcp –dport 22 –syn -m state –state NEW -j ACCEPT
#whois
$IPTABLES -A INPUT -i eth0 -p tcp –dport 43 –syn -m state –state NEW -j ACCEPT
#domain
$IPTABLES -A INPUT -i eth0 -p tcp –dport 53 –syn -m state –state NEW -j ACCEPT
#http
$IPTABLES -A INPUT -i eth0 -p tcp –dport 80 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A INPUT -i eth0 -p udp –dport 80 -m state –state NEW -j ACCEPT
#https
$IPTABLES -A INPUT -i eth0 -p tcp –dport 443 –syn -m state –state NEW -j ACCEPT
#rsync
$IPTABLES -A INPUT -i eth0 -p tcp –dport 873 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A INPUT -i eth0 -p udp –dport 873 -m state –state NEW -j ACCEPT
$IPTABLES -A INPUT -p icmp –icmp-type echo-request -j ACCEPT
$IPTABLES -A INPUT -i ! lo -j LOG –log-prefix “DROP ” –log-ip-options –log-tcp-options

###### OUTPUT 체인 ######
echo “[+] Setting up OUTPUT chain…”

### 상태 추적 규칙
$IPTABLES -A OUTPUT -m state –state INVALID -j LOG –log-prefix “DROP INVALID ” –log-ip-options –log-tcp-options
$IPTABLES -A OUTPUT -m state –state INVALID -j DROP
$IPTABLES -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

### 외부로 나가는 연결을 허용하기 위한 ACCEPT 규칙
#ftp
$IPTABLES -A OUTPUT -p tcp –dport 20 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p tcp –dport 21 –syn -m state –state NEW -j ACCEPT
#ssh
$IPTABLES -A OUTPUT -p tcp –dport 22 –syn -m state –state NEW -j ACCEPT
#whois
$IPTABLES -A OUTPUT -p tcp –dport 43 –syn -m state –state NEW -j ACCEPT
#domain
$IPTABLES -A OUTPUT -p tcp –dport 53 –syn -m state –state NEW -j ACCEPT
#http
$IPTABLES -A OUTPUT -p tcp –dport 80 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p udp –dport 80 -m state –state NEW -j ACCEPT
#https
$IPTABLES -A OUTPUT -p tcp –dport 443 –syn -m state –state NEW -j ACCEPT
#rsync
$IPTABLES -A OUTPUT -p tcp –dport 873 –syn -m state –state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p udp –dport 873 -m state –state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPT

### 기본 OUTPUT LOG 규칙
$IPTABLES -A OUTPUT -o ! lo -j LOG –log-prefix “DROP ” –log-ip-options –log-tcp-options

 보기에는 별 문제가 없는 방화벽 스크립트이다.

 기본적으로 모든 입력에 대해 DROP 정책을 고수하고 서비스하는 특정 포트들에 대해 접근을 허가하는 내용인데… 특이점으로 ftp에 대한 포트와 rsync를 위한 포트를 개방한 부분에 있다.

 이는 동아리에서 서비스 중인 미러링 사이트 유지를 위해 필요한 부분이었기 때문에 특별히 신경썼던 부분이었다.

 해당 스크립트를 적용시킨 후, ssh 접속 및 ftp, http 접속이 정상적으로 이루어지는 것을 확인하여 아무런 문제가 없는 줄 알았다.

 하지만… 미러링을 위한 rsync 스크립트를 돌리자마자 다음의 오류를 발생하며 프로세스가 정지가 되는 것이었다.
 

rsync: getaddrinfo: releases.ubuntu.com 873: Temporary failure in name resolution
rsync error: error in socket IO (code 10) at clientserver.c(122) [receiver=3.0.3]

 에러 발생 메시지가 늘 그렇듯이 처음보는 에러메시지였다. 하지만 에러 메시지 중 익숙한 부분이 눈에 들어왔다. 바로 “getaddrinfo” 라는 부분과 “socket IO” 부분.

 그렇다. 네트워크 프로그래밍에서 주소를 받아오는 함수부분인 것이다. 다른곳도 아니고 주소를 알아내는 모듈이 실패를 했다는 메시지가 나오니 그래서..설마하는 마음으로 dig 명령어를 이용한 IP 질의를 해보았다.

 역시나였다. dig, nslookup 등등의 명령어가 먹히지 않는다. 이상했다.

 resolve 질의를 위한 부분 역시 스크립트에서는 명백히 명시를 해놓았기 때문이다. 무엇이 문제일까. 구글링 및 kldp를 비롯하여 여러곳을 뒤져보아도 속시원한 답을 찾을 수 없었다.

 단 하나, 똑같은 상황이 있었는데 네임서버 설정이 잘못되있는 경우 그런 에러가 발생한다는 것만 알 수 있었다.

 하지만 이미 네임서버는 설정이 정상적으로 되어 있는 상황이었고, 같은 네임서버를 설정해놓은 다른 보통의 서버(위의 스크립트를 적용시키지 않은)들은 아무 문제없이 질의가 이루어지는 상황이었다.

 한참….을 헤멘후에야 그 해답을 알 수 있었는데..

 그 정답은 바로 다음의 라인이었다.

$IPTABLES -A INPUT -p udp –dport 53 -m state –state NEW -j ACCEPT
$IPTABLES -A OUTPUT -p udp –dport 53 -m state –state NEW -j ACCEPT

 차이를 알겠는가? 바로 프로토콜 설정부분이었다. 기존의 스크립트는 -p tcp 만을 옵션으로 하였기 때문에 udp의 경우는 방화벽에 차단당했던 것이었다.

 늘 그렇다. 알고나면 별것아닌것. 에효… 진즉에 service 파일좀 살펴볼껄… 별것아닌 에러에 이렇게 곤란을 느낀것이 부끄럽기만 하다.

iptables (커널 2.4대의 방화벽 관리도구)

Posted on by
Reply

 커널 2.4대에서 방화벽, 규칙 설정, IP 매스커레이딩을 조정하는 커널 도구

 iptables -[ADC] chain 상세룰 [옵션]
 iptables -[RI] chain 룰번호 상세룰 [옵션]
 iptables -D chain 룰번호 [옵션]
 iptables -[LFZ] [chain] [옵션]
 iptables -[NX] chain
 iptables -E 이번체인이름 새로운체인이름
 iptables -P chain target [옵션]
 iptables -h

 -A chain, –append chain : chain을 추가한다.
 -D chain, –delete chain : chain에서 룰을 삭제한다.
 -D chain 룰넘버, –delete chain 룰넘버 : chain 정책 중 지정한 룰넘버를 삭제한다. 만일 룰넘버가 1이라면 chain 규칙의 첫 번째 룰을 삭제한다.
 -I chain [룰넘버], –insert chain [룰넘버] : chain 정책에 지정한 숫자번째에 삽입하거나, 마지막에 룰을 삽입한다.
 -R chain 룰넘버, –relace : chain 정책 중 지정한 숫자번째의 룰을 교체한다.
 -L [chain], –list [chain] 모든 chain 정책을 보거나, 지정한 chain 정책을 본다.
 -F [chain], –flush : 모든 chain 정책을 삭제하거나, 지정한 chain 정책을 삭제한다.
 -Z [chain], –zero : 모든 chain 정책을 제로로 만들거나, 지정한 chain 정책을 제로로 만든다.
 -C chain, –check chain : 설정한 chain 정책을 테스트한다.
 -N chain, –new-chain : 새로운 정책을 만든다.
 -X [chain], –delete-chain : 사용자가 만든 chain이나 모든 chain을 삭제한다.
 -P chain target, –policy chain target : chain 정책을 지정한 chain 정책으로 바꾼다.
 -E old-chain new-chain, –rename-chain old-chain new-chain : chain명을 바꾼다.
 -p, –protocol [!] proto : 프로토콜을 지정한다. !은 제외의 의미이다.
 -s, –source [!] address[/mask] : 출발지 주소를 지정한다. mask는 C클래스면 255.255.255.0이나 24비트로 표현된다.
 -d, –destination [!] address[/mask] : 목적지 주소를 지정한다.
 -i, –in-interface [!] input name[+] 수신하는 네트워크 인터페이스 이름을 지정한다. name+은 name으로 시작하는 모든 인터페이스 이름이다.
 -j –jump target : 지정하는 target으로 리다이렉트 시킨다.
 -m : 지정한 match로 확장이 가능하다.
 -n : IP주소와 포트번호를 숫자 그대로 보여준다.
 -o, –out-interface [!] output name[+] : 발신하는 네트워크 인터페이스 이름을 지정한다.
 -v, –verbose : 상세한 정보를 보여준다.
 –line-numbers : 룰정책을 보여줄 때 줄번호도 나타낸다.
 -x, –exact : 정확한 값으로 나타낸다.
 -V, –version : 버전 정보를 보여준다.

 iptables는 netfilter 필터링 룰에 사용한다. 대부분 ipchains와 사용법이 거의 같으나, 가장 큰 차이점은 확장성에 있다. 정상적으로 커널 확장은 커널 모듈 하부 디렉토리(/lib/modules/커널버전/kernel/net)에 존재하는데, iptables는 요구에 의하여 적재된다. 그래서, 아들 모듈을 직접 적재할 필요는 없다. iptables의 확장들은 공유 라이브러리 형태로 보통 /usr/local/lib/iptables 에 위치한다. 배포판은 이것을 /lib/tables나 /usr/lib/tables 에 넣으려 할 것이다.

User image 우분투 8.10-Desktop 의 경우 /lib/iptables 밑에 존재한다.

 ipchain이 iptables에서 변경된 사항들은 다음과 같다.

 * 미리 만들어진 체인 이름 (input, output, forward)가 소문자에서 대문자로 바뀌었다.

 * -i 지시자는 들어오는 인터페이스만 의미하고 INPUT과 FORWARD chain에서만 작동한다. FORWARD나 OUTPUT chain은 -o 로 사용한다.

 * TCP와 UDP 포트는 –source-port, –sport (–destination-port, –dport)과 사용하게 된다. -p tcp 또는 -p udp 옵션과 함께 사용되어져야 한다.

 * TCP -y 지시자는 –syn 으로 바뀌었고 -p tcp 다음에 와야한다.

 * DENY target 는 DROP으로 바뀌었다.

 * iptables 를 이용하여 정책들을 입력하였다면, 이는 메모리에 적재될 뿐이므로 시스템을 다시 시작한 후에는 모두 사라질 것이다. 이를 iptables-save 명령으로 저장이 가능하다.

 # iptables-save > iptables_test

 아래와 같이 iptables-restore 명령으로 저장한 정책 파일을 불러올 수도 있다.

 # iptables-restore < iptables_test

 * 매스커레이딩(iptables)
 ipchain 명령과 마찬가지로 내부 인터넷 연결 공유를 할 수 있다. masquerading 기법으로 한 컴퓨터에 두 개의 네트워크 인터페이스를 설정한 다음, 하나는 외부의 인터넷과 연결되어 있고, 다른 하나는 내부 게이트웨이(192.168.0.1 이라고 가정)의 역할을 하도록 설정한다. 내부 게이트웨이 역할을 하는 인터페이스와 연결된 허브를 통해 같은 192.168.0.0/24 대역의 아이피를 설정하여, 내부에서도 인터넷을 사용할 수 있도록 할 수 있다. 아래의 스크립트는 최소의 masquerading 기법을 위한 입력으로 손쉽게 내부에 인터넷을 공유할 수 있다.

 # /sbin/iptables -F
 # echo “1” > /proc/sys/net/ipv4/ip_forward
 # iptables -t nat -A POSTROUTING -s 192.168.1.2/24 -j MASQUERADE

 * 솔라리스(Solaris)
 솔라리스는 BSD 계열의 SunOS를 바탕으로 하여, System V 계열의 영향을 받은 SunOS 5 버전부터는 Solaris 2.x 라는 이름도 함께 사용해 왔다. 이후 Solaris 2.7 부터는 다시 Solaris 7이라는 이름으로도 통용되고 있다. Sun 사에서는 이 OS를 자사에서 생산하는 스팍 플랫폼 용으로만 개발하였으나 인텔 플랫폼을 사용하는 경우가 늘어나며 인텔용 버전도 함께 개발하였다. 그러나 본질적으로는 거의 동일한 소스를 기반으로 컴파일한 제품이므로 성능 면에서는 큰 차이가 없다.