대규모 환경을위한 iptables 관리 도구


15

내가 운영하는 환경은 대규모 웹 호스팅 운영 (수백 대의 서버, 거의 모든 공개 주소 지정 등)이므로 ADSL 링크 관리에 대해 이야기하는 것은 잘 작동하지 않을 것입니다. 핵심 규칙 세트 (현재 카운트에서 iptables에있는 약 12,000 개의 항목)와 고객을 위해 관리하는 호스트 기반 규칙 세트를 모두 관리하는 데 편한 것을 찾고 있습니다. 핵심 라우터 규칙 세트는 하루에 몇 번 변경되며 호스트 기반 규칙 세트는 한 달에 50 번 정도 변경 될 수 있습니다 (모든 서버에서 한 달에 5 대의 서버 당 한 번 변경 될 수 있음).

우리는 현재 filtergen (일반적으로 공, 우리의 작업 규모에서 슈퍼 볼)을 사용하고 있으며 과거에는 다른 작업에서 해안 벽을 사용했습니다 (filtergen보다 바람직하지만, 나는 그보다 더 나은 무언가가 있습니다).

교체 시스템에 대해 우리가 생각 해낸 "필수 사항"은 다음과 같습니다.

  • 규칙 세트를 상당히 빠르게 생성해야합니다 (규칙 세트에서 filtergen을 실행하는 데 15-20 분이 소요됩니다. 이건 제정신입니다)-이것은 다음 시점과 관련이 있습니다.
  • iptables-restore 스타일 파일을 생성하고 모든 규칙 삽입에 대해 iptables를 호출하지 않고 한 번의 히트로로드해야합니다.
  • 규칙 세트가 다시로드되는 동안 장기간 방화벽을 중단해서는 안됩니다 (다시 말하면 위의 결과입니다).
  • IPv6를 지원해야합니다 (IPv6와 호환되지 않는 새로운 것은 배포하지 않습니다)
  • DFSG가 없어야합니다
  • 일반 텍스트 구성 파일을 사용해야합니다 (수정본 제어를 통해 모든 것을 실행하고 표준 Unix 텍스트 조작 도구를 사용하는 것이 SOP 임)
  • RedHat과 Debian을 모두 지원해야합니다 (패키지 선호). 그러나 최소한 배포판의 표준에 지나치게 적 대해서는 안됩니다.
  • 시스템의 "기본 언어"에 포함되지 않은 기능을 지원하기 위해 임의의 iptables 명령을 실행하는 기능을 지원해야합니다.

이러한 기준을 모두 충족하지 않는 것은 고려되지 않습니다. 다음은 "좋은 것"입니다 :

  • 구성 파일 "조각"을 지원해야합니다 (즉, 디렉토리에 파일 더미를 버리고 방화벽에 "규칙 세트에이 디렉토리의 모든 것을 포함 시키십시오"라고 말할 수 있습니다. 우리는 구성 관리를 광범위하게 사용하며이 기능을 사용하려고합니다. 서비스 별 규칙 자동 제공)
  • 원시 테이블을 지원해야합니다
  • 수신 패킷과 거부 규칙 모두에서 특정 ICMP를 지정할 수 있어야합니다.
  • 하나 이상의 IP 주소로 확인되는 호스트 이름을 정상적으로 지원해야합니다 (여기서 filtergen을 사용하여 여러 번 잡혔습니다. 엉덩이에 약간의 고통이 있습니다)
  • 도구가 기본적으로 또는 기존 또는 쉽게 쓸 수있는 플러그인을 통해 지원하는 옵션 / 이상한 iptables 기능이 더 좋습니다. 우리는 때때로 iptables의 이상한 기능을 사용하며, "그냥 작동하는"기능을 많이 사용할수록 모든 사람에게 더 좋습니다.

물어 볼게요. 글에서 "공"과 "슈퍼 볼"이라는 용어는 무엇입니까? 탄력있는 고무 구체에 대해 이야기하고 있지 않다고 생각하지만 문맥이 "좋은"또는 "나쁜"을 의미하는지 추측 할 수 없습니다.
Evan Anderson

공 == 나쁘다. 슈퍼 볼 == 추가 불량.
womble

규칙이 많으면 맨 위에 허용 및 설정된 연결을 수락하는 ACCEPT 규칙이 있어야합니다. PC에는 TCAM이 없으며 많은 규칙이 성능에 영향을 미칩니다. 많이.
토마스

@ Thomas : 그렇습니다. 규칙 세트에 적용되는 일정량의 최적화가 있습니다. 물론 어떤 방화벽 도구를 선택하든 최적화에 대한 "지식"을 갖는 것은 보너스입니다.
womble

답변:


4

규칙 중심 접근 방식에서 "최종 상태 설명"작업을 수행하려는 경우 fwbuilder를 살펴보십시오.

장점 :

  • 여러 방화벽 지원-핵심 + 호스트 기반 규칙-1 개 개체 집합에서
  • SQL-esque "어떻게 원하는지 말해줘"대신 "어떻게해야하는지 알려줘"접근 (NB 거기에 SQL이 없다고 말하지는 않는다!
  • 벤더의 상용 하드웨어 인터페이스와 같은 GUI이므로 직원 / 기술 스택 아래로 일부 작업을 푸시 할 수 있습니다.
  • 내가 시도한 대부분의 "지저분한"사용법을 지원합니다
  • 다양한 f / w 구현에 대한 규칙을 생성 할 수 있습니다-BSD / cicso / iptables / etc
  • 규칙 컴파일러와 프론트 엔드를 분리하여 속도가 저자에게 우려가되기를 바랍니다. NB 난 네가 암시하는 척도 근처에 아무것도 없어
  • 파일 형식이 이진이 아닙니다
  • IPv6합니까
  • 원자 적이며 빠른 로딩을위한 iptables-save stylee 구성 생성

단점 :

  • GUI입니다
  • 기존 규칙 세트를 이동하는 데 어려움이 없을 것
  • GPL과 데비안에서 Windows + OSX 클라이언트는 30 일 평가판입니다. 아무도 해당 OS를 위해 아직 무료 버전을 크로스 컴파일하지 않았기 때문입니다. 따라서 개발자의 상업적 팔은 그 바이너리에 독점권을 가지고 있습니다.
  • 파일 형식은 기술적으로 XML입니다. NB는 이것을 포기하지 않습니다 : 그들이 제공하는 도구 (예를 들어 GUI 바이너리를 사용하여 CLI를 통해 조작 할 수 있음), 이미 존재하는 CLI XML 도구를 살펴보고 기억하십시오. 규모-메타 데이터 + 구조의 일부는 / bad /가 아닙니다! IIRC에서는 편집 내용이 상당히 다릅니다.

링크 : http://www.fwbuilder.org


흠 ... 한번 볼게요. GUI (XML은 말할 것도없이)가 존재하기 때문에 좀 더 심하게 비틀 거리게되지만 흥미로운 아이디어 (전체 인프라에 대한 단일 규칙 집합)를 발생시킵니다. OS X는 문제가되지 않습니다.
womble

나는 GUI가 원래 WTF를 만들었 음을 동의하지만 CLI 측면에서 본 것에 만족했다. 어쨌든 설정이 얼마나 역동적입니까? 하루에 10 번, 1 년에 10 번 변경됩니까? 여기서 자세히 설명하는 유용한 요소가 될 수 있습니다. 또한 XML 파일 형식의 좋은 기능은 XML 인식 도구를 사용하여 단일 정의 객체를 사용하여 하나의 파일로 전체 구성을 가질 수 있지만 개별 서버의 구성 및 변경 세트를 문서화하기위한 노드 별 변경 로그를 생성 할 수 있다는 것입니다. . 그냥 생각 ...
Jonathan Matthews

@Jonathan : 맞습니다. 규칙 집합의 역 동성을 알아야합니다. 질문을 편집했습니다. 핵심 규칙 집합에 대한 대부분의 근무일은 하루에 몇 번입니다.
womble

3

직접 작성하십시오. 진지하게-이 규모로 합리적입니다.

사용 ipset 및 / 또는 먼저, iptable 테이블 / 서브 테이블을 많이. 가능할 때마다 일부 서브 테이블 / 일부 ipset 세트 만 다시로드하면 재구성 속도가 빨라집니다.

아마도 이미하고 있지만 여전히 언급 할 가치가 있습니다. 중첩 된 테이블을 사용하여 라우터의 부하와 새로운 연결을 설정하는 패킷에 필요한 평균 조회 수를 줄이십시오. 분명히-앞으로 -m 상태-상태가 정해져 있으며, 관련이 가장 중요합니다.


"우리의 글을 쓰십시오"는 표에서 나오지 않았지만, 처음에 filtergen을 얻은 이유는 지금 전직 직원이 작성했습니다. 가능한 경우 다른 방화벽 관리 도구를 생성하지 않는 것이 좋습니다.
womble

대규모 규칙 세트의 경우 IPSET이 매우 빠릅니다. "한 번에 여러 IP 주소 또는 포트 번호를 저장하고 iptables로 수집과 일치; 성능 저하없이 IP 주소 또는 포트에 대해 iptables 규칙을 동적으로 업데이트; 단일 IPtables 규칙으로 복잡한 IP 주소 및 포트 기반 규칙 세트를 표현하고 속도의 이점 IP 세트의 "나는 shorewall와 함께 사용합니다. 나는 당신의 규모로 쇼어 월이 어떻게 작동하는지 전혀 모른다.
artifex

2

거룩한 공 (테마를 살려라!) 남자 ... 12,000 핵심 규칙?

단순히 세트를 CVS에 놓는 것과 같은 모든 쉬운 옵션을 고려했다고 가정합니다. 꼭두각시 또는 CFengine?

솔직히, 당신이 제시 한 광범위한 개요에서, 나는 당신의 네트워크 디자인을 재평가 할 것을 강력히 권합니다. 나는 아마도 너무 단순하지만 12k iptables 규칙을 필요로하는 디자인을 간단히 이해할 수는 없습니다. 방화벽 규칙을 관리하는 더 좋은 방법보다 SLB 유형 솔루션의 이점이 더 큰 것처럼 들립니다.

참고로, "응답"을 추가하는 것과 어떻게 주석을 추가합니까?


의견을 남기려면 최소한의 평판이 필요합니다. 당신이 할 때 링크가 나타납니다.
jay_dubya

iptables 규칙에는 어느 정도의 중복성이있을 수 있지만 filtergen의 기능은 그다지 효율적이지 않을 수 있습니다. 그러나 우리는 / 19의 IP 공간과 고객 당 VLAN, 상당히 제한적인 "기본 정책"(고객이 요구하는대로 포트를 열기 위해 IP 별 예외가 필요함)을 가지고 있습니다. 우리는 분명히 그 규칙 중 몇 가지 이상을 제거 할 수는 없습니다. 아, 그렇습니다. 우리는 이미 Puppet을 사용하고 있으며, 운영 규모에 따라 규칙 세트를 직접 작성하지는 않습니다.
womble

글쎄, 당신은 확실히 나보다 더 큰 IP 공간을 유지하지만, 나는 여전히 많은 규칙을 정당화하는 것이 어렵다는 것을 안다. 당신은 이것들을 트리 구조로 분해하여 초크 포인트에서 폴 스루 규칙 설정을 활용할 수있는 방법을 생각해 보셨습니까? 즉, 서브넷 X의 모든 웹 전용 서버, 서브넷 Y의 모든 웹 + smtp 서버? 실제로 그것들을 서브넷으로 묶을 필요가 없으며 논리적으로 계층화 된 방화벽 뒤에 그룹화 할 것입니다 ...이 시점에서 잡음을 추가하는 경우 미안합니다 ... 나는 이것에 충분하지 않을 수 있습니다. 나는 방화벽 규칙 세트가 짧고 잔인하다 =)
Greeblesnort

우리는 실제로 그런 것을 "계층화"할 수있는 위치에 있지 않습니다. 우리는 주로 전용 서버 호스팅 제공 업체이므로 고객이 일상적인 컴퓨터로 수행하기로 결정한 내용이 변경 될 수 있으므로 내부 서비스를위한 전용 인프라를 구축하는 것보다 훨씬 더 많은 춤이 필요합니다.
womble

0

12000 규칙? 미쳤냐? 이 정도의 필터링으로 인해 성능 문제가 발생하지 않습니까? 왜 12,000 개의 규칙이 필요한지 알 수 없습니까? 규칙 세트가 실제로 정책을 시행하고 있는지 어떻게 확인합니까?

정책은 무엇입니까?

정책을 어떻게 테스트합니까?

12,000 개의 규칙이 책의 모든 보안 규칙을 위반할 수 있습니다.


-2

iptables-> https://www.efw.io/Forum 관리를위한 SAAS 솔루션을 사용해 볼 수도 있습니다. 또한 AWS 클라우드 통합도 수행 할 수 있습니다.


SaaS 오퍼링에 DFSG가없는 것 같습니다.
womble
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.