tail head cat sleep
QR code linking to this page

Man page  — FIREWALL

명칭

firewall – FreeBSD 로 동작하는 간단한 파이어 월(fire wall)

내용

파이어 월(fire wall)의 기초

파이어 월(fire wall)는 일반적으로, 외부로부터 행해지는 네트워크 내부에의 부정한 액세스 (을)를 막기 위해서(때문에) 사용됩니다. 또, LAN 내에서만 서비스되어야 할 NFS 나 SMBFS 와 같은 서비스에 대해서, 내부의 IP 주소를 위장해 외부로부터 행 원 공격을 막기 위해서(때문에)도 이용됩니다.

또, FreeBSD 의 파이어 월(fire wall) 기구는, dummynet(4) (을)를 이용한 대역 제한을 실시할 수도 있습니다. 이 기능은 특히 중요한 목적을 위해서(때문에) 대역폭을 프로텍션하고 싶은 경우 등에 유효하겠지요. 예를 들어, 오피스의 T1 (1.5Mbps)(을)를 이용해 비디오 회의를 실시하는 경우에, 다른 통신을 1Mbps 까지 눌러, 비디오 회의용의 connection에 최악이어도 0.5Mbps 를 확보할 수가 있습니다. 또 같이 공용 기기로 유명한 웹 사이트나 FTP 사이트를 운용하고 있는 경우에는, 프로바이더로부터의 고액의 대역 과금을 피하기 위해서(때문에) 사용할 수도 있습니다.

그리고, FreeBSD 의 파이어 월(fire wall) 기구는 패킷이 올바른 도달 먼저 가도록(듯이) 패킷을 divert 하거나 다음의 호프의 주소를 변경하거나 할 수도 있습니다. 패킷의 divert 는 주로, 프라이빗 IP address 공간으로부터 외부에의 브라우즈 등 의 액세스를 가능하게 하는 NAT (네트워크 어드레스 변환)를 실현하기 위해서(때문에) 이용됩니다.

파이어 월(fire wall)를 구축하는 것은 간단한 것 같습니다만, 많은 사람이 실수를 범해 (이)라고 있습니다. 가장 많은 실수는, 포괄적인 파이어 월(fire wall)가 아니고, 배타적인 파이어 월(fire wall)를 만들어 버리는 것입니다. 배타적인 파이어 월(fire wall)는, 룰 세트에 적합하지 않았다 모든 패킷을 통과시키는 것으로, 포괄적인 파이어 월(fire wall)는 룰 세트에 매치 한 패킷만을 통과시킵니다. 포괄적인 파이어 월(fire wall) 쪽이, 배타적인 물건보다 훨씬 안전합니다만, 올바르게 움직이는 것을 만드는 것이 어려워집니다. 다음에 많은 실수는, 통과시키고 싶지 않은 것 모든 것을 폐기해 버리는 것입니다. TCP/IP 가 정상적으로 동작하기 위해서는, 예를 들어 MTU 디스카바리의 실장과 같이, 몇개의 ICMP 에러를 필요로 합니다. 같이 많은 demon는, connection를 요구하는 유저를 인증하기 위해서, auth 서비스에 역방향의 connection를 칩니다. auth 는 위험합니다만, 올바른 대응 (은)는 다만 패킷을 폐기하므로 없고, TCP reset 를 돌려주도록(듯이) 하는 것입니다. 이하로 가리키는, 파이어 월(fire wall)의 샘플에서는 이러한 사항을 채우도록(듯이) 되어 있습니다.

IPFW 를 사용하기 위한 커널의 설정

IP 파이어 월(fire wall)의 기능을 사용하기 위해서는, custom car 네루를 작성할 필요는 없습니다. /etc/rc.conf (후술)(으)로 파이어 월(fire wall)를 유효하게 하면, ipfw 커널 모듈이 자동적으로 로드 됩니다. 당신이 편집 하고 싶다면, IPFIREWALL 옵션을 설정하는 것으로, IPFW 를 직접 FreeBSD 커널에 짜넣을 수도 있습니다. 이 파이어 월(fire wall)는, 아무것도 설정하지 않으면 모든 패킷을 통과시키지 않게 되어 있습니다. /etc/rc.conf 그리고, 재기동시에 적절한 룰 세트를 읽어들이게 되지 않으면 콘솔에 손댈 수가 없는 경우, 머신에 액세스조차 할 수 없게 됩니다. 또, 새로운 릴리스의 커널에 갱신할 때에, 바이너리 (역주: 명령나 프로그램 라이브러리)를 갱신하기 전에 리부트를 실행해 버리는 일이 자주 있습니다. 이 결과 ipfw(8) (와)과 커널이 비호환이 되어 버려, 부트 순차 순서로 ipfw(8) 하지만 동작하지 않는 것에보다 , 머신에 액세스 할 수 없게 되어 버립니다. 이 때문에, IPFIREWALL_DEFAULT_TO_ACCEPT 그렇다고 하는 커널 옵션이 준비되어 있어 이것에 의해 파이어 월(fire wall)의 초기 상태를 모든 패킷을 통과시키는 설정으로 할 수가 있습니다. 그러나, 이 옵션을 설정하는 것은, 시스템 부트중의 단기간, 파이어 월(fire wall)가 전패킷을 통할지도 모르는 것에 주의해 주세요. 그런데도 본옵션의 사용은, FreeBSD 파이어 월(fire wall)에 충분히 익숙해질 때까지의 기간에는 유용합니다. 어떻게 동작할까 모두 알면(자), 이것을 삭제해, 빠져 나갈 구멍을 막아 주세요. 제 3 의 옵션으로서 IPDIVERT (이)가 있습니다. 이것은, 파이어 월(fire wall)가 패킷을 유저 프로그램에 divert 할 수가 있도록(듯이) 하는 것으로, natd(8) 에 의해, 프라이빗 네트워크로부터 외부에 액세스 할 수 있도록(듯이) 할 때 에 필요합니다. 트래픽 타입에 의한 대역 제한에는, ipfw pipe 룰을 유효하게 하기 위해서, DUMMYNET 옵션이 필요합니다.

IPFW 에 의한 파이어 월(fire wall)의 예

여기에 나타내는 것은, 3 개의 인터페이스 카드를 가지는 머신으로 동작하고 있다 ipfw 베이스의 파이어 월(fire wall)의 예입니다. fxp0 가 「외측의」LAN 에 접속되고 있습니다. 이 LAN 상의 머신은, 10. 그리고 시작되는 내부 IP 주소와 인터넷에 루팅 되는 IP 주소를 가져, dual-homed가 되고 있습니다. 예를 들어, 192.100. 5. x 가 인터넷에 루팅 되는 IP 블록을 가리켜, 10. x.x.x 가 내부 네트워크를 가리킵니다. 예로서 적절하지 않을지도 모릅니다만, 10.0. 1. x 가 fxp0 의 접속되고 있는 LAN 의 주소, 10.0. 2. x 가 fxp1 의 접속되고 있는 LAN 의 주소, 그리고 10.0. 3. x 가 fxp2 의 것이다고 합니다.

이 예에서는, 3 개의 LAN 모든 것을 인터넷으로부터 격리해, 또 각각을 도 격리하고 싶은 것으로 합니다. 동시에, 모든 내부 주소로부터, 이 머신으로 달리고 있는 NAT 게이트웨이를 경유해 인터넷에 액세스가 가능하도록 합니다. NAT 게이트웨이를 동작시키기 위해서(때문에)는, fxp0 에 내부 주소의 10. 외에, 인터넷으로부터 보이는 주소를 갖게한다 필요가 있습니다. 이 주소 (여기에서는 가리키고 있지 않습니다)가, 이 머신의 공식적인 주소이며, 또 하나의 외부로부터 보이는 주소 (이 예에서는 192.100. 5.5 입니다)가 NAT 게이트웨이로서의 주소가 됩니다. 이 예는, 외부로부터 보이는 LAN 의 머신에도 내부 주소 10.0. 0. x 를 할당하는 것 에 의해, 조금 복잡하게 되어 있습니다. 그러나 이 방법에 따라, 내부 서비스는 내부 주소에게만 바인드 해, 인터넷으로부터 지킬 수 있습니다. 밖으로부터 보이는 IP 주소에 바인드 한다 서비스는, 인터넷에 대해서 공개하려고 하는 것인 만큼 합니다.

이 예에서는, 네트워크 10.0. 0. x 는 파이어 월(fire wall)에 의해 보호되고 있고 선. 이 네트워크를 외부로부터의 주소 위장으로부터 지키기 위해서(때문에), 인터넷 라우터에 의한 보호를 확인해 주세요. 또 예에서는, 외부로부터 보이는 호스트가 내부 IP 주소를 통해서 서비스를 조작하는 경우, 내부의 네트워크에 매우 자유롭게 액세스 가능으로 하고 있습니다. 이 방법에는 얼마인가의 보안상의 위험이 수반하고 있어 외부로부터 보이는 호스트에 문제가 있는 경우에는 무엇이 일어날까 모릅니다. 이 위험을 회피하기 위해서는, 룰 01010 으로 01011 을 삭제해, LAN0 경유로 들어 오는 것 모든 것을 firewall 를 경유하도록(듯이) 해야 합니다.

또, 이 예에서는 내부 address 공간을 사용하는 것이 파이어 월(fire wall)에 의한 보호 기구 의 중요한 점인 것에 주목해 주세요. 적절한 주소 위장 대책을 실시하는 와 (와)과에 의해, 외부로부터, 내부 (LAN1 및 LAN2)의 호스트에 직접 액세스 하는 와 (와)과는 불가능이 됩니다.

# /etc/rc.conf
#
firewall_enable="YES"
firewall_type="/etc/ipfw.conf"

# 파이어 월(fire wall)를 통과하는 일시적인 포트 할당의 범위를 설정 # # 주의 : 파이어 월(fire wall)를 통해서 행해지는 서비스의 부하가 높은 경우에는, # 보다 넓은 포트 할당의 범위를 필요로 하게 됩니다. 그러한 때는 # 4000-10000 (이)나 4000-30000 가 보다 좋은 선택이지요. ip_portrange_first=4000 ip_portrange_last=5000 ...

# /etc/ipfw.conf
#
# FIREWALL: 파이어 월(fire wall)겸 NAT 게이트웨이
# LAN0      10.0. 0. X 와 192.100. 5. X (dual-homed)
# LAN1      10.0. 1. X
# LAN2      10.0. 2. X
# sw:       이더넷(ethernet) 스윗치 (관리 대상외)
#
# 192.100. 5. x 는, 인터넷으로부터 보이는 IP 주소 (인터넷으로부터
# 루팅 된다)를 의미합니다. 10. x.x.x 는, 내부 IP 주소
# (밖으로부터는 안보인다)(을)를 나타냅니다.
#
#   [LAN1]
#      ^
#      |
#   FIREWALL -->[LAN2]
#      |
#   [LAN0]
#      |
#      +--> 외측의 호스트 A
#      +--> 외측의 호스트 B
#      +--> 외측의 호스트 C
#      |
#   인터넷 라우터 (2 번째의 파이어 월(fire wall))
#      |
#    [인터넷]
#
# 주의!  여기에는 쓰여져 있지 않습니다만, 인터넷 라우터는 발신기지 주소가
# 10.  인 패킷을 허가하지 않게 설정될 필요가 있습니다.
# 이것은, dual-homed의 10.0. 0. x 블록을 보호하기 (위해)때문입니다.
# 그렇지 않으면, 외부로부터 보이는 호스트는, 이 예에서는 지켜지고 있지 않습니다.
# 이러한 호스트는, 외부에 보이는 서비스만을 외부로부터 보이는 주소에
# 바인드 해야 합니다. 내부 서비스는, 안전하게 내부 주소에 바인드 가능합니다.
#
# NAT 게이트웨이는, 내부의 IP 주소로부터 외부의 IP 주소에
# 향하여 보내지는 패킷을, 포트 8668 으로 listen 하고 있는 natd 에 전송
# 것에 의해 동작합니다. 이 동작은 룰 00300 에 의해 지정되어 있습니다.
# 외계로부터 natd 에 되돌아 오는 패킷도 같이 룰 00301 에 의해 natd 에
# 보내집니다. 이 예로 흥미로운 것은, 밖에 보이고 있는 호스트에의 내부로부터의
# 리퀘스트는, natd (룰 00290)를 통할 필요가 없다고 하는 것입니다.
# 이것은, 외부에 보이고 있는 호스트도 내부의 10.  네트워크를 알 수 있으므로
# 가능하고, natd 의 부하를 경감할 수가 있습니다. 내부의 트래픽도
# natd 를 통할 필요가 없습니다. 이러한 호스트는, 내부의 10.  네트워크의
# 루팅를 알기 (위해)때문입니다.
# /etc/rc.local 로부터는, natd 는 이하와 같이 기동됩니다.
# natd 의 커널 편입형의 버젼인 ipnat 에 대해서도 참조해 간다
# (이)다 차이.
#
#       natd -s -u -a 208.161. 114.67
#
#
add 00290 skipto 1000 ip from 10.0. 0.0/8 to 192.100. 5.0/24
add 00300 divert 8668 ip from 10.0. 0.0/8 to not 10.0. 0.0/8
add 00301 divert 8668 ip from not 10.0. 0.0/8 to 192.100. 5.5

# 높은 대역의 액세스가 룰 세트 전체를 통과해 나가는 것을 막기 위한 쇼트 # 컷 룰을 설정합니다. 벌써 확립되어 있는 TCP connection는 그대로 # 통해, 또 밖에 나오는 패킷도 이와 같이 합니다. 파이어 월(fire wall)를 통한다 # 의는 입력 패킷인 만큼 합니다. # # 확립된 TCP connection를 그대로 통해 버리는 것은 작은 보안 # 홀이 됩니다만, 파이어 월(fire wall)의 과잉인 부하를 피하는 의미로 필요 # (이)가 될 수도 있습니다. 만약 걱정이면 이 룰을, 주소 위장 체크 # 의 뒤로 이동할 수도 있습니다. # add 01000 allow tcp from any to any established add 01001 allow all from any to any out via fxp0 add 01001 allow all from any to any out via fxp1 add 01001 allow all from any to any out via fxp2

# 주소 위장 방지의 룰입니다. 이것은, 내부 네트워크의 패킷을 # 어느 정도 신뢰할까에 의해 바뀌어 옵니다. fxp1 를 경유하는 패킷은 반드시, # 10.0. 1. x 로부터의 것이 아니면 안됩니다. fxp2 를 경유하는 것 # (은)는 10.0. 2. x 로부터입니다. fxp0 를 경유하는 것이 LAN1 나 LAN2 블록으로부터 # 의 것임도 있을 수 없습니다. 여기에서는 10.0. 0. x 를 보호할 수 성과 # 없기 때문에, 라우터를 적절히 설정할 필요가 있습니다. # add 01500 deny all from not 10.0. 1.0/24 in via fxp1 add 01500 deny all from not 10.0. 2.0/24 in via fxp2 add 01501 deny all from 10.0. 1.0/24 in via fxp0 add 01501 deny all from 10.0. 2.0/24 in via fxp0

# 이 예의 룰 세트에서는, 내부 호스트간에는 어떤 제약도 마련하고 있지 않습니다. # 외부로부터 보이는 LAN 상의 호스트여도, 내부 IP 주소를 사용한다 # 한계에 대해 그렇습니다. 이것은 보안 홀이 될 가능성이 있습니다 # (외부로부터 보이는 호스트에 무엇인가가 있으면 어떻게 될까요 ? ). 이것들 # 3 개의 LAN 의 사이의 통신을 완전하게 제한하고 싶은 것이면, 이하의 두 룰 # (을)를 삭제해 주세요. # # LAN1 와 LAN2 를 고립시켜, 그러나 외부로부터 보이는 호스트간의 자유로운 액세스를 # 허락하고 싶다면, 룰 01010 만을 삭제해, 01011 은 남겨 주세요. # # (comment out 되어 있습니다만, 보다 제약의 적은 파이어 월(fire wall)로 한다 # 경우는 이것들을 유효하게 해 주세요) #add 01010 allow all from 10.0. 0.0/8 to 10.0. 0.0/8 #add 01011 allow all from 192.100. 5.0/24 to 192.100. 5.0/24 #

# 특정의 LAN 로부터는 특정의 서비스에의 액세스를 허가하는 경우 # # 보다 제약의 강한 파이어 월(fire wall)를 사용하는 경우에는, 특정의 LAN 로부터 파이어 # 월상에서 동작하고 있는 특정의 서비스에 액세스 할 수 있도록(듯이) 하는 것에 # 됩니다. 이 예에서는, LAN1 가 파이어 월(fire wall)상에서 움직이고 있는 파일 공유 # (을)를 필요로 하면(자) 가정합니다. 만약, 룰 01010 이 유효하게 되어 있는 것 같은, # 제약의 느슨한 파이어 월(fire wall)이면 이러한 룰은 불필요합니다. # add 01012 allow tcp from 10.0. 1.0/8 to 10.0. 1.1 139 add 01012 allow udp from 10.0. 1.0/8 to 10.0. 1.1 137,138

# 내부와 외부의 LAN 의 횡단을 허가하는 일반적인 서비스 # # DNS 참조, ntalk, ntp 라고 하는 특정의 UDP 서비스는 통과시킵니다. # 내부 서비스는 주소 위장 불가의 내부 주소 (10. 넷)을 가지는 것으로 # 보호되고 있으므로, 이러한 룰은 외부로부터 보이는 IP 주소에 바인드 # 되고 있는 서비스 에 대해서만 의미를 가집니다. 또, UDP fragment는 # 허가할 필요가 있습니다. 그렇게 하지 않으면 fragment 되는 것 같은 큰 # UDP 패킷은 파이어 월(fire wall)를 통과할 수 없습니다. # # DNS 참조에 대한 응답 등, 큰 포트 번호를 이용한 일시적인 서비스를 # 실시할 필요가 있을지도 모릅니다. 이 예에서는 그러한 포트 번호를 # 4000-65535 (으)로 하고 있습니다. 외부로부터 보이는 전머신이 일시 포트를 이 # 외부로부터 보이는 포트에 바인드 하도록(듯이), /etc/rc.conf 의 변수로 설정 # 하고 있습니다 (위의, rc.conf 의 예를 참조해 주세요). # add 02000 allow udp from any to any 4000-65535, domain, ntalk, ntp add 02500 allow udp from any to any frag

# 같은 서비스를 TCP 에 대해서도 허가합니다. 여기에서도, 외부로부터 보인다 # 주소에 바인드 하는 서비스에게만 적용됩니다. 또, 이 예에서는 # 'auth'를 통과시키고 있습니다만, 실제로는 외부로부터 보이는 포트에서는 identd # (을)를 동작시키고 있지 않습니다. 이것에 의해, auth 요구를 받아들인 머신은 # TCP RESET 를 발행합니다. 패킷을 버리게 되면(자), ident 참조를 실시해 온다 # 서비스에의 접속의 지연의 원인이 됩니다. # # TCP fragment를 허가하고 있지 않는 것에 주의해 주세요. UDP 이외에서는, # 일반적으로 fragment를 허락하지 않습니다. TCP 의, MTU 디스카바리프로트콜 # 하지만 올바르게 동작해, TCP fragment가 존재하지 않는 것이라고 기대하고 있습니다. # add 03000 allow tcp from any to any http, https add 03000 allow tcp from any to any 4000-65535, ssh, smtp, domain, ntalk add 03000 allow tcp from any to any auth, pop3, ftp, ftp-data

# 몇개의 타입의 ICMP 를 통과시키는 것은 중요합니다. # 일반형인 ICMP 타입을 여기에 열거합니다. # ICMP 타입 3 을 통과시키는 것이 중요한 것으로 주의해 주세요. # #       0       에코 리플라이 #       3       도달 불능 #       4       시점 억제 (통상은 허가되지 않습니다) #       5       리디렉트 (통상은 허가되지 않습니다. 위험합니다 ! ) #       8       에코 #       11      시간 초과 #       12      파라미터 문제 #       13      타임 스탬프 #       14      타임 스탬프 리플라이 # # 상황에 따라서는 타입 5 의 ICMP 리디렉트 패킷을 허가하지 않으면 # 들 없는 경우가 있습니다만, 그러한 경우에는 인터넷 라우터로 그것이 # 금지되고 있는 것을 확인해 주세요. # add 04000 allow icmp from any to any icmptypes 0,3,8,11,12,13,14

# 여기까지 다녀 남은 fragment의 로그를 취합니다. 도움이 될지도 모르고 # 선이, 방해인 만일 수 있는일지도 모릅니다. 마지막 deny 룰은, 커널의 설정 # 하지만 어떻게에서 만나도, 파이어 월(fire wall)가 포괄적인 것임을 프로텍션한다 # 물건입니다. # add 05000 deny log ip from any to any frag add 06000 deny all from any to any

내부전용, 외부용 서비스의 포트 바인딩

multi-homed인 호스트로, 서비스를 어느 쪽의 주소에 바인드 하는가 한다 일에 대해 다루었습니다만, 설명은 하고 있지 않습니다. 복수의 IP 주소를 가지는 호 파업에서는, 각각의 서비스를 모든 IP 주소에 바인드 하는 것은 구, 특정의 IP 주소나 인터페이스에 바인드 하는 것이 가능합니다. 물으면 이 예의 파이어 월(fire wall) 머신에는, 인터페이스가 3 개 있어, 그 1 개(살)에는 2 개의 외부로부터 보이는 IP 주소가 있으므로, 이 머신에는 5 개의 IP 주소 (10.0. 0.1, 10.0. 1.1, 10.0. 2.1, 192.100. 5.5, 192.100. 5.1)이 있게 됩니다. Windows 의 LAN 세그먼트(segment) (LAN1 로 합니다) 에 대해서 파일 공유 서비스를 제공한다면, samba 의 'bind interfaces' 그렇다고 하는 설정 항목으로, LAN1 의 IP 주소에만 samba 를 바인드 할 수 있습니다. 이렇게 하는 것으로, 다른 LAN 세그먼트(segment)에서는 이 파일 공유 서비스를 이용 할 수 없게 됩니다. 또, LAN2 에 UNIX 엔지니어링 워크스테이션 (이)가 있으면, nfsd 를 10.0. 2.1 에 바인드 하도록(듯이) 설정하는 것으로 NFS 에서도 같이 가 할 수 있습니다. 어느 서비스를 어떻게 바인드 할까는 대부분의 경우 (으)로 지정할 수 있고, 또 그것을 지정할 수 없는 경우에는 jail(8) (을)를 사용하는 것에 의해, 간접적으로 그것을 실시할 수도 있습니다.

관련 항목

ipnat(1) [영어], dummynet(4), ipnat(5), rc.conf(5), smb.conf(5)[ /usr/ports/net/samba], samba(7)[ /usr/ports/net/samba], config(8), ipfw(8), jail(8), natd(8), nfsd(8)

관련 문서

ipf(5), ipf(8), ipfstat(8)

역사

firewall 메뉴얼 페이지는 최초, Matthew Dillon 에 의해 쓰여져 2001 년 5 월에 FreeBSD 4.3 그리고 처음 등장했습니다.

FIREWALL (7) May 26, 2001

tail head cat sleep
QR code linking to this page


Ben Bullock이 유닉스 매뉴얼 페이지에서 서비스에 대한 의견을 주시기 바랍니다. Privacy policy.

Using Unix is the computing equivalent of listening only to music by David Cassidy
— Rob Pike