취약성 평가에 사용될 도구 선택을 위하여 취약성 평가 방법론을 먼저 수립하시기 바랍니다. 불행히 아직 미리 정의되거나 산업체에서 인증받은 방법이 존재하지 않지만 일반 상식과 실행 결과만으로도 평가 방법론에 대한 충분한 길잡이가 될 수 있습니다.

어느 시스템을 상대로 하는가? 한 개의 서버를 상대하는가 또는 전체 네트워크 및 그 네트워크 내의 모든 시스템을 상대로 하는가? 현재 회사 외부에 위치하고 있는가 내부에 위치하고 있는가? 이러한 질문에 대한 해답을 찾는 것은 사용할 적절한 도구를 찾는데 도움이 될 뿐만 아니라 그 도구를 어떠한 방법으로 사용할 지 결정 가능하게 합니다.

방법론 수립에 대한 보다 많은 정보를 원하신다면 다음 웹사이트를 참조하시기 바랍니다:

nmap은 Red Hat Enterprise Linux에 포함된 네트워크 배치를 찾아내기 위해 자주 사용되는 도구입니다. nmap은 수년간 사용되어져 왔으며 아마도 가장 흔히 사용되는 정보 수집용 도구입니다. 메뉴얼 페이지를 보시면 옵션과 사용법에 대한 자세한 정보를 찾으실 수 있습니다. 관리자는 네트워크 상에서 nmap을 사용하여 호스트 시스템과 호스트 시스템 상에서 열려진 포트를 찾아낼 수 있습니다.

nmap은 취약성 평가의 첫단계로 사용하기에 모자람이 없는 훌륭한 도구입니다. 네트워크 내의 모든 호스트를 찾고 심지어는 특정 호스트에서 실행 중인 운영 체제를 찾기 위한 옵션도 전달 가능합니다. nmap은 보안 서비스를 사용하고 사용되지 않는 서비스는 멈추는 정책을 수립하는데 좋은 기반이 됩니다.

nmap foo.example.com

Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

Nessus는 전체 서비스 보안 스캐너입니다. Nessus는 플러그인 구조로 되어있기 때문에 사용자가 자신의 시스템과 네트워크에 맞게 사용자 정의 가능합니다. 다른 스캐너와 마찬가지로 Nessus는 침입탐지 패턴 데이터베이스에 의존하지만, 다행히도 Nessus는 자주 업데이트됩니다. 완전한 보고 기능, 호스트 스캐닝, 실시간 취약성 검색과 같은 기능을 제공합니다. Nessus처럼 자주 업데이트되고 강력한 도구라 해도 잘못된 결과 (존재하지 않는 취약점을 보고하거나 존재하는 취약점을 발견하지 못하는 결과)를 보고할 가능성이 있습니다.

Nessus와 관련된 보다 많은 정보를 원하신다면 다음 URL에서 공식 홈페이지를 찾아보시기 바랍니다:

http://www.nessus.org/

Nikto은 훌륭한 CGI(common gateway interface) 스크립트 스캐너입니다. Nikto는 CGI 취약점을 확인하는 기능을 갖추고 있을 뿐만 아니라 침입 탐지 시스템의 눈에 띄지 않고 찾아내기 어려운 방법을 사용합니다. 이 프로그램은 훌륭한 문서 자료가 함께 나와 있으므로 프로그램을 실행하시기 전에 주의깊게 읽어보시기 바랍니다. CGI 스크립트를 사용하는 웹 서버를 찾으신다면 Nikto를 사용하여 이 서버의 보안을 확인해보실 수 있습니다.

Nikto에 대한 보다 자세한 정보는 다음 URL에서 찾으실 수 있습니다:

http://www.cirt.net/code/nikto.shtml

VLAD는 Bindview, Inc 사의 RAZOR 팀에서 개발한 스캐너로서 취약성을 검사하는데 사용됩니다. 이 프로그램은 가장 흔한 보안 문제점 중 SANS 최상위 열가지 문제점 (SNMP 문제, 파일 공유 문제점 등)을 찾아냅니다. VLAD는 Nessus 만큼 완전한 기능을 갖추고 있지는 않지만 조사해 볼만한 가치가 있습니다.

VLAD에 대한 보다 자세한 정보는 RAZOR 팀 웹사이트인 다음 URL에서 찾으실 수 있습니다:

http://www.bindview.com/Support/Razor/Utilities/

여러분의 목표와 자원에 따라서 여러 다른 도구를 사용 가능합니다. 무선 네트워크, Novell 네트워크, Windows 시스템, 리눅스 시스템 등에 따른 여러 다른 도구가 있습니다. 평가 수행의 또 다른 중요한 부분은 물리적 보안을 검토하고 직원을 살펴보고 음성/PBX 네트워크를 평가하는 것입니다. war walking 무선 네트워크 취약점을 살펴보기 위해 기업체의 물리적 구조의 경계를 스캐닝하는 작업과 같은 새로운 개념을 조사해보시고 필요하다면 여러분의 평가 계획에 통합하십시오. 취약성 평가를 계획하고 수행하는 데는 여러분의 상상력과 경험 외에는 한계가 없습니다.

Red Hat Network를 사용하시면 대부분의 업데이트 과정이 자동화됩니다. 시스템에 필요한 RPM 패키지를 검색한 후 안전한 리포지터리에서 패키지들을 다운로드 받습니다. 그 후 패키지가 변경되지 않은 것을 확인하기 위해 RPM 서명을 검증 후 패키지를 업데이트 합니다. 패키지 설치는 즉시 시작될 수도 있고 정해진 시간에 시작되도록 계획하는 것도 가능합니다.

Red Hat Network를 통해 시스템을 업데이트하기 위해서는, 각 시스템마다 시스템 프로파일이 있어야 합니다. 시스템 프로파일에는 시스템에 대한 하드웨어와 소프트웨어 정보가 포함되어 있으며, 이 정보는 기밀로 보관되어 어느 누구에게도 공개되지 않습니다. 이 프로파일은 각 시스템에 어떠한 에라타 업데이트를 적용할 것인가를 결정하는데 사용되며, 이 프로파일이 없이는 Red Hat Network는 해당 시스템이 업데이트가 필요한지 여부를 판단할 수 없습니다. 보안 에라타 (또는 다른 종류의 에라타)가 출시될 경우, Red Hat Network는 에라타에 대한 설명과 에라타가 영향을 미치는 시스템의 목록을 함께 이메일로 보내드립니다. 업데이트를 신청하시려면, Red Hat Update Agent를 사용하시거나 http://rhn.redhat.com 웹사이트를 통해 패키지 업데이트를 계획하실 수 있습니다.

보안 에라타 리포트가 출시되면, Red Hat 에라타 웹사이트 http://www.redhat.com/security/에 발표됩니다. 이 페이지에서 시스템에 맞는 제품과 버전 번호를 선택해 주십시오. 그 후 페이지 상단에 위치한 security 를 선택하시면 Red Hat Enterprise Linux Security Advisories만 보실 수 있습니다. 시스템에 사용된 패키지와 관련된 보안 권고에 대한 시놉시스가 있다면, 보다 자세한 정보를 보기 위해 해당 시놉시스를 클릭하시기 바랍니다.

자세한 정보 페이지에는 보안 허점에 대한 정보와 함께 보안 상 문제점을 고치기 위한 패키지 업데이트 및 필요한 작업 실행 방법에 대한 지시 사항이 있습니다.

업데이트된 패키지(들)을 다운로드 받으시려면, Red Hat Network에 로그인 하셔서 패키지 이름에 클릭하신 후 하드 드라이브에 저장하시기 바랍니다. /tmp/updates와 같이 새로운 디렉토리를 생성하신 후 다운로드 받은 모든 패키지를 그 디렉토리에 저장하시길 적극 권장합니다.

모든 Red Hat Enterprise Linux 패키지는 Red Hat, Inc. GPG키로 서명되었습니다. GPG는 GNU Privacy Guard (GnuPG)의 줄임말로서 배포 파일의 인증을 확인하는데 사용되는 자유 소프트웨어 패키지를 말합니다. 예를 들면 Red Hat은 비밀키 (개인키)를 사용하여 패키지를 잠근 후 공개키를 사용하여 패키지를 잠금 해제 후 검증합니다. 만일 RPM 검증 과정에서 Red Hat에서 배포한 공개키가 비밀키와 일치하지 않는다면, 패키지가 변경되었을 수 있으므로 신뢰할 수 없습니다.

Red Hat Enterprise Linux에서 RPM 유틸리티를 사용하면 RPM 패키지를 설치하기 전에 자동적으로 패키지의 GPG 서명을 검증합니다. 만일 Red Hat GPG 키를 아직 설치하지 않으셨다면, Red Hat Enterprise Linux 설치 CD-ROM과 같이 안전한 곳에서 GPG 키를 받아 설치하시기 바랍니다.

CD-ROM이 /mnt/cdrom에 마운트되었다고 가정합시다. 다음 명령을 입력하시면 신뢰할 수 있는 키 목록을 기록한 데이터베이스인 keyring을 가져올 수 있습니다:

rpm --import /mnt/cdrom/RPM-GPG-KEY

RPM 검증을 위해 설치된 모든 키 목록을 보시려면, 다음 명령을 실행하십시오:

rpm -qa gpg-pubkey*

Red Hat키는 다음과 같이 출력됩니다:

gpg-pubkey-db42a60e-37ea5438

특정 키에 대한 자세한 정보를 보시려면, 다음 예시와 같이 rpm -qi 명령 다음에 이전 명령의 출력 결과를 함께 입력하시면 됩니다:

rpm -qi gpg-pubkey-db42a60e-37ea5438

RPM 파일들을 설치하시기 전에 반드시 파일의 서명을 검증하여 파일이 Red Hat, Inc.에서 출시한 패키지에서 변경되지 않았음을 확인하시기 바랍니다. 다운로드 받은 패키지들을 동시에 모두 검증하시려면, 다음 명령을 입력하십시오:

rpm -K /tmp/updates/*.rpm

각 패키지마다 GPG 키 검증을 성공적으로 마치면 gpg OK라는 메시지가 나타납니다. 만일 검증이 성공적이지 않다면 우선 올바른 Red Hat 공개키를 사용하고 있는지 확인하시고 원인을 알아보시기 바랍니다. GPG 검증에 실패한 패키지는 제3자에 의해 변경되었을 가능성이 있으므로 설치하지 마시기 바랍니다.

GPG 키 검색과 에라타 리포트와 관련된 모든 패키지를 다운로드 받으셨다면, 쉘 프롬프트에서 루트로 로그인 하신 후 패키지를 설치하시기 바랍니다.

다음 명령을 입력하여 패키지를 안전하게 설치하실 수 있습니다 (커널 패키지 제외):

rpm -Uvh /tmp/updates/*.rpm

커널 패키지의 경우 다음 명령을 사용하시기 바랍니다:

rpm -ivh /tmp/updates/<kernel-package>

앞의 예시에서 <kernel-package> 부분을 커널 RPM의 이름으로 대체하시기 바랍니다.

새로운 커널을 사용하여 컴퓨터가 안전하게 재부팅한 후에는 다음 명령을 사용하여 이전 커널을 제거하셔도 됩니다:

rpm -e <old-kernel-package>

앞의 예시에서 <old-kernel-package> 부분을 이전 커널 RPM 이름으로 대체해 주십시오.

Red Hat Network 또는 Red Hat 에라타 웹사이트를 통해 보안 에라타를 다운로드 받고 설치하신 후, 이전 소프트웨어 사용을 중단하시고 새로운 소프트웨어를 사용하셔야 합니다. 업데이트된 소프트웨어의 종류에 따라서 이 방법이 달라집니다. 다음 목록은 일반 소프트웨어 종류와 패키지 업그레이드 후 업데이트된 버전을 사용하는 방법을 보여줍니다.

TCP 래퍼는 서비스로의 액세스를 거부하는 것 이외에도 다른 많은 기능을 제공합니다. 이 부분에서는 TCP 래퍼를 사용하여 연결 배너를 보내고, 특정 호스트에서 침입자에게 경고 메시지를 보내며, 기록 기능을 강화하는 방법에 대하여 설명하고 있습니다. TCP 래퍼의 기능과 제어 언어에 대한 전체적인 목록을 보시려면 hosts_options 메뉴얼 페이지를 참조하시기 바랍니다.

 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed. 

 vsftpd : ALL : banners /etc/banners/ 

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert 

 in.telnetd : ALL : severity emerg 

이 부분에서는 xinetd를 사용하여 트랩(trap) 서비스를 설정하는 방법과 xinetd 서비스가 사용할 수 있는 자원의 양을 제어하는 방법에 대하여 중점적으로 설명해 보겠습니다. 서비스가 사용할 수 있는 자원의 한계를 설정하면 서비스 거부 (DoS) 공격을 좌절시킬 수 있습니다.모든 사용 가능한 옵션의 목록을 보시려면 xinetd 및 xinetd.conf의 메뉴얼 페이지를 참조하시기 바랍니다.

flags           = SENSOR

deny_time       = 30

disable         = no

portmap 서비스에는 내장된 인증 방식이 없으므로 TCP 래퍼를 사용하여 이 서비스를 사용할 수 있는 네트워크나 호스트를 제한하는 것이 중요합니다.

또한 서비스로 접근을 제한하실 때는 IP 주소만 사용하셔야 합니다. 호스트명은 DNS poisoning이나 다른 방법으로 위조가 가능하므로 사용하지 마십시오.

portmap 서비스로 접근을 더 제한하시려면 서버에 iptables 규칙을 추가하여 특정 네트워크로 접근하는 것을 제한하시는 것이 좋습니다.

다음은 (포트 111을 청취하는) portmap 서비스로 192.168.0/24 네트워크와 로컬호스트에서 TCP 연결을 허용하는 두가지 IPTables 명령 예시입니다. Nautilus가 sgi_fam 서비스를 사용하는데 필요한 설정입니다. 모든 다른 패킷은 버립니다(drop).

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1  --dport 111 -j ACCEPT

이와 유사한 방식으로 UDP 트래픽을 제한하기 위해서는 다음 명령을 사용하십시오.

iptables -A INPUT -p udp -s! 192.168.0.0/24  --dport 111 -j DROP

NIS는 네트워크 상에서 기밀 정보를 암호화되지 않은 상태에서 전달하기 때문에 서비스를 분할되고 안전한 네트워크 상에서 방화벽을 사용한 상태에서 서비스를 실행해야 합니다. 비보안 네트워크 상에서 NIS 정보가 전달될 때마다 누군가 정보를 가로챌 위험이 있습니다. 이러한 의미에서 네트워크를 신중히 설정함으로서 심각한 보안 침입 위협을 방지할 수 있습니다.

NIS 도메인 내에 위치한 컴퓨터에서 사용자가 NIS 서버의 DNS 호스트명과 NIS 도메인 이름만 알고 있다면 인증을 거치지 않고 서버에서 정보를 유출하는 것이 가능합니다.

예를 들어 만일 누군가 네트워크에 랩탑 컴퓨터를 연결하거나 외부에서 네트워크에 침입하여 내부 IP 주소를 위장할 수 있다면 다음 명령을 사용하여/etc/passwd 파일의 내용을 보는 것이 가능합니다:

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

만일 이 침입자가 루트 사용자 권한을 가지고 있다면 다음과 같은 명령을 입력하여 /etc/shadow 파일의 내용을 볼 수 있습니다:

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

침입자가 NIS map에 액세스하는 것을 보다 힘들게 하기 위하여 DNS 호스트명을 o7hfawtgmhwg.domain.com와 같은 임의 문자열로 생성하시는 것이 좋습니다. 유사한 방법으로 NIS 도메인 이름도 임의 문자열로 생성하시되 호스트명과 다른 이름을 생성하십시오. 이렇게 하시면 침입자가 NIS 서버에 액세스하는 것이 더욱 힘들어 집니다.

/var/yp/securenets 파일이 공백으로 비어있거나 (기본 설치를 수행한 후) 파일이 존재하지 않는 경우 NIS는 모든 네트워크를 청취합니다. 이러한 경우 가장 먼저 하실 것은 ypserv가 적절한 네트워크에서 들어오는 요청만 응답하도록 이 파일에 넷마스크/네트워크 쌍을 입력하셔야 합니다.

다음은 /var/yp/securenets 파일 예제입니다:

255.255.255.0     192.168.0.0

이 기술은 IP 스푸핑 공격에 대한 보호를 제공하지는 못하지만 최소한 NIS 서비스가 청취할 네트워크를 제한해줍니다.

NIS와 관련된 모든 서버에 특정 포트를 할당하는 것이 가능하지만 사용자가 로그인 암호를 변경할 수 있게 해주는 데몬인 rpc.yppasswdd는 예외입니다. 다른 두 개의 NIS 서버 데몬인 rpc.ypxfrd와 ypserv에 포트를 할당함으로서 방화벽 규칙을 생성하여 침입자가 NIS 서버 데몬에 침입하지 못하도록 보안을 강화할 수 있습니다.

이러한 설정을 위해 /etc/sysconfig/network 파일에 다음과 같은 줄을 삽입하시기 바랍니다:

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

다음 iptables 규칙을 입력하여 이 포트에서 서버가 청취할 네트워크를 제한 설정하실 수 있습니다:

iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 834 -j DROP
iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 835 -j DROP

이는 192.168.0.0/24 네트워크에서 요청이 들어올 경우, 프로토콜에 상관없이 서버는 834와 835포트로의 연결만을 허용함을 의미합니다.

NIS 인증이 사용될 경우 가장 심각한 결점은 사용자가 시스템에 로그인할 때마다 /etc/shadow 파일의 암호 해시가 네트워크 상에서 전달되는 것입니다. 만일 침입자가 NIS 도메인에 침입하여 네트워크 트래픽을 훔쳐보고 있다면 사용자명과 암호 해시를 모르게 수집할 수 있습니다. 충분한 시간이 주어진다면 암호 크래킹 프로그램을 사용하여 추측하기 쉬운 암호를 알아낸 후 침입자는 유효한 계정을 사용하여 네트워크에 액세스 가능합니다.

NFSv4는 네트워크 상에서 모든 정보를 커베로스를 사용하여 암호화하여 전달할 수 있으므로, 방화벽이나 분활된 네트워크 상에서 올바르게 서비스를 설정하셔야 합니다. NFSv2와 NFSv3는 여전히 정보를 암호화되지 않은 상태로 전달하기 때문에 이러한 점이 고려되어야 합니다. 따라서 네트워크를 신중히 설정함으로서 심각한 보안 침입 위협을 방지할 수 있습니다.

NFS 서버는 /etc/exports 파일을 통해 어느 파일 시스템은 익스포트할 것이고 이 디렉토리를 익스포트할 호스트는 무엇인지 결정합니다. 따라서 이 파일을 수정하실 때 불필요한 공간을 추가하지 않도록 주의하셔야 합니다.

예를 들어 /etc/exports 파일에서 다음과 같은 줄은 bob.example.com 호스트에서 /tmp/nfs/ 디렉토리를 읽고 쓸 수 있도록 공유합니다.

/tmp/nfs/     bob.example.com(rw)

반면 /etc/exports 파일에 이 줄을 삽입하시면 호스트명 다음에 삽입된 빈 공간 때문에 동일한 디렉토리를 bob.example.com에 읽기 전용 허가를 가지고 공유하고 그 외 다른 전체 호스트에 읽기 쓰기 허가를 가지고 이 디렉토리를 공유합니다.

/tmp/nfs/     bob.example.com (rw)

따라서 showmount 명령을 사용하여 어떠한 디렉토리가 어떻게 공유되고 있는지 NFS 공유 설정을 확인해보시기 바랍니다:

showmount -e <hostname>

NFS 공유는 루트 사용자를 특별한 권한이 없는 사용자 계정인 nfsnobody로 변경하도록 기본 설정되어 있습니다. 따라서 루트 사용자가 생성한 파일은 모두 nfsnobody가 소유하게 되어 사용자 아이디 비트를 재설정하여 프로그램을 업로드하지 못하게 됩니다.

만일 no_root_squash 옵션을 사용하시면 원격 루트 사용자가 공유 파일 시스템에서 모든 파일을 변경할 수 있으며 트로이 목마 프로그램을 설치하여 다른 사용자가 의도하지 않게 실행하게 됩니다.

이 지시자는 기본값으로 활성화되어 있습니다. 따라서 웹 서버의 문서 루트로 심볼릭 링크를 생성하실 때는 주의하시기 바랍니다. 예를 들어 /로 심볼릭 링크를 제공하는 것은 좋은 생각이 아닙니다.

이 지시자는 기본 값으로 활성화되어 있지만, 그리 바람직하지 않습니다. 침입자가 서버에서 파일을 검색하는 것을 방지하기 위해 이 지시자를 삭제하시기 바랍니다.

UserDir 지시자는 침입자가 시스템 상에 사용자 계정이 존재하는지 확인할 수 있기 때문에 비활성화되도록 기본 설정되어 있습니다. 서버에서 사용자 디렉토리 검색 기능을 활성화하시려면 다음 지시자를 사용하시기 바랍니다:

UserDir enabled
UserDir disabled root

이 지시자는 사용자 디렉토리 검색 기능을 /root/를 제외한 모든 사용자 디렉토리에서 활성화할 것입니다. 비활성 계정 목록에 사용자를 추가하시려면 UserDir disabled 줄에 사용자 이름을 빈칸으로 구분하여 추가하십시오.

Server-Side Includes (SSI) 모듈에서는 명령을 실행하지 못하도록 기본 설정되어 있습니다. 만일 절대적으로 필요한 경우가 아니라면 이 설정을 변경하지 마십시오. 이 설정을 변경하시면 침입자가 시스템에서 명령을 실행할 위험이 높아집니다.

스크립트나 CGI를 포함한 디렉토리에는 루트 사용자에게만 쓰기 허가를 부여하셔야 합니다. 다음 명령을 입력하시기 바랍니다:

chown root <directory_name>
chmod 755 <directory_name>

사용자명과 암호를 입력하기 전에 환경 배너가 나타납니다. 이 배너에는 버전 정보가 포함되어 있으며, 이 정보는 크래커가 시스템 약점을 찾아내는데 유용하게 사용됩니다.

따라서 vsftpd의 환영 배너를 변경하시려면 /etc/vsftpd/vsftpd.conf 파일에 다음 지시자를 추가하시기 바랍니다:

ftpd_banner=<insert_greeting_here>

위의 지시자에서 <insert_greeting_here> 부분에 새로운 환영 메시지를 입력하십시오.

여러 개의 줄로 이루어진 배너 메시지를 입력하시려면 배너 파일을 사용하시는 것이 좋습니다 여러 배너를 손쉽게 관리하기 위하여 /etc/banners/라는 새 디렉토리를 만드신 후 모든 패너 파일을 이 디렉토리에 저장하십시오. 이 예시에서 FTP 접속에 사용되는 배너 파일은 /etc/banners/ftp.msg 입니다. 다음은 이 파일의 내용 예제입니다:

######### # 안녕하세요, ftp.example.com에 있는 모든 작업은 기록됩니다. #########

vsftpd에 이 환경 배너 파일을 사용하기 위해서는 /etc/vsftpd/vsftpd.conf 파일에 다음과 같은 지시자를 추가하십시오:

banner_file=/etc/banners/ftp.msg

또한 2.1.1.1.1절. “TCP 래퍼와 연결 배너”에서 설명된 것처럼 TCP 래퍼를 사용하여 들어오는 연결에 추가 배너 메시지를 보내는 것도 가능합니다.

/var/ftp/ 디렉토리를 생성하시면 익명 계정이 활성화됩니다.

이 디렉토리를 생성할 수 있는 가장 쉬운 방법은 vsftpd 패키지를 설치하는 것입니다. 이 패키지는 익명 사용자를 위한 디렉토리 구조를 설정하고, 익명 사용자에게 이 디렉토리를 읽기만 할 수 있는 허가를 설정합니다.

익명 사용자는 어느 디렉토리에도 쓰기 작업을 할 수 없도록 기본 설정되어 있습니다.

mkdir /var/ftp/pub/upload

chmod 730 /var/ftp/pub/upload

drwx-wx---    2 root     ftp          4096 Feb 13 20:05 upload

anon_upload_enable=YES

FTP는 비보안 네트워크 상에서 인증을 위해 암호화되지 않은 사용자명과 암호를 전달하기 때문에 시스템 사용자가 사용자 계정을 통해 서버에 접속하는 것을 거부하도록 설정하는 것이 좋습니다.

vsftpd에서 사용자 계정을 비활성화하시려면 /etc/vsftpd/vsftpd.conf 파일에 다음 지시자를 추가하십시오:

local_enable=NO

2.1.1.1절. “TCP 래퍼를 사용하여 보안 강화하기”에서 설명된 것처럼 FTP 데몬으로 접근을 제어하기 위해서 TCP 래퍼를 사용하십시오.

이메일의 특성상, 침입자는 비교적 간단히 서버에 다량의 이메일을 집중적으로 보내어 서비스 거부 현상을 야기시킬 수 있습니다. /etc/mail/sendmail.mc에 다음과 같은 지시자를 제한 설정하여 이와 같은 서비스 거부 공격이 발생할 가능성을 줄일 수 있습니다.

절대로 메일 스풀 디렉토리인 /var/spool/mail/를 NFS 공유 볼륨에 놓지 마십시오.

NFSv2와 NFSv3는 사용자 그룹 ID를 관리 제어하지 않으므로 두 명 이상의 사용자가 동일한 UID를 가질 수 있습니다. 따라서 서로의 메일을 받고 읽는 것이 가능해집니다.

이렇게 로컬 사용자가 Sendmail 서버를 악용하는 것을 방지하기 위하여 메일 사용자는 이메일 프로그램을 사용하여 Sendmail 서버만 사용하도록 설정하시는 것이 좋습니다. 메일 사용자는 메일 서버에서 쉘 계정을 갖지 못하고 /etc/passwd 파일에서 모든 메일 사용자 쉘은 /sbin/nologin으로 설정하셔야 합니다. (루트 사용자 예외)

각각의 PAM-aware 응용 프로그램이나 서비스는 /etc/pam.d/ 디렉토리에 파일을 갖습니다. 이 디렉토리에 있는 각각의 파일은 액세스를 제어하는 서비스와 같은 이름을 갖습니다.

PAM-aware 프로그램은 자신의 서비스명을 정의하고 /etc/pam.d/ 디렉토리에 PAM 설정 파일을 설치합니다. 예를 들어, login 프로그램은 login으로 자신의 서비스명을 정의하고 /etc/pam.d/login PAM 설정 파일을 설치합니다.

현재 네 가지 유형의 PAM 모듈 인터페이스가 사용 가능합니다. 각각의 유형은 권한 부여 과정의 다른 양상을 띠고 있습니다.

PAM 설정 파일에서, 모듈 인터페이스는 처음으로 정의되어야 할 영역입니다. 예를 들어, 설정에서 나타나는 전형적인 줄은 다음과 같습니다:

auth        required        pam_unix.so

이는 PAM이 pam_unix.so 모듈의 auth 인터페이스를 사용하게 합니다.

[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth        sufficient        pam_rootok.so
auth        required        pam_console.so
#auth        include        system-auth
account        required        pam_permit.so

모든 PAM 모듈은 호출되었을 때 성공 또는 실패 결과를 생성합니다. 제어 플래그는 PAM에게 결과에 어떻게 대응할 지를 지시합니다. 모듈은 특정한 순서로 스택될 수 있으며, 제어 플래그는 특정 모듈의 성공 또는 실패 결과가 사용자를 서비스에 인증하게 하는 전체 목적에 얼마나 중요한 지를 결정합니다.

네 개의 미리 정의된 제어 플래그입니다:

보다 정교하게 제어할 수 있는 새로운 제어 플래그 구문이 현재 PAM에서 사용 가능합니다.

/usr/share/doc/pam-<version-number>/ 디렉토리에 있는 pam.d 메뉴얼 페이지와 PAM 문서는 이러한 새로운 구문에 대하여 자세하게 설명합니다. 여기서<version-number>는 시스템에 있는 PAM의 버전 번호로 대체합니다.

모듈명은 특정 모듈 인터페이스를 포함하는 장착식 모듈 명과 함께 PAM을 제공합니다. Red Hat Enterprise Linux 버전 순서에서, 모듈로의 완전한 경로는 PAM 설정 파일에 제공되지만, /lib64/security/ 디렉토리에 있는 64비트 PAM 모듈을 저장할 수 있는 multilib 시스템이 나타나면서, 디렉토리명이 생략되었습니다. 이는 응용 프로그램이 올바른 모듈 버전을 배치할 수 있는 libpam 버전에 링크되기 때문입니다.

PAM은 몇몇 모듈에 대해 인증하는 동안 인자를 사용하여 장착식 모듈에 정보를 전달합니다.

예를 들어, pam_userdb.so 모듈은 Berkeley DB 파일에 저장된 정보를 사용하여 사용자를 인증합니다. Berkeley DB는 많은 응용 프로그램에 내장된 오픈 소스 데이터베이스 시스템입니다. 모듈이 db 인자를 갖음으로서 Berkeley DB는 어떤 데이터베이스가 요청된 서비스에 사용되는 지를 알게 됩니다.

다음은 PAM 설정에서의 전형적인 pam_userdb.so 줄입니다. <path-to-file>는 Berkeley DB 데이터베이스 파일로의 완전 경로로 대체합니다.

auth        required        pam_userdb.so db=<path-to-file>

잘못된 인자는 일반적으로 무시되며 PAM 모듈의 성공 또는 실패 결과에 영향을 미치지 않습니다. 하지만, 몇개의 모듈은 잘못된 인자로 인해 실패될 수 도 있습니다. 대부분의 모듈은 /var/log/secure 파일에 오류를 보고합니다.

PAM 타임스탬프가 활성화되는 곳에서 콘솔을 배제하기 전에, 타임스탬프 파일을 삭제시킬 것을 권장합니다. 그래픽 환경에서 이를 실행하기 위해, 패널 상의 인증 아이콘을 클릭하면 대화 상자가 나타납니다. 관리자 권한 해제하기 버튼을 클릭하여 활성화된 타임스탬프 파일을 삭제합니다.

인증 해제 대화 상자의 예시

그림 2.2. 인증 다이얼로그 해제

PAM 타임스탬프 파일에 대해 다음 사항을 주의하시기 바랍니다:

pam_timestamp_check를 사용하여 타임스탬프 파일을 삭제하는 것에 관한 보다 자세한 정보는 pam_timestamp_check 메뉴얼 페이지를 참조하시기 바랍니다.

pam_timestamp.so 모듈은 여러 지시문을 허용합니다. 다음은 가장 일반적으로 사용되는 두 개의 옵션입니다:

pam_timestamp.so 모듈 제어에 관한 보다 자세한 정보는 2.2.8.1절. “설치된 문서”에서 참조하시기 바랍니다.

사용자가 Red Hat Enterprise Linux 시스템에 로그인할 때, pam_console.so 모듈은 login 또는 그래픽 로그인 프로그램, gdm, kdm, xdm에 의해 호출됩니다. 이러한 사용자가 물리적 콘솔에 로그인하는 첫 번째 사용자일 경우 — console user로 불려짐 — 모듈은 일반적으로 루트 사용자에 의해 소유되었던 여러 장치의 사용자 소유권이 확장됩니다. 콘솔 사용자는 사용자의 마지막 로컬 세션이 끝날때 까지 이러한 장치를 소유합니다. 이러한 사용자가 로그 아웃한 후, 장치의 소유권은 루트 사용자에게로 복귀됩니다.

영향을 미치는 장치에는 사운드 카드, 디스켓 드라이브, CD-ROM 드라이브가 포함되지만, 이에 제한되지는 않습니다.

이러한 장치는 로컬 사용자가 루트 액세스 없이 이러한 장치를 조작하는 것을 허용하므로, 콘솔 사용자를 위한 일반적인 작업을 단순화시킬 수 있습니다.

다음의 파일을 편집하여 pam_console.so에 의해 제어되는 장치 목록을 수정하실 수 있습니다.

위의 파일 목록보다는 다른 장치의 사용 권한을 변경하시거나 또는 특정 기본값으로 덮어쓰실 수 있습니다. 50-default.perms 파일을 수정하는 대신, 새로운 파일을 생성하시고 (예, xx-name.perms) 필요한 사항을 수정하시기 바랍니다. 새로운 기본 파일명은 50 이상의 숫자로 시작해야 합니다. (예, 51-default.perms) 이는 50-default.perms 파일에 있는 기본값을 덮어 쓰게 됩니다.

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 
<xconsole>=:0\.[0-9] :0

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

콘솔 사용자는 /etc/security/console.apps/ 디렉토리에서 사용하도록 설정된 특정 프로그램에도 액세스합니다.

이 디렉토리에는 콘솔 사용자가 /sbin and /usr/sbin에 있는 특정 응용 프로그램을 실행할 수 있는 설정 파일이 포함되어 있습니다.

이 설정 파일에는 콘솔 사용자가 설정한 응용 프로그램과 같은 이름이 있습니다.

콘솔 사용자가 액세스한 주목할만한 응용 프로그램 그룹 중 하나는 시스템을 종료하거나 재부팅하는 세가지 프로그램입니다:

이는 PAM-aware 응용 프로그램이므로, 사용을 위한 기본 조건으로서 pam_console.so 모듈을 호출합니다.

보다 자세한 정보는 2.2.8.1절. “설치된 문서”에서 참조하시기 바랍니다.

호스트간 IPsec 연결은 두 시스템 사이에서 암호화된 연결이어야 하며, 같은 인증키를 사용하고 IPsec을 실행하여야 합니다. IPsec 연결이 활성화되었을 경우, 두 호스트사이의 모든 네트워크 소통은 암호화됩니다.

호스트간 IPsec 연결을 설정하기 위해,각각의 호스트에 사용하는 단계는 다음과 같습니다:

IPsec 연결을 설정한 후에, 그림 2.3. “IPsec 연결”에서 볼 수 있듯이 이는 IPsec 목록에 나타납니다.

IPsec 연결

그림 2.3. IPsec 연결

IPsec 연결이 설정되면 다음의 파일이 생성됩니다:

자동 암호화가 선택되면, /etc/racoon/racoon.conf 역시 생성됩니다.

인터페이스가 나타나면, <remote-ip>.conf를 포함하기 위해 /etc/racoon/racoon.conf가 수정됩니다.

연결을 생성하는 첫번째 단계는 각 워크스테이션의 시스템 정보와 네트워크 정보를 모으는 것입니다. 호스트 간 연결을 위해서는 다음과 같은 정보를 수집하셔야 합니다:

예를 들어 워크스테이션 A와 워크스테이션 B가 IPsec터널을 통하여 연결하고자 한다고 가정합니다. Key_Value01의 값을 이미 공유된 키로 사용하여 연결하고자 하며, 양 사용자가 racoon 데몬이 자동으로 인증키를 생성하여 각 호스트 간에 공유하는 것에 동의하여 이 연결을 ipsec1으로 이름 붙였다고 가정합니다.

다음은 워크스테이션 B와 호스트 간 IPsec을 연결하기 위해 사용된 워크스테이션 A의 IPsec 설정 파일입니다. 이 예시에서 이 연결을 식별하기 위해 사용된 고유 이름은 ipsec1이므로 결과적으로 파일 이름은 /etc/sysconfig/network-scripts/ifcfg-ipsec1이 됩니다.

DST=X.X.X.X
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK

워크스테이션 A는 X.X.X.X 부분을 워크스테이션 B의 IP 주소로 대체하고, 워크스테이션 B는 X.X.X.X를 워크스테이션 A의 IP 주소로 대체합니다. 이 연결은 부팅시 시작되도록 (ONBOOT=no) 설정되지 않았으며 이미 공유된 키 인증 방식 (IKE_METHOD=PSK)을 사용합니다.

다음은 이미 공유된 키 파일 (/etc/sysconfig/network-scripts/keys-ipsec1)의 내용입니다. 이 파일은 양 워크스테이션이 상대방을 인증하는데 필요합니다. 이 파일의 내용은 양 컴퓨터에서 동일해야 하며 루트 사용자만이 이 파일을 읽거나 수정할 수 있습니다.

IKE_PSK=Key_Value01

[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

언제든지 인증키를 변경하시려면 양 워크스테이션에서 keys-ipsec1 파일을 수정하시면 됩니다. 양 키가 동일해야만 제대로 연결할 수 있습니다.

다음은 원격 호스트로 1 단계 연결하는데 사용되는 설정 파일의 예입니다. 이 파일의 이름은 X.X.X.X.conf입니다 (여기서 X.X.X.X는 원격 IPsec 호스트의 IP 주소로 대체하십시오). 이 파일은 IPsec 터널이 활성화되면 자동으로 생성되기 때문에 직접 수정하시면 안됩니다.

remote X.X.X.X
{
         exchange_mode aggressive, main;
         my_identifier address;
         proposal {
                 encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

IPsec 연결이 초기화될때 생성된 기본 단계 1 설정 파일에는 Red Hat Enterprise Linux가 IPsec를 구현하는데 사용하는 다음과 같은 문구가 포함됩니다:

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";

[root@myServer ~]# /sbin/ifup <nickname>

[root@myServer ~]# tcpdump -n -i eth0 host <targetSystem>

IP 172.16.45.107 
> 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)

네트워크 간 IPsec 연결에서는 사설 서브넷에 대한 네트워크 소통을 라우트하여 각각의 네트워크에 하나씩 두개의 IPsec 라우터를 사용합니다.

예를 들어, 그림 2.5. “네트워크 간 IPsec”에서 볼 수 있듯이, 192.168.1.0/24 사설 네트워크가 192.168.2.0/24 사설 네트워크로 네트워크 소통을 할 경우, 패킷은 gateway0를 통해 ipsec0로 이동하며, 인터넷을 통해 ipsec1, gateway1, 192.168.2.0/24 서브넷으로 이동합니다.

IPsec 라우터에는 공개적으로 주소를 지정할 수 있는 IP 주소와 사설 네트워크와 연결된 다른 이더넷 장치가 있어야 합니다. 암호화된 연결이 있는 다른 IPsec 라우터를 통해 소통하려할 경우, IPsec 라우터만을 통해 소통이 이루어집니다.

네트워크 간 IPsec

그림 2.5. 네트워크 간 IPsec

각 IP 라우터와 인터넷 간의 방화벽 및 각 IPsec 라우터와 서브넷 게이트웨이 간의 인트라넷 방화벽을 포함하는 네트워크 설정 대체 옵션. 서브넷의 IPsec 라우터와 게이트웨이는 두개의 이더넷 장치를 가진 하나의 시스템이 될 수 있습니다: 하나는 공개 IP 주소를 가지고 IPsec 라우터로 작동하며; 다른 하나는 사설 IP 주소를 가지고 사설 서브넷에 대한 게이트웨이로 작동합니다. 각각의 IPsec 라우터는 사설 네트워크 또는 공개 게이트웨이에 대해 게이트웨이를 사용하여 패킷을 다른 IPsec 라우터로 전송합니다.

다음과 같은 과정을 실행하여 네트워크 간 IPsec 연결을 설정합니다:

IPsec 연결을 활성화하기 위한 네트워크 스크립트는 자동으로 네트워크 라우터를 생성하여 필요한 경우 IPsec 라우터를 통해 패킷을 전송합니다.

예를 들어 LANA (lana.example.com)와 LAN B (lanb.example.com)가 IPsec 터널을 통하여 서로 연결하고자 한다고 가정합니다. LAN A의 네트워크 주소는 192.168.1.0/24 범위에 속하고 LAN B의 네트워크 주소는 192.168.2.0/24 범위를 사용한다고 합시다. LAN A의 게이트웨이 IP 주소는 192.168.1.254 이며 LAN B의 게이트위에 IP 주소는 192.168.2.254 입니다. IPsec 라우터는 각각의 LAN에서 분리되어 두개의 네트워크 장치를 사용합니다: eth0는 인터넷에 접속하는 외부에서 접근 가능한 정적 IP 주소에 할당되었으며, 반면 eth1은 한 네트워크 노드에서 원격 네트워크 노드로 LAN 패킷을 처리하고 전송하는 라우팅 지점으로 사용됩니다.

각 네트워크 간 IPsec 연결은 r3dh4tl1nux을 이미 공유된 키로 사용하며 A와 B의 관리자가 racoon 데몬이 자동으로 인증키를 생성하고 각 IPsec 라우터 간에 인증키를 공유하도록 동의했다고 가정합니다. LAN A의 관리자는 IPsec 연결을 ipsec0이라 이름 붙인 반면 LANB의 관리자는 IPsec 연결을 ipsec1이라고 이름 붙였습니다.

다음 예시는 LAN A에서 네트워크 간 IPsec 연결에 사용된 ifcfg 파일의 내용을 보여줍니다. 이 예시에서 이 연결을 식별하기 위해 사용된 고유 이름은 ipsec0입니다, 따라서 결과적으로 파일 이름은 /etc/sysconfig/network-scripts/ifcfg-ipsec0이 됩니다.

TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X

다음의 목록은 이 파일의 내용을 설명합니다:

다음은 /etc/sysconfig/network-scripts/keys-ipsecX 기존 공유 키 파일 (여기서 X는 LAN A의 경우 0이며 LAN B는 1 입니다)의 내용으로서 이 파일은 양 네트워크가 상대방을 인증하는데 사용됩니다. 이 파일의 내용은 두 네트워크에서 동일해야 하며 루트 사용자만이 이 파일을 읽거나 작성할 수 있습니다.

IKE_PSK=r3dh4tl1nux

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

언제든지 인증키를 변경하려면 양 IPsec 라우터에서 keys-ipsecX 파일을 수정합니다. 반드시 양 키가 같아야 제대로 연결됩니다.

다음은 IPsec 연결에 사용된 /etc/racoon/racoon.conf 설정 파일입니다. 파일 마지막 부분의 include 부분은 자동으로 생성되며 IPsec 터널이 실행된 경우에만 나타납니다.

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
  
sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

다음은 원격 네트워크로 연결하는데 사용되는 설정 파일입니다. 파일의 이름은 X.X.X.X.conf이며 여기서 X.X.X.X를 원격 IPsec 라우터의 IP 주소로 대체합니다. 이 파일은 IPsec 터널이 활성화되면 자동으로 생성되기 때문에 직접 수정하시면 안됩니다.

remote X.X.X.X
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

IPsec 연결을 시작하기 전에 커널에서 IP fowarding 기능을 활성화합니다. IP forwarding 기능을 활성화하려면 다음 명령을 실행합니다:

IPsec 연결을 시작하려면 각 라우터에서 다음 명령을 실행합니다:

[root@myServer ~] # /sbin/ifup ipsec0

LAN A와 LAN B가 서로 통신할 수 있도록 연결이 활성화됩니다. IPsec 연결에서 ifup을 실행하여 호출된 초기화 스크립트에 의해 라우트가 자동으로 생성됩니다. 네트워크 상 라우트 목록을 보시려면, 다음 명령을 실행합니다:

[root@myServer ~] # /sbin/ip route list

IPsec 연결을 테스트하시려면 tcpdump 유틸리티를 외부에서 라우팅가능한 장치 (이 예시에서는 eth0)에서 실행하여 호스트 간 (네트워크 간)에 전송되는 네트워크 패킷이 IPsec을 사용하여 암호화되었는지 확인하시기 바랍니다. 예를 들어 LAN A의 IPsec 연결을 확인해보시려면 다음 명령을 입력합니다:

[root@myServer ~] # tcpdump -n -i eth0 host lana.example.com

패킷은 AH 헤더를 포함해야 하며 ESP 패킷으로 보여져야 하니다. ESP는 패킷이 암호화되었다는 것을 의미합니다. 예를 들면 (백슬래쉬는 한 줄이 계속 된다는 것을 의미합니다):

12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \
        lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
        (ipip-proto-4)

여러 iptables 명령은 다음과 같은 구조를 가지고 있습니다:

 iptables [-t <table-name>] <command><chain-name> \ <parameter-1><option-1> \ <parameter-n><option-n>

<table-name> — 어떤 테이블에 규칙을 적용할 지를 지정합니다. 지정하지 않으신 경우, filter 테이블이 사용됩니다.

<command> — 규칙 추가 또는 삭제와 같은 실행할 작업을 지정합니다.

<chain-name> —수정, 생성, 삭제할 chain을 지정합니다.

<parameter>-<option> 쌍 — 규칙에 일치하는 패킷을 실행하는 방법을 지정하는 매개 변수 및 관련된 옵션입니다.

iptables 명령의 길이 및 복잡성은 목적에 따라 현저하게 변경될 수 있습니다.

예를 들어, chain에서 규칙을 삭제하기 위한 명령의 길이가 짧을 수 도 있습니다:

iptables -D <chain-name> <line-number>

반면, 여러 특정 매개변수와 옵션을 사용하는 특정 서브넷에서 패킷을 필터링하는 규칙을 추가하는 명령은 다소 길어질 수 있습니다. iptables 명령을 구축할 때, 몇몇 매개 변수와 옵션은 유효한 규칙을 구축하기 위해 추가 매개 변수 및 옵션을 요구한다는 점을 기억해두시기 바랍니다. 이는 더 많은 매개변수를 요구하는 추가 매개 변수와 함께 캐스캐이딩(cascading) 효과를 창출할 수 있습니다. 다른 옵션을 요구하는 모든 매개변수 및 옵션을 만족시킬때 까지, 규칙은 유효하지 않게 됩니다.

iptables -h를 입력하여 iptables 명령 구조의 종합적인 목록을 봅니다.

명령 옵션은 특정 작업을 실행하기 위해 iptables를 사용합니다. 하나의 명령 옵션에 하나의 iptables 명령만이 허용됩니다. 도움말 명령을 제외하고 모든 명령은 대문자로 쓰여져 있습니다.

iptables 명령은 다음과 같습니다:

특정 chain 안에서 규칙의 추가, 삭제, 삽입 또는 대체에 사용되는 특정 iptables 명령은 패킷 필터링 규칙을 구성하기 위해 다양한 매개 변수를 필요로 합니다.

다른 네트워크 프로토콜은 프로토콜을 사용하여 특정 패킷이 일치하도록 설정할 수 있는 특수화된 일치 옵션을 제공합니다. 하지만, 프로토콜은 iptables 명령에 먼저 지정되어야 합니다. 예를 들어, -p <protocol-name>은 특수화된 프로토콜에 해당하는 옵션을 활성화합니다. 프로토콜명을 사용하는 데신 프로토콜 ID를 사용하실 수 있음에 유의하시기 바랍니다. 같은 효과를 갖는 다음의 예를 참조하시기 바랍니다:

 iptables -A INPUT -p icmp --icmp-type any -j ACCEPT  iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT 

서비스 정의는 /etc/services 파일에 있습니다. 가독성을 위해, 포트 번호를 사용하는 데신 서비스명을 사용하실 것을 권장합니다.

 [root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services 

패킷이 특정 규칙과 일치할 때, 규칙은 패킷을 알맞은 작업을 결정하게 하는 여러 다른 대상에 지정합니다. 각각의 chain은 기본 대상을 가지고 있으며, 이는 chain에서 어떤 규칙도 패킷에 일치하지 않거나 또는 패킷에 일치하는 어떤 규칙도 대상을 지정할 수 없는 경우입니다.

다음은 기준이 되는 대상입니다:

또한, 다른 대상을 지정하게 하는 확장 모듈이 사용 가능합니다. 이러한 확장 모듈은 대상 모듈 또는 일치 옵션 모듈이라고 불리우며, 특정 테이블과 상황에만 적용됩니다. 일치 옵션 모듈에 관한 보다 자세한 정보는 2.4.3.4.4절. “추가 일치 옵션 모듈”에서 참조하시기 바랍니다.

여러 확장된 대상 모듈이 있으며, 대부분 특정 테이블이나 상황에만 적용됩니다. Red Hat Enterprise Linux에서 기본값으로 포함된 가장 많이 사용되는 대상 모듈에는 다음과 같은 것이 있습니다:

nat 테이블을 사용하는 IP 매스커레이딩이나 또는 mangle 테이블을 사용하는 패킷 변경에 유용한 여러 기능을 포함하는 대상 확장기능은 iptables 메뉴얼 페이지에서 확인하실 수 있습니다.

기본 목록에서 iptables -L [<chain-name>] 명령은 기본 필터 테이블의 현재 chain에 대한 기본적인 개요를 제공합니다. 추가 옵션에서는 보다 많은 정보를 제공합니다:

다음의 예는 여러 옵션의 사용을 보여줍니다. -x 옵션을 포함하여 나타나는 바이트 표시에 있어서 다른점에 주의하시기 바랍니다.

 [root@myserver ~]# iptables -L OUTPUT -v -n -x Chain OUTPUT (policy ACCEPT 64005 packets, 6445791 bytes) pkts bytes target prot opt in out source destination 1593 133812 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#iptables -L OUTPUT -v -n Chain OUTPUT (policy ACCEPT 64783 packets, 6492K bytes) pkts bytes target prot opt in out source destination 1819 153K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]# 

iptables initscripts의 동작은 /etc/sysconfig/iptables-config 설정 파일에 의해 제어됩니다. 다음은 이러한 파일에 들어 있는 지시문 목록입니다: