하드웨어 ARP 스푸핑을 ISP 차원에서 막는 방법은 없나요?

제가 아는 거라고는 https://www.wireshark.org/ 이 걸로 분석 해서 대처 하는 방법 밖에 모르는대 정작 이거 사용 방법을 모르겠어요 ㅎㅎ;;검색 해봐도 없더라고요 ㅠㅠ.. 찾아도 너무 난해 하게 설명 되어 있고요 ㅎㅎ 참 그리고 장비가 너무 고가라고 하던대.. ㅎㅎㅎㅎ.. 참 그리고 제가 들은 걸로는 지금 기술로는 막을 방법이 없다내요.. 위의 프로그램으로 패킷 검사 해서 일리리 수작업 해야 한다고 하더라고요.. -_-;; 장비 구매 해야지 수작업 해야지.. 솔류션 돌려야지.. 사원도 없는대 보안 업체도 아닌대 누가 그런거 할사람도 없고.. 그런 것 같더라고요 그래서 기업들도 막 기업 정보 유출 되고 왔다 갔다 해도 모른다고 하던대.. 대표 기업들도 기술 정보 막 빼간다는 쉬쉬 해서 모르고 있는 암시장 엄청 크다고 들었어요.. 뉴스에도 나옴.. ㅎㅎ;;

더 웃긴건 해커를 기업에서 키우고.. 보안 관리자는 찬밥이란 거죠.. ㅎㅎ;; 서로 서로 해킹 하기 대회도 아니고 ㅎㅎ;;

보안 관리자는 힘들어서 머리 다 빠질라고 함 ㅎㅎ.. 대머리..농담..

Static ARP 정보 관리
변경 주기가 잦지 않은 주요 네트워크(게이트웨이) 및 시스템(서버) 등에 대한 IP/MAC주소 pair 정보에 대해서는 ARP 정보를 Static 하게 관리하여 ARP Spoofing에 의한 ARP Cache 테이블의 주요 정보의 변조를 미연에 방지한다. ARP Spoofing을 이용한 ARP Cache 테이블 변경에 가장 효과적인 대응 방법이면서, 네트워크 구조 변경이 잦은 기업에게는 일반적인 Dynamic 모드에 비해 유연하지 못하므로 적용시 주의가 필요하다. 각각의 시스템이 부팅할 때마다, 미리 정의된 static ARP table을 구성하도록 한다. 동일한 LAN상의 중요 시스템(스위치, 게이트웨이 등)에 대한 static ARP을 목록화하여 관리한다. 시스템의 수가 적고 변화가 크지 않은 소규모 기업에 적당한 대응 기술로서 시스템의 정상적인 IP/MAC주소 pair 정보의 추가/변경/삭제에 대한 static ARP table 세심한 관리가 요구된다. 다음과 같이 시스템의 arp 명령어의 '-s' 옵션을 사용하여, static ARP 정보를 등록할 수 있다.

L2 보안 스위치 도입
스위치에서 Port Security 기능이 제공될 경우, Mac Flooding이나 MAC Spoofing 등의 공격을 최소화할 수 있다. 스위치 포트마다 최대 허용 가능한 MAC주소 설정할 수 있다. 스위치 포트에 하나 이상의 MAC 정보가 매핑되는 경우 해당 포트의 기능을 차단할 수도 있게 된다. 또한, 특정 스위치 포트마다 접속을 허용하거나 차단할 static MAC 주소를 미리 설정해둔다. 이러한 기능을 통해 공격자가 피해시스템(victim)의 IP주소를 이용하여 자신의 MAC 주소가 스위치의 CAM(Content Addressable Memory) table에 등록되는 것을 방지할 수 있다.

ARP 모니터링 도구 도입
ARP Spoofing 공격을 직접적으로 차단할 수 있는 방법은 아니지만, ARP 모니터링을 통해 공격에 대한 탐지가 가능하다. 일반적으로 ARP 모니터링 도구들은 LAN상의 ARP 패킷들을 수집하여 IP/MAC pair 정보를 데이터베이스화한다. 모니터링 과정에서, ARP Cache 정보의 변경이 탐지되면, 시스템 화면 하단의 트레이 아이콘에 탐지 솔루션의 아이콘이 껌벅거리게 되거나(WinARPWatch), 관리자에게 notify가 가능하여 사후 조치가 가능할 수도 있다.

NAC(Network Access Control) 솔루션 도입
근래에 여러 가지 형태의 NAC(Network Access Control) 솔루션이 등장했다. 모든 트래픽을 미러링 받아 트래픽을 분석하는 방법, 브로드캐스트/멀티캐스트 등을 받아 트래픽을 분석 하는 방법, 802.1x 를 기반하여 네트워크 접근을 제 어하는 솔루션 등등, 여러 가지 형태를 통해 이상 트래픽을 감지할 수 있다.

위 방법 중에 돈 안드는건 Static ARP 정보 관리 뿐이네요..ㅎㅎ

저도 보안업체에서 일하는데 ARP Spoofing 때문에 난리네요..ㅎ

만약 방법이 있다면 왜 ISP에서 ARP 스푸핑을 방지하기 위한 작업을 하지 않는 것인지 궁금하네요....

1. 기존의 장비만으로는 구현할 수 없는 것인지, 아니면
2. 구현할 수는 있어도 구현을 위해서는 네트워크 Load가 많이 걸리기 때문에 구현하지 않는 것인지, 아니면

- 인터넷 서비스를 제공하기 때문에 기존 장비만으로는 구현 불가능, 단순 사내망일 경우는 구현 가능하지만
일반 인터넷 서비스 망에서 제공할 경우 가입자들의 인터넷 사용에 심각한 문제가 생김.
가입자 인증과정과 DHCP에서의 IP할당에서도 문제가 생김.
(DHCP서버에서 MAC인증 과정을 거쳐 ip를 할당해 주고 가입자 실명인증 서버를 통한 2차 인증을 거치기 때문에
구현 자체가 현실적으로 불가능)
그리고 이런 스푸핑 방어 장비를 설치 하려면 스위치 자체가 그 기능을 가지고 있어야 하는데
그 기능을 가지고 있더라도 다양한 방법으로 우회나 교란이 가능해서 그 효과는 큰 기대를 하지 말아야 하고
모든 스위치를 이런 막강한 기능이 있는 장비로 교체하려면 그 비용이 엄청나기 때문에
인터넷 서비스 업체에서 투자를 할 생각이 없답니다. (트래픽 문제도 한몫)
그렇다고 현재 깔려 있는 장비들이 방어 기능이 없는 것은 아니지만
현실적으로 있으나 마나한 수준일 뿐더러 위에 말했듯이 이런 기능 전체를 가동시킨다면
역시 인터넷 서비스를 할 수 없는 상태가 된답니다.

3. 구현할 수는 있어도 구현하는 것 보다,
단순히 해당 클라이언트만 분리하는 것이 더 효율적(간편한 방법)이기 때문인지 궁금합니다.

- 워낙 침해건수가 많기 때문에 이를 빠르게 통제할 전문 인력과 장비가 부족하기도 하고
원천적으로 막기 위해 일반가입자와 기업가입자(보안회선 사용자)를 따로 분리 해서 운영하고 있답니다.
효율적이다는 것 보다 사실 이윤을 극대화하기 위해 상업적인 목적이 우선시 되기 때문이라 보는게 옳답니다.
유휴 네트워크 자원을 놀리지 않고 장기 계약에 유리하고 높은 이용요금을 징수 할 수 있기 때문. 

네트워크 실무에서는 ARP 스푸핑 방지를 위해 Infrastructure 레벨에서
어떠한 방법이 사용되는지 궁금합니다.

- 실무 쪽에서는 보안이 필요한 회선에 한해서(기업용 VPN을 추가 사용료를 지불하고 사용해야 하지만
일반인들이 사용하기에는 고가)
사업체용 VPN을 제공하거나 사업체에서는 외부로 연결되는 주회선은 VPN으로 구축하고
사내의 경우에는 VLAN,WLAN 등을 이용해서 폐쇄 네트워크를 구축해서 쓴답니다.
기관망의 경우에도 역시 VPN을 사용하기 때문에 같이 물려있는 동일 영역내에서 일반회선(일반 인터넷 가입자용)
과는 분리 운영하기 때문에 상대적으로 스푸핑의 위험은 극히 낮답니다.
그리고 고도의 보안이 필요한 네트워크의 경우 하드웨어 방화벽은 물론 실시간 트래픽 모니터링을 하고 있고
이상 트래픽 발생시 자동으로 기록이 되며 패킷 분석이 가능한 시스템이 구축돼 있답니다.
어느 정도 규묘가 있는 사업체등의 경우 전세계 적으로 많이 이용하는 Juniper Networks도 많이 사용 한답니다.
Juniper Networks나 유사한 서비스형태들은(각 ISP별로 사업체 대상으로 서비스중)
 몇 단계에 거친 사용자 인증을 거치 때문에 상대적으로 안전하지만
사내 직원의 실수로(클라이언트가 바이러스에 감염되거나) 문제가 생기거나
설치된 Infrastructure 장비(스위치 같은)에 취약점이 있다면 이것도 뚫리는 것은 패치하기 전까지는
막을 수 가 없으니 물리적 분리 네트워크 외에는 완벽할 수 는 없답니다.(Juniper Networks 침해 사고는
매년 수도 없이 발생하니까요)
다만 일반 이용에 비해 상대적으로 안전한 네트워크 이용을 할 수 있답니다.

일반인터넷 이용자들의 경우는 월 몇 만원에 제공되는 VPN을 사용하면 되지만
인터넷 속도에 민감한 사용자들의 속도 저하 문제와 월 인터넷 사용료 외에 VPN 사용료까지 지출하게 되는 문제로
이 부분은 개인들의 선택에 따라 좌우된답니다.
(무료 VPN 이야기는 할 필요가 없는 이유가 무료로 이용되는 VPN 서버를 신뢰 할 수 없기 때문이랍니다)