<pre style='font-size:10pt; font-family:굴림체,gulimche,gulim'>
실제 IP를 이용한 Bridge FireWall
================================
작성자 : 유천 송덕균
작성일 : 2001년 4월 21일 5시
수정일 : 2002년 1월 1일 -.-;
라이센스 : GPL
kltp.org와 debianusers.org의 문서가 그림이 모두 제대로 나오지 않고,
약간의 수정사항(커널 2.4.x)이 있어 다시 올려 놓습니다.
0. 원대한 야망 =.=;
-------------------
기존의 네트웍을 그대로 이용하면서 LinuxBox로 방화벽 역할을 하게하며, 삼바,
FTP등의 서비스를 제공 하고자 함.
1. 현재 네트웍 구조 & 목적
--------------------------
|
|
+-----....
|
|
|
+---+ | +---+ ------------ PC
| |---+----- | | ------------ PC ...
| | | | | ------------ PC ...
+---+ | +---+ ------------ PC
Router | Hub
|
| 회사내의 네트웍
|
+-----....
|
|
+-----.....
|
|
( 상황 )
======
o. 한 건물에 여러개의 회사가 입주해 있다.
o. 건물 내에 방화벽은 없으며, 각 회사마다 방화벽을 따로 구축을 해야한다.
o. 그러나, 라우터는 건드릴 수 없다. (전문 관리자가 없다.)
o. 각 PC 당 Real 고정 IP가 1개씩 부여되어 있다.
o. LAN선들이 외부로 돌출된 것이 아니라 벽면에 숨겨저 공사되어 있다.
LAN선 공사를 따로 할 수 없다. (물론 있지만, 미관상 눈총 받기 싫다. =.=; )
o. 이 건물의 모든 컴은 MS의 OS를 쓴다. 윈도 2000 서버가 두대 있다.
유닉스/리눅스 서버는 없다. -.-;
-. 그렇다 이 회사는 다른 회사에 꼽사리 껴 있다. 그래서, 이렇게 삽질하는
것 아닌가? 하하하.... 밤샘의 삽질 속에 늘어가는 내 실력... ㅠ.ㅠ;
o. 울 회사도 MS 윈도 쓴다. 물론 공유 기능을 십분 활용하고 있다. -.-;
( 목적 )
======
o. 다른 회사에서 우리 회사의 공유 네트웍을 보게 하고 싶지 않다.
o. FireWall에서 기획실 쪽 컴퓨터를 완존히 장악할 것이다. !! 히힛~
o. 삽질을 해보고 싶었다.... =.=;
2. Linux Box 구성 & 참고 자료
1) Linux Box : 셀러론 266, 128M RAM, 2개의 NIC (3com 905B, 리얼텍 8139B)
데비안 2.2 포테이토, 커널 2.2.19
2) 참고 자료 & 사이트
o. 정정화님의 Bridge Firewall
--> http://kldp.org/KoreanDoc/Bridge_Firewall-KLDP o. 정정화님의 실제 IP를 사용하는 방화벽 및
포워딩 머쉰 구축 --> http://kldp.org/KoreanDoc/Firewall-KLDP o. Linux BRIDGE -STP -HOWTO
-> http://www.bnhof.de/~uwe/bridge-stp-howto/BRIDGE-STP-HOWTO o. Linux BRIDGE Homepage
--> http://www.math.leidenuniv.nl/~buytenh/bridge 또는,
--> http://bridge.sourceforge.net/ 3. 준비물
---------
o. 네트웍 기초 / 리눅스 기초 문서 -.-;
o. 위에 언급한 참고 자료를 샅샅히 읽는다.
(정정화님의 문서는 오래 되었다. 지금은 환경이 바뀌었으니, 홈페이지와
HOWTO를 확실하게 읽어 두는 것이 좋다.)
o. 리눅스 커널 2.2.20
(현재 이 글을 쓰는 시점에서, 2.4.x는 아직 bridge-firewall을 지원하지 못함.
물론 2.4.x에 bridge 기능이 있지만, firewall 기능은 없다. netfilter/iptables
용 패치가 있지만 아직 불안하다. 계속 개발 중이니 조금 기다려 보고,
제작자에게 감사의 편지라도 보내자.)
덧글 : 2002년 1월 현재 커널 2.4.x 버전도 안정 버전이 릴리즈 되었다.
2.4.x 버전에 관련한 설명도 추가한다.
o. 브릿지 패치 (브릿지 홈페이지에 가면 있다. 아래 내용은 커널 2.2.x에 관한 것이다. )
bridge-1.0.2-against-2.2.20.diff
bridge-ipchains-against-1.0.2-against-2.2.20.diff
o. bridge-utils 0.9.3
o. 날 밤샐 수 있는 인내력 & 녹차
(초보자는 정말 날 새야 할 것이다. =.=; 초보자의 비애~ )
4. Start
--------
1) 바뀐 구조 (리눅스 박스가 추가되었다.)
|
|
+-----....
|
|
|
+---+ | +---+ +---+ ------------ PC
| |---+---| |---| | ------------ PC ...
| | | | | | | ------------ PC ...
+---+ | +---+ +---+ ------------ PC
Router | Linux Hub
|
| 우리 회사내의 네트웍
|
+-----....
|
|
+-----.....
|
|
2) 커널 패치
/usr/src/linux# patch -p1 < bridge-1.0.2-against-2.2.20.diff
/usr/src/linux# patch -p1 < bridge-ipchains-against-1.0.2-against-2.2.20.diff
3) 커널 컴파일
/usr/src/linux# make menuconfig
networking options -->
[*] 802.1d Ethernet Bridging
그리고, firewall 기능을 당연히 넣어주고, 컴파일 ...
4) bridge-utils 0.9.3 설치 (현재 최신 버전)
데비안 apt 사이트에서 bridge-utils를 받아오자.
# apt-get install -d bridge-utils
아마도 0.9.3이 받아질 것이다. 화일이 저장된 디렉터리는 /var/cache/apt/archives 이다.
또는 직접 가서 받아올수 있다. (포테이토는 직접가서 받아와야 할 것이다.)
http://http.us.debian.org/debian/pool/main/b/bridge-utils/ 이 패키지는 데비안 포테이토의 의
존성에 걸린다. (libc6 2.2.3-1 이상, ifupdown 0.6.0 이상이 필요하다. 현재 이 패키지들은 데
비안 포테이토 버전에 없다. 위 패키지는 우디 이상에서 설치가능하다.)
우디 이상이면 그냥 설치하면 되고, 포테이토이면 brctl화일만 추출해서 복사하자.
# cd /
# dpkg --fsys-tarfile /var/cache/apt/archives/bridge-utils_0.9.3-1_i386.deb | tar xvf - */brctl
그러면, /usr/sbin에 brctl 화일이 추출되었을 것이다. ( 'cd /'를 해주는 이유는 tar 때문이
다. 이상하게 tar에서 -C / 옵션을 주었어도 그냥 현재 디렉터리에 풀린다. 따라서 / 로
한것이다. -.-; ) 참고로, bridge-utils_0.9.3-1_i386.deb 화일을 살펴보면,
# dpkg -c bridge-utils_0.9.3-1_i386.deb
데비안 방식의 설정 방식이 보일 것이다. 필자는 이 패키지를 사용해보지 않았다. 그
냥 brctl 화일만 복사해서 사용해 본것 뿐이다. (커널 2.4.x에서는 사용해 보지 않았다.)
각자 입맛에 맞게 하시길.. =.=; 5. 설정
-------
Linux Box
+--------------+
외부 | | 내부
---------| |-----------
eth0 | | eth1
(905B) | | (8139B)
+--------------+
참고로, 랜카드는 3COM이나 인텔 것을 쓰는 것이 정신 건강에 이롭다. 브릿지는
계속해서 실시간으로 네트웍을 검사하기 때문에 랜카드에 엄청난 부하가 걸린다.
싸구려 리얼텍 랜카드는 에러메시지를 뿌려될 확률이 100%...!! 잘되다가 중간에
다운이 된다면, 리얼텍 랜카드를 의심해 보는 것이 좋을 것이다. 또한 리얼텍
랜카드는 부하가 많이 걸릴때 속도가 떨어지고, packet loss가 일어난다는 사실을
꼭 명심할 것. 웬만하면 중대 규모 네트웍 구축할때는 리얼텍 카드 쓰지 마시라!!!
1) NIC 설정
/etc/network/interfaces를 손 본다.
----------------
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# The loopback interface
iface lo inet loopback
-----------------
NIC가 하나도 설정되지 않았다. 일부러 이렇게 했다. 브릿지와 promisc 모드를
수동으로 설치하기 위함이다.
2) 브릿지 실행 스크립트
/etc/rc.boot/에 화일을 만들고, chmod +x 를 수행한다.
/etc/rc.boot# emacs start-bridge-firewall
/etc/rc.boot# chmod +x start-bridge-firewall
그리고, start-bridge-firewall 화일을 편집한다.
-------------------
#!/bin/bash
echo "Setting bridging ...."
/usr/sbin/brctl addbr dev-br
#
# 'dev-br'은 브릿지 이름이다.
#
/usr/sbin/brctl stp dev-br off
#
# 굳이 외부(게이트웨이가 아닌 외부 업체)에 우리의 네트웍을 실시간으로
# 연결할 필요가 없어 stp모드는 꺼 두었다. 일반적으로는 켜두는 것이 좋다.
# 브릿지는 네트웍에 물린 모든 컴퓨터의 NIC(LAN Card) 의 MAC Address를
# 조사하여 DB를 구성한 후에 작동된다. 따라서 에이징 시간이 조금 걸린다.
# 브릿지 시작후 ping이 나가려면 네트웍 규모에 따라 몇초정도 기다려야 한다.
# 착오 없기를... ^^
#
/usr/sbin/brctl addif dev-br eth0
/usr/sbin/brctl addif dev-br eth1
#
# eth0 eth1를 dev-br에 묶는다.
#
/sbin/ifconfig eth0 0.0.0.0
/sbin/ifconfig eth1 0.0.0.0
#
# IP 0.0.0.0을 부여한다는 것은 promisc 모드로 한다는 것이다.
#
/sbin/ifconfig dev-br 211.171.xxx.162 up
#
# 브릿지에 고정IP를 부여해 주었다. 그래야 리눅스 박스에서 FTP등의
# 서비스를 제공할 수 있다. 그리고 반드시 up를 해 주어야 한다.
# 리눅스 박스가 외부에 표출되어질 필요가 없으면 할 필요 없다.
# 요것을 이해하지 못하는 분이 있는데, 간단히 설명하면, 브릿지 화이어월
# 리눅스 박스 자체가 단순히 브릿지 기능만을 위한 것이라면 위 설정을 해줄
# 필요가 없다. 아무런 서비스(FTP,WEB,SSH 등)을 제공하지 않는데 당연히
# IP를 부여할 필요가 없다. -.-; 아무런 서비스를 하지 않을 것이면 위 명령을
# 실행하지 마시라~. 괜히 크래킹당한다.
# FTP, WEB 서버들 방화벽 뒤에 따로 서버를 둬서 서비스하려고 해도
# 위 설정을 해 줄 필요가 없다. !!!
# IP가 없는 화이어월.... 강력하다고 생각되지 않는가? -.-a
#
/sbin/route add default gw 211.171.xxx.1
#
# 바로 위의, 브릿지에 고정 IP를 부여해 주었다면,
# 이 줄을 반드시 추가해 주어야 한다. 가장 기본적인 것을 빼먹어서
# 리눅스 박스에서 외부로 데이터가 나가지 않았다. 이것 때문에
# 하룻밤을 버렸다... ㅠ.ㅠ 위 주소는 게이트웨이 주소이다.
# .. 당연히 리눅 박스가 아무런 서비스를 제공하지 않으면 해줄 필요가 없다.
#
echo "Setting BRIDGE - FireWall ... "
#
# * 체인은 모두 6개가 된다.
# 기본 체인 : input, forward, output
# 기본 브릿지 체인 : dev-br
# 브릿지 관련 체인 : br_thru .... 브릿지를 완전히 관통하는 패킷들 제어
# br_input ... 브릿지를 통해 '리눅스 박스 자체로 들어오는' 패킷 제어
# br_out ..... '리눅스 박스 자체'에서 브릿지를 통해 나가는 패킷 제어
#
/sbin/ipchains -N dev-br
#
# 새로 만든 브릿지의 이름(dev-br)과 브릿지 방화벽을 위한 체인의 이름은
# 같아야 한다.!!!!
#
/sbin/ipchains -N br_thru
/sbin/ipchains -A dev-br -j br_thru
#
# br_thru라는 체인을 다시 만들었다. dev-br이라는 이름은 브릿지 장치명을
# 가르키는 것이라, 보다 명확하게 br_thru로 명명한다. 사용해보면 알겠지만,
# 브릿지 체인(dev-br = br_thru)는 리눅스 박스를 완전히 통과하는 것만을
# 의미한다. 이를테면 외부에서 리눅스 박스 자체로 들어오는 것은 건드리지
# 못한다. 따라서 아래의 br_input를 만든다.
#
/sbin/ipchains -N br_input
/sbin/ipchains -A input -i dev-br -d (자신의 IP) -j br_input
#
# 브릿지(데이터 링크 계층)엑서 리눅스 박스 자체로 들어오는 패킷은 br_input
# 체인으로 점프한다. 물론 리눅스 박스의 서비스들이 브릿지 계층위에 있기 때문에
# input 체인을 그냥 이용해도 되지만, 보다 명확하게 나누어 놓았다.
# NIC가 여러개 있어 라우터 역할을 하는 컴은 당연히 지정해 주어야 명확하다.
#
/sbin/ipchains -N br_out
/sbin/ipchains -A output -i dev-br -s (자신의 IP) -j br_out
#
# 리눅스 박스에서 브릿지를 통해 나가는 패킷들을 제어한다.
#
생략 .....
# 이제 모든 브릿지 데이터는 br_thru와 br_input, br_out로 통한다.
# 알아서 방화벽을 삶아 주시라~ ^_^
# 자세한 설정은 정상화님의 방화벽 구성하기(Sub-net screen 구조)를 보시라.
# --> http://kltp.kldp.org/stories.php?story=01/08/21/3141987 #
-------------------
3) Test
알아서 테스트 해 보시라. 브릿지는 OSI Layer 2 (Datalink)에서 동작하기 때문에
투명하다. ^_^ traceroute로 해도 안보인다.
4) 내부의 컴퓨터들의 게이트 웨이 셋팅을 고칠 필요 없다. 고치지 마라~ -.-;
--> 아마도 여기에서도 헷갈리는 분들이 있을 것으로 사료된다. 이 문서는 네트웍의
모든 컴이 같은 서브넷으로 구성되어 있을 경우로 설명한 것이다.
예를 들어 건물내의 네트웍이 211.171.xxx.0을 서브넷으로 가지고 있을 경우는
브릿지 내부의 IP를 가상 IP(192.168.1.0 등)으로 바꾸어서는 안된다.
이 문서는 마스커레이딩 문서가 아니다. 말그대로 기존의 네트웍 셋팅을 전혀
건드리지 않는다.
6. 패킷들의 이동 경로
---------------------
*. 모든 패킷이 브릿지를 통과할 경우
*. 완전 노가다로 알아낸 리눅스 박스의 패킷 이동 경로
1) 단순히 내부 <--> 외부로 나갈 때
(리눅스 박스의 어떤 서비스(FTP, 삼바 등)도 이용하지 않고, 브릿지로만 통과할 때...)
Linux BOX
+--------------+
| |
| Services |
| (FTP, |
| apache, |
| 삼바 등) |
| |
| |
| |
+--------------+
외부 | | 내부
<-----------------------------------
----------------------------------->
| Bridge |
+--------------+
(통과하는 패킷 개수 변동)
CHAINS : input = 통과하는 패킷 없음
output = 통과하는 패킷 없음
forward = 통과하는 패킷 없음
br_thru = 모든 패킷 통과함
br_input = 통과하는 패킷 없음
br_out = 통과하는 패킷 없음
==> input, output 체인을 건드려 봐야 헛수고다.
2) 내부, 또는 외부 <--> Linux BOX 서비스를 이용할 때
(리눅스 박스의 어떤 서비스(FTP, telnet, 삼바 등)를 이용하려고 할 때..)
Linux BOX
+--------------+
| |
| Services |
| (FTP, telnet |
| apache, |
| 삼바 등) |
외부 | | 내부
| |
| | | | | |
+--| |----| |--+
output | | | | | | input
<------<----+ | | +--<--------<--
--->------>---+ +-------->------>
input | Bridge | output
+--------------+
(통과하는 패킷 개수 변동)
CHAINS : input = 패킷 통과함
output = 패킷 통과함
forward = 통과하는 패킷 없음
br_thru = 모든 패킷 통과함
br_input = 패킷 통과함
br_out = 패킷 통과함
==> br_input, br_out, br_thru 체인을 적절히 만져주면 좋은 방화벽을 만들수 있
다. !!! 결론) 모든 패킷은 브릿지 체인을 반드시 통과하게 되어있다.
(너무 당연한 것이지만... 이 그림이 머리속에 그려지지 않아
삼일 날밤을 새었다. ㅠ.ㅠ; 돌머리의 비애~)
PS) 여기에서는 NIC 2개로 리눅스 박스를 구축하고, 그 두 NIC로 브릿지를 묶었다.
여러개의 NIC를 가지고 있어, 브릿지에 묶이지 않은 NIC와 관련된 체인들은 더
욱 자세하게 모니터링 해서 더욱 구체적인 체인들을 만들어 관리해야 할 것이다.
7. 커널 2.4.x에서 설정
----------------------
커널 2.4.x 용 패치를 받아서 커널에 적용한 후에 아래와 같이 하면 된답니다.
아마도 아래의 글은 마스커레이딩 기능까지 이용해서 FORWARD 체인을 이용하나 봅니다. :)
마스커레이딩을 하지 않는다면 위 문서대로 하면 될것 같네요. FORWARD 체인을 건드리지
말고요... (제가 직접해보지는 않아서 확신할 수는 없습니다. 여러분들이 한번 해보세요.)
(이운억님의 댓글을 옮깁니다.)
......... 시작 ...........
커널 2.4.x, iptables 그리고 masquerading 에 관한 설정을 힘겹게(?) 끝내고서
다음을 위해 토를 답니다 ^^;
랜카드는 두장으로 위 문서와 동일합니다. eth0 가 외부이고,
eth1이 내부 허브에 연결되는 구조도 같습니다.
랜카드가 모자란 관계로 bridge 에 ip alias 를 이용하여 가상IP를 할당합니다.
(참고로 아래 mybridge 는 위 문서상에서 dev-br 에 해당합니다.)
ifconfig mybridge:1 가상IP netmask 가상네트웍마스크 up
ipchains 로 br_thru, br_input, br_out 체인을 만든것 처럼 iptables 로
똑같이 만들면서 약간 수정하였습니다.
/sbin/iptables -N mybridge
/sbin/iptables -N br_thru
#/sbin/iptables -A mybridge -j br_thru
/sbin/iptables -A FORWARD -i eth0 -j br_thru
여기서 FOWARD 로 지정해야만 아래쪽에 지정할 방화벽 정책들이
적용되더군요 ( 한참 시행착오를 했답니다 -_-; )
/sbin/iptables -N br_input
/sbin/iptables -A INPUT -i eth0 -d 리얼IP -j br_input
인터페이스를 명시해 주었지요.
/sbin/iptables -N br_out
/sbin/iptables -A OUTPUT -o eth0 -s 리얼IP -j br_out
여기도 마찬가지로 인터페이스를 명시.
...
필요한 방화벽 정책
...
#
# IP Masqrade
#
/sbin/iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
이렇게 설정하고서 지금 마스크된 PC에서 글을 작성하고 있습니다.
............. 끝 ..............
다시 유천 덧글)
위 설정을 자세히 보니 무언가 잘못됬다는 생각이 듭니다. 브릿지가 아니라
마스커레이딩 설정을 한 것 처럼 보이네요. 브릿지는 mybridge인데 iptables에서는
-i eth0(외부)로 설정을 했네요. 이러면 브릿지는 무용지물이 될 법 합니다.
#/sbin/iptables -A mybridge -j br_thru
/sbin/iptables -A FORWARD -i eth0 -j br_thru
/sbin/iptables -A INPUT -i eth0 -d 리얼IP -j br_input
/sbin/iptables -A OUTPUT -o eth0 -s 리얼IP -j br_out
/sbin/iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
요 부분을
/sbin/iptables -A mybridge -j br_thru
/sbin/iptables -A INPUT -i mybridge -d 리얼IP -j br_input
/sbin/iptables -A OUTPUT -o mybridge -s 리얼IP -j br_out
/sbin/iptables -A POSTROUTING -t nat -o mybridge -j MASQUERADE
요렇게 고쳐야 브릿지로 나가고 들어올 것 같습니다.
해보세요~ ^^; 안되면 열심히 삽질하시고, 그 해결책을 올려주십셔~ ^^
**********************
*** 2002.5.15 수정 **** 필독!!!!!!!!!!!!!!!
**********************
---> 커널 2.4.x에서는 dev-br 체인을 만들어주지 말고, 그냥 FORWARD, INPUT,
OUTPUT 체인을 만져주면 됩니다. 2.2.x와는 유일하게 다른점이랍니다. ^^
8. 질문 & 의견
--------------
*. Bridge의 메일링 리스트
--> http://www.math.leidenuniv.nl/mailman/listinfo/bridge *. 유천 송덕균(tfreeman at korea.com)
잘못된 점이나 의견 있으신 분은 댓글 달아 주시고, 전 현재 네트웍 일을 그만둔 상태라
정확한 답변은 드릴수가 없네요. 고수분들께서 잘못된 점이나 수정해야될 부분 있으면
의견 주십시오.
9. 감싸~
--------
. 새로운 브릿지 code 를 만든 Lennert Buytenhek
. 리누스 토발드
. GNU 개척자들
. 브릿지 관련글을 만든 정정화님
. 정상화님, 이운억님 등 여러 고수님들 :)
꼬랑지~
-------
제가 처음에 브릿지를 생각한 것은 기존의 네트웍 변경 없이 어떻게하면 리눅스 화이어월
를 붙일 수 있을까 고민하던 중이었습니다. 그 당시만 해도 제가 NAT에 대한 개념을 단순히
마스커레이딩만 생각하고 있어서, 리눅스 화이어월을 구축하려면 그 밑의 네트웍은 가상IP
로 모두 바꾸어야 했거든요. 실제로 커널 2.2.x의 NAT(NAT라고 말할수 있을까? -.-;) 기능은
단순 마스커레이딩이었죠.(아닌가요? 자세히는 몰라요.) 도대체 제 능력으로는 커널 2.2.x에
서 두 네트웍을 포워딩(연결)시킬수 없었습니다. 그래서 브릿지를 생각한 것이고, 그 브릿
지에 화이어월이 있을 법도 하다는 생각이 들어 인터넷을 뒤졌죠. :) 그때 마침 kldp.org에 정
정화님 의 브릿지 화이어월이라는 글을 보고, 그대로 따라 할려고 하니 커널 2.2.19는 bridge S
TP 방식 으로 대체되었더군요. linuxdoc.org에서 Bridge-STP-HOWTO를 보고 돌머리를 굴려가면서 삽
질을 했죠.
그런데 새로나온 커널 2.4.x는 SNAT, DNAT 개념을 가진 NAT였죠. 두 네트웍 사이를 SNAT와
DNAT를 이용하여 연결할 수 있을 법도 합니다. 그러면 브릿지의 기능이 굳이 필요 없겠죠.
제가 잘못 생각한 것인가요? ^^a
그래도 브릿지가 필요한 이유는 투명하다는 것이 겠지요. 데이터링크 계층에서 작동하기
때문에 외부에서는 절대로 침입할 수 없죠. (커널 2.2.x의 경우 같은 LAN 안에서 IPX는
화이어월에 걸리지 않더군요. -.-; 아마도 커널 2.4.x에서는 걸러낼수 있을 겁니다.
같은 LAN 안에서 울 회사와 저쪽 회사에서 스타를 IPX로 하는데 막을 수가 없더군요.
tcpdump로 보니 MAC 어드레스로 데이터가 왔다갔다.. -.-; ipchains의 한계입죠.
아마도 커널 2.4.x의 iptables는 MAC 어드레스도 제어가 가능할 겁니다.) 이거 네트웍에서
손땐지 꽤나 되나서 맞나 모르겠네요...
여하튼 이 보잘것 없는 문서가 여러분의 네트웍 구성에 쬐끔이나마 도움이 되었으면 합니
다. (__)
</pre>