김윤술 2010-09

방화벽 실시간 모니터링 돌려보면 바로 나올거 같은데요...
제가 보기엔 클라이언트 PC가 좀비가 있는걸로 보입니다. 특정 PC가 아웃바운드 UDP 세션을 잡은거 같아요. UDP포트를 차단했다고 UDP 아웃바운드가 안되는것이 아닙니다. 방화벽 실시간 로그 돌려보면 잡을수 있을거 같음. 전 ISA단에서 그 좀비 PC 잡았었죠. 클라이언트는 정말 아무것도 모르고 있었습니다. 백그라운드 서비스에서 대량으로 외부 아무데나 악성 스팸을 보내고 있었다는걸...

미녀와확고… 2010-09

흠 저희가 보유하고 있는 방화벽은 가격대비 성능위주로 선정을 했더니...로그 기능이 많이 모자란 편입니다.
근데 저희가 내.외부 UDP 아웃바운드를 필수적인거 빼구 다 막았는데 아웃바운드가 되나요?
허용된 포트가 아니면 다 패킷을 드랍시키도록 해놨는데...
좀비가 있는 건 맞을겁니다. 얼마전에 사내에서 디도스 공격 트래픽이 발생해서 문제가 된 경우가 있었거든요.

선철 2010-09

저정도라면 장비들에서 뿜어져나오는 전자파도 상당할테니, 혹시 케이블이 전자파의 영향을 받는건 아닐지 모르겠습니다.
특정 서버만 그렇거나한다면 케이블 테스트도 해보셔야 할 겁니다.

미녀와확고… 2010-09

전자파의 영향은 아닐겁니다.
위의 회선도에서 클라이언트용 허브 100여개 정도는 한곳에 뭉쳐있는게 아니라 이곳 저곳에 분산되어 있는 EPS실에 있는 허브의 갯수라서요.
뭐 그렇다고 서버가 수백대씩 있는 그런 곳도 아니니까요.

강인식 2010-09

방화벽 기능이 미약하다면 L2 스위치에 노트북을 바로 물려서 wire shark 를 돌려보아도 됩니다.

TCP 덤프만 떠봐도 어느정도 상태를 가늠할 수 있습니다.

별 문제가 없다면 Link negotiation 도 확인해 보시기 바랍니다.

김윤술 2010-09

스위치나 허브가 관리형이라면 포트 하나를 미러링 포트로 만들구요 스니핑을 해보세요.

유철종 2010-09

네트워크의 구성이 매우 이상하네요.

VLAN을 사용하시나요?

아니라면 저런 물리적 구성에서 네트워크 대역이 두개인 이유가 뭔가요?

제가 보기엔,
VLAN을 사용하지 않는다면 저런 구성에서 문제없이 정상적으로 동작한다면 그게 더 이상할 것 같군요.

김윤술 2010-09

당연히 서버용과 클라이언트용은 대역이 다르게 하는게 좋은 방향입니다. 중간 라우팅 기능이 되는 방화벽에서 정책으로 접근을 통제하는거죠. VLAN을 하였다 하더라도 중간에서 라우팅을 해주지 않으면 클라이언트에서 통신을 못하기 때문에 두대역 이상 나누어 주는것이 좋은 방향인거 같아요. ISA도 저런 구성을 사용합니다.

유철종 2010-09

MS에서 네트워크를 저런식으로 구성하라고 하나요? 어이가 없네요.

IP 대역을 나누는 이유를 생각해보세요.

저런 환경에서 한 사용자가 자신의 IP를 서버대역으로 맞추고 통신을 하면
ISA가 도대체 뭘 할 수 있죠?

물리적 환경이 이미 잘못되었는데 ISA가 아니라 ISA 할아버지가 온들 무슨 소용이 있습니까?

미녀와확고… 2010-09

글쓴이입니다.
그다지 좋은 구성은 아닌건 부인하기 힘드니 열내지 마세요... ^^;
하다못해 VLAN도 구성되어 있지 않으니...
방화벽에서 하단의 스위치로 연결되고 여기서 서버용 허브, 클라이언트 허브 등으로 분화되었기에
물리적으로 분할되었다고 보기는 힘들죠.

방화벽의 LAN 인터페이스가 다중 IP 대역을 지원하기도 하고...기존에 설치된 물리회선을 건드릴 수 없어 이렇게 구성이 된것이죠.

IP 대역 역시 기존에 사용하던 대역을 사용할 수 밖에 없는 상황이라 그렇구요.
설비 등에 설정된 IP 정보를 바꾸는 것도 일입니다.
여러 서비스와 얽혀 있어서 바꾸는게 어려운 설비도 있구요.

그래서 기존 대역에 추가로 대역을 더 붙여서 6개로 사용중입니다.
차후 확장을 대비해서 각 팀별로 넉넉하게 대역을 할당했거든요.

다만 말씀하신 것처럼 IP를 임의적으로 변경하는 것을 막고자 MAC Binding을 적용하려고 하고 있습니다.
IP 및 MAC 정보의 정리가 거의 끝났으니 등록하고 정책 적용만 해주면 됩니다.
Binding 정보를 계속 관리해줘야 하는 점이 귀찮지만...웹 차단 정책을 적용받지 않는 IP로 임의로 바꾸는 것을
막기 위해서도 MAC Binding이 필요하긴 합니다.

유철종 2010-09

글쓴 분께 열낼 이유가 없구요.

음, VLAN 구성이 되어 있지 않다면 현재 구성은 문제점이 발생할 소지가 많습니다.

우선 네트워크에 참여하고 있는 시스템 수가 상당히 많은데요.

이렇게 되면 브로드캐스트가 너무 많이 발생하게 됩니다.
네트워크가 물리적으로 분리되어 있지 않기 때문에 브로드캐스트가 네트워크 대역을 가로 지르게 되는 구조예요.
네트워크가 규모가 크고 물리적 환경이 이상해서 지연이 생기고 패킷 드랍이 발생하는 것도 무리가 아닙니다.

힘드시겠지만, 현재 환경에서 자꾸 드러나는 문제점을 막기보다는
전체적인 구성을 제대로 구축하는 작업을 진행해 나가시는게 좋으실 것 같습니다.

미녀와확고… 2010-09

뭐 저도 입사하고나서 여기 네트워크 구성에 대해 듣고 이거 어찌해야 하나 생각이 들었습니다.
전체적으로 사내의 회선을 다 뜯어 고치는 작업은 힘들 것 같습니다.
각각의 EPS실에 있는 허브가 어디랑 연결되는지 아는 사람이 없는 건 둘째치고...위의 구성도에서
방화벽 하단의 스위치에 물려있는 회선이 어디로 가는지도 아는 사람이 없어요.
그렇다고 하나씩 뽑아보면서 테스트 할 수도 없고...난감합니다.

지금 가장 심플한 해법은 방화벽 하단의 스위치를 성능 좋은 관리기능이 포함된 스위치로 변경하고 VLAN을 구성하는 것인데 이것은 내년초에 일정이 잡혀 있습니다.
라인이 쉬는 구정에 일정이 잡혀 있는데 그때 상황에 따라 라인이 쉬지 않는다면 또 연기되겠네요.
제가 아는 한도에서는 이게 가장 나은 해법인데 더 좋은 해법이 있다면 기탄없이 말씀해 주시면 좋겠습니다.

어쨌거나 제가 이 질문을 한 요지는 지금 상태에서도 지연이나 드랍은 없이 양호하게 사용중인데 가끔가다
드랍이나 지연이 생기는 이유가 궁금해서 입니다.
브로드캐스트 트래픽 때문에 발생한다기에는 종종 새벽에도 발생하는 이 현상을 설명하기가 어렵네요.

유철종 2010-09

음 그러시군요. 난감하죠.
예전에 회사 입사하면 늘 네트워크부터 전부 정비하던 생각이 나네요.
그쪽일을 하는 사람도 아닌데...

물리적으로 전체 환경을 바꿀 수 없다면 라우팅을 스위치단으로 분산시키도록 VLAN을 이용하는 것이 답일 거 같습니다.
다만 VLAN으로는 보안의 문제를 해결할 수 없다는 점은 염두에 두셔야겠죠.

그리고 현재 환경에서 문제가 발생할 수 있는 부분이 여러 곳이라 딱히 이게 문제다라고 말씀드리기 힘드네요.

라우터 역할을 하는 방화벽의 문제일 수도 있고 스위치의 문제일 수도 있습니다.
스위치가 여러 대역의 MAC을 learning하게 되는데 오동작을 일으킬 확률도 있을거 같네요.
중추 스위치의 경우 MAC table이 full이 날 확률도 높겠죠.

환경이 복잡해서 문제가 날 소지가 많고 또한 해결하기도 힘든 상황으로 보여집니다.
그다지 도움이 되는 답변 드리지 못해서 죄송스럽네요.

김윤술 2010-09

http://www.isaserver.org/articles/2004pubdmzservers.html

뭐가 어이 없다는건지 이상한데요? ISA가 그리 만만한 제품이 아닌데요. 직접 설계하고 라우팅하고 서버와 클라이언트간의 거의 완벽한 통제 정책중 하나입니다. ISA써보면 다른제품 눈에도 안들어옵니다.

유철종 2010-09

링크해주신 내용에서도 물리적인 네트워크가 분리되어 있습니다.
너무 기본적인 내용이라 아예 언급을 안하는 것인데,
이걸 물리적으로 동일한 네트워크에 대역을 나누라고 이해하셨나보네요. ^^;

네트워크가 분리되어 패킷이 라우터인 ISA서버로 지나가야 정책등이 적용되죠.

글쓴님께서 그려주신 네트워크 구성도를 가만히 한번 살펴보세요.
뭐가 문제인지 이해가 안가시면 ISA가 아니라 네트워크의 원리에 대해서 좀 살펴보시고 생각해보시면 좋겠네요.
이전 댓글에서 말씀드렸는데 이해가 안가신다면 글로는 설명 드리기 힘들 것 같네요.

그리고 ISA가 나오기 훨씬 전에도 리눅스에서는 저런 기능을 전부 구현했었고 활용하여 사용을 했습니다.
훨씬 전부터 PC기반에서 저런 기능을 하는 제품이 있었다는 것을 모르셔서 ISA에 그리 환호하시는거 같은데요.

예전부터 활용하던 입장에서는 뭐 그다지 신선할 것도 없는 다만 마우스로 똑닥거릴 수 있는 또 하나의 제품이라 생각되어질 뿐이네요. 뻑하면 리붓해도 되는 환경이라면 뭐 쓸만도 하겠지만요...

김윤술 2010-09

발로 윈도우 기반을 운영 하는 사람이나 뻑하는 리부팅 하겠죠. 전 이제까지 뻑해서 리부팅을 해본적이 없었습니다. 리눅스는 안뻑하든가요... 어짜피 다 똑같은건데

유철종 2010-09

하하... 죄송합니다. 제가 사투리를 사용해서 의미 전달이 제대로 안됐네요.

뻑하면은 시스템이 다운됐다는 의미가 아니라 '자주' 라는 의미로 썼습니다.
윈도 시스템도 좀 사용하는데 업데이트 리붓때문에 힘들더군요.
특히 ISA서버와 같은 역할은 라우터로 기능을 하게 되는데 이걸 자주 리붓을 해야 한다면
굉장히 관리가 어렵겠다는 생각이 들어서 한 소리입니다.

뭐 리눅스가 좋다 윈도우가 좋다 그런 내용은 아닙니다.
뭐 사용하는 입장에서 더 쉽게 목적을 달성할 수 있는 솔루션을 사용하는게 당연하지 않겠습니다.
대부분 특정 시스템이 굉장이 좋다던지 그것이 답이라고 우기는 사람들을 보면 그것밖에 모르는 경우가 많더군요.

강태욱 2010-09

제가 보기엔 헝그리정신에 입각해서 본다면 큰 문제는 없어보이는 구성인것 같습니다 해당하는 문제점에 대해 경험상 두가지만 체크해보세요 허브와 스위치는 엄연히 다릅니다 스위치는 방식에 따라 조금씩 다르긴 합니다만, 송신과 수신간의 데이터 전송시 순간적으로 전용회선(?)으로 연결합니다 1:1이죠 물론 브로드케스트일 경우엔 전 포트에 뿌리겠지만요 하지만 허브란놈은 그렇치 않습니다 한 회선을 공유하기 때문에 팻킷충돌이 날 수도 있습니다 이 원리가 이더넷방식의 기본 출발점이죠 그래서 팻킷충돌일 경우 모두 팻킷충돌 감지 이후에 멈춥니다 그리고 다시 보내죠 제가 이부분을 말씀드리는 이유는 10년 전엔 이러한 허브들이 있었지만 요즘엔 몇만원이면 스위치방식을 살수있죠 그리고 MS에서 서브넷팅(논리적,물리적 네트웍분리)을 해야하는 PC댓수는 대략 500대 일 경우엔 나누어야 한다고 합니다 왜냐면 우리가 통신을 시키는것 보다 그냥 발생되는 팻킷이 많은 탓이죠
1. 방화벽의 내부셋팅(예:MTU사이즈, 보안설정 등) 문제 또는 Nic인터페이스 불량
2. 사용하시는 구성이 허브라면 팻킷콜리젼(충돌)이 발생하는지 확인(모니터LED등이 있다면..)
    만약, 특정 허브나 포트에서 발생한다면 해당 허브나, 포트를 제거(Off) 시키고 테스트 해보세요
저도 약 10년전에 그런 구성으로 운영했지만 NT기반 방화벽(라우터)으로 사용시 트래픽 처리엔 문제가 없었습니다

미녀와확고… 2010-09

음...제가 위의 회선도에서 스위치 및 허브로 적은 이유는 구분을 하기 위해서입니다.
요즘 나오는 허브는 기존처럼 더미 허브가 아닌 전부 스위칭 허브라고 하더군요...
클라이언트용 허브가 3COM 또는 넷기어 허브로 대부분 구성되어 있는걸 확인했는데 가장 오래된 허브가 2006년도 구입품이니 더미 허브는 없다고 생각합니다.

차이점이라면 방화벽 하단의 스위치는 업링크 포트가 있는 제품이고 서버용이나 클라이언트용은 업링크 포트가 따로 없는 24포트 또는 8포트 등의 제품입니다.

그리고 특정 허브에서 발생하는 것은 아니고...드랍이나 지연이 일어나면 사내의 모든 컴퓨터 및 서버에서 발생합니다.
그래서 대역간 트래픽을 중개해주는 방화벽이 의심스러운데...문제는 뭐가 원인인지 찾을 방법이 딱히 없다는겁니다.

방화벽에서 세션 초기화를 하면 거의 대부분 정상으로 돌아오니 분명 이 부분과 관련이 있는데...

유사용 2010-09

방화벽이 L3도 같이 하는 구조인가 보네요.
방화벽을 초기화 하면 정상으로 된다는것을 봤을때, 방화벽 성능적 요인인것 같은데요.
현재의 방화벽 말고 다른 방화벽으로 테스트를 해보거나 Linux, Unix등 으로 만든 PC 방화벽을 한번 테스트 해보세요.
iptable, pf 등 PC를 활용하여 방화벽을 만들어서 테스트 해보시는것도 한 방법 이겠네요.
만든 방화벽에서는 문제가 없다면, 방화벽의 성능 문제 입니다.