Ch 23. Network Security 2011.11.29 SSEL, 민성현
Contents Introduction Policy Development Network Organization Availability Anticipating Attacks Addition – Next Generation FireWall, NGFW 본 23장에서는 한 회사가 웹 서비스를 비롯한 email service, 그리고 회사의 주요 데이터와 관련된 서비스를 하고자 하는 상황에 대해서 설명을 드릴 것 입니다. 이러한 상황 하에서 회사의 정보 보안에 대한 정책이 어떻게 정의되어 가는 지와 이러한 정책이 시스템에 어떻게 반영되어 가는 지를 통해 네트워크 보안에 대해서 알아보고자 합니다.
Introduction The Dribble corporation(Drib) Builds and sells dribbles, an electronic item Developing a network infrastructure allowing it to connect to internet to provide mail, web presence for consumers, suppliers, other partners The goals of the Drib’s security policy Data related to company plans is to be kept secret. When a customer provides data (such as a credit card number) to the Drib as part of a purchase, the data, and all information about the customer, are to be available only to those who fill the order. Releasing sensitive data requires the consent of the company's officials and lawyers. Drib는 소비자, 공급자, 기타 관계자들에게 메일과 웹 서비스를 제공할 수 있도록 외부 인터넷과 연결된 네트워크 인프라를 개발중입니다. 이 회사의 보안 정책의 목표로는 회사의 플랜, 민감한 데이터, 장차 나올 상품등에 대한 데이터는 보안이 유지 되어야 하고, 오직 권한이 있는 사람만 볼 수 있어야 한다. 사용자의 카드 번호와 같은 개인정보는 오직 주문을 하는 사람만이 볼 수 있어야 한다. 민감한 데이터는 회사 관계자가 변호사의 동의를 필요로 한다.
Customer Service Group Policy Development Customer Service Group Customer info. Credit-card info. Shared information Future plan New technology Corporate info. Lawsuit problem Development Group Corporate Group Drib 는 인증되지 않은 엔티티를 줄여 데이터에의 위협을 줄이고자 한다. 여기서 인증되지 않은 엔티티를 설명하기 위해 일단 회사 내부의 조직에 대해서 살펴보도록 하겠습니다. 고객 지원 팀이 있습니다. 약어로 CSG라고 합니다. 그리고 개발팀 DG가 있으며, 회사 임원진 CG가 있습니다. 세개의 그룹은 각각 private data를 갖거나, 일부 data를 공유하기도 한다 Public : 최신 상품에 대한 스펙이나 마켓팅 자료 CG, DG : 예산, 특허 출원 등 Customer Service Group(CSG) All dealings with customers Development Group(DG) Develops, modifies, and maintains products Corporate Group(CG) Handles the Drib’s debentures, lawsuits, patents, and other corporate-level work
Data Classes Public data(PD) available to anyone Product specifications, price information, marketing literature, and any other data Development data for existing products(DDEP) available to CG and DG. Development data for future products(DDFP) available to DG only Corporate data(CpD): available to CG Legal information Customer data(CuD) available to CSG only Customers supply, such as credit card information. 드립에서 다루는 데이터들은 다음과 같이 분류할 수 있습니다. 누구에게나 공개되는 퍼블릭 데이터 피디, 현재 개발이 진행되고 있는 제품에 대한 데이터 디디이피, 추후 개발할 예정인 제품 데이터 디디에프피, 법적으로 중요한 정보인 씨피디, 그리고 고객 지원팀에서만 접근이 가능한 고객 정보 씨유디가 있습니다. 이 데이터들은 늘 고정되어 있는 것이 아니라 상황에 따라 변경되기도 합니다 예를 들어 Ddef – ddep : 상품이 만들어 지면 Ddep – pd : 일부 개발 정보를 홍보하는 것이 이득이 될때 cpd – pd : 일부 권한이 필요한 정보가 합병, 소송 등으로 공개 되어야 할때 CuD 의 공개는 없으며 보호되어야 함.
User Classes Outsiders (O) Developers (D) Corporate executives (C) members of public Access to public data Can also order, download drivers, send email to company Developers (D) access to DDEP, DDFP Cannot alter development data for existing products Corporate executives (C) access to CD Can read DDEP, DDFP, CuD but not alter them Sometimes can make sensitive data public Employees (E) access to CuD only 본 네트워크 인프라를 사용하는 유저는 4가지로 분류되며 1. 아웃사이더로 공개 자료에 접근할 수 있으며, 제품에 대한 주문을 하거나, 제품의 드라이버를 다운로드 받고, 회사에 메일을 보낼 수도 있습니다. 2. 개발자들은 추구 개발할 제품 혹은 현재 개발 중인 제품 정보에 대해 접근을 할 수 있습니다. 하지만 현재 개발 중인 제품에 대한 수정 권한은 없습니다. 이는 회사 내부 검토가 아닌 고객들의 요구, 그 외에 부정확한 정보로부터 개발 중인 제품에 대해 변경을 하게 되면, 문제가 생길 수 있기 때문입니다. 3. 회사 임원진은 회사의 모든 정보에 접근할 수 있습니다. 하지만, 변경은 하지 못하는 정보가 있는 데, ddep, ddfp, cud 입니다. 민감한 정보에 대해서 회의를 통해 공개 정보로 수정하기도 합니다. 마지막으로 여기서는 직원, 4. employee로 표기가 되어있는 데, 고객 지원팀이라고 보는 게 좋을듯 하며 오직 CuD에만 접근할 수 있습니다.
Access Control Matrix for Policy D C E PD r DDEP DDFP r, w CpD CuD w 이렇게 정보와 그 정보들을 읽고, 사용하는 사용자에 대한 권한에 대한 정책을 바탕으로 표를 만들면 다음과 같이 됩니다. 아웃사이더는 공개 정보를 읽을 수 있고, 주문을 통해 자신의 고객 정보를 작성할 수 있습니다. 이러한 정책 외에 access control matrix에 영향을 미치는 사항이 몇 가지 있습니다. r is read right, w is write right
Availability Drib world-wide multinational corp Does business on all continents Imperative anyone be able to contact Drib at any time Drib places very high emphasis on customer service Requirement: Drib’s systems be available 99% of the time 1% allowed for planned maintenance, unexpected downtime Drib은 세계적으로, 다국적 기업이며, 전 세계에서 주문을 받습니다. 따라서 전세계 모든 지역에서 접근이 되어야 하며, 항상 시스템이 활용될 수 있어야 합니다. 드립은 고객 서비스에 대해 매우 강조하고 있으며, 이를 위해 계획된 유지보수 혹은 예상하지 못한 시스템 다운 타임을 제외한, 99%의 시간에 대해서 가용할 수 있어야합니다
Consistency Check Keep sensitive info confidential Developers Need to read DDEP, DDFP, and to alter DDFP No need to access CpD, CuD as don’t deal with customers or decide which products to market Corporate executives Need to read, alter CpD, and read DDEP Only employees who handle purchases can access customer data, and only they and customer can alter it Outsiders Need to alter CuD, do not need to read it Customer support Need to read, alter CuD This matches access permissions Releasing sensitive info requires corporate approval Must approve any reclassification No-one can write to PD, except through reclassification This matches reclassification constraints 그 다음 가용성 외에도 만족 시켜야 하는 기존의 goal 3가지가 있습니다. 이는 need to know를 원칙으로 삼겠습니다. 첫번째는 요주의 기밀 정보 유지 입니다. 이를 위해 디벨로퍼에게는 ddep, ddfp를 읽을 권한과 ddfp를 수정할 권한은 있지만, cpd, cud와 같은 정보에는 접근 권한이 필요 없습니다. 임원진은 cpd를 읽고, 수정할 수 있으며, ddep를 읽을 수 있습니다. 두번째는 구입에 대한 사항을 관리하는 임플로이만이 고객 정보에 접근할 수 있으며, 그들과 고객만이 고객 정보를 수정할 수 있어야한다는 것입니다. 이를 위해 아웃사이더는 cud를 수정할 필요는 있지만, 읽을 필요는 없으며, 고객 지원팀은 읽고, 수정 가능해야합니다. 셋째로 기밀 정보를 공개하는 것은 법인의 승인이 필요합니다. 이를 위해 임원진은 모든 정보의 reclassification에 대해 승인할 수 있어야하며, 누구도 pd를 쓸 수는 없습니다. Pd에 대한 변경은 단지 reclassification을 통해서만 가능합니다.
Consistency Check : Transitive Closure D C E PD r DDEP DDFP r, w CpD w CuD 이행 완료 r is read right, w is write right
Network Organization Partition network into several subnets Guards between them prevent leaks 앞서 정의된 policy에 따라 정보 가 세어나가는 것을 방지하기 위해 크게 외부와 내부 네트워크를 분리 하고 각 파트 사이에 가드를 구축한 네트워크 구조입니다. 내부 네트워크에 법인 정보, 고객 정보, 개발 정보에 대한 서브넷이 독립적으로 존재하며, 이는 이너 파이어월을 통해 보호받고 있습니다. 그리고 외부의 인터넷을 통해 회사 네트워크로 접근하는 트래픽들은 아우터 파이어월을 통해 접근이 조절될 것 입니다. 이 두 방화벽 사이에는 dmz, 디밀리터리 존이 존재하고 있습니다. 각각에 대해서 자세히 살펴보도록 하겠습니다.
Firewalls Firewall Filtering Firewalls a host that mediates access to a network Allows, disallows accesses based on configuration and type of access Filtering Firewalls Access control based on attributes of packets and packed headers firewall Corporate network Message of outsiders Is destination port 25345? 우선 앞에서 가드라고 표현한 방화벽에는 어떠한 것들이 있는 지 살펴보도록 하겠습니다. 파이어월, 방화벽은 네트워크로의 접근을 조절하게 됩니다. 접근의 형식과 구성을 바탕으로 접근을 허용허가나 불허합니다. 그리고 필터링 파이어월은 패킷과 패킷의 헤더 속성을 바탕으로 접근을 제어합니다. 회사는 방화벽을 설치하여 외부에서 특정 포트로 들어오는 메시지를 차단 할 수 있다 방화벽에는 네트워크 안으로 혹은 밖으로 전이되는 트래픽에 대한 접근 제어 매커니즘을 가지고 있습니다. 또한 들어온 패킷에 대해 분석하는 감리 매커니즘도 가지고 있습니다.
Virus scanner detect whether virus is in the mail Proxy Proxy Intermediate agent or server acting on behalf of endpoint without allowing a direct connection between the two endpoints Proxy Firewall Usually bases access control on content as well as source, destination addresses, etc Also called an applications level or application level firewall 프록시는 에이젼트나 서버의 중간물로써 연결의 두 점이 직접적으로 이어지지 않게 합니다. 프록시 파이어월은 프록시를 이용한 방화벽으로 패킷이나 메시지의 컨텐츠를 바탕으로 접근을 제어하고 있으며, 이를 어플리케이션 레벨의 방화벽이라고 합니다. Proxy firewall Desired recipient Mail arrives Virus scanner detect whether virus is in the mail
Outer Firewall Configuration(1) Goals Restrict public access to corporate network Restrict corporate access to Internet Required Public needs to send, receive email and access web services Outer firewall allows SMTP, HTTP, HTTPS Outer firewall uses its address for those of mail, web servers Attack analysis Web server ports Web server ports: proxy checks for invalid, illegal HTTP, HTTPS requests, rejects them Mail server port proxy checks email for invalid, illegal SMTP requests, rejects them Bypass low-level firewall checks by exploiting vulnerabilities in software, hardware Firewall designed to be as simple as possible Defense in depth 아우터 파이어월은 프록시를 기반으로 한 방화벽으로, 외부에서 내부로의 접근을 제한하고, 내부에서 인터넷으로의 접근을 제한하고 있습니다. 하지만 퍼블릭은 메일을 주고 받아야 하고, 웹 서비스로 접근이 가능해야합니다. 따라서 smtp, http, hhtps를 통한 접근은 허용해야하기 때문에, 아우터 파이어월은 메일과 웹 서비스를 위해 자신의 주소를 활용합니다. 웹 서버 포트 : 프록시가 유효하지 않거나 불법적인 http https 요청을 체크하고 거절하도록 합니다. 메일 서버 포트 : 프록시가 유효하지 않거나 불법적인 smtp 요청을 체크하고 거절합니다. 소프트웨어나 하드웨어 상의 취약점을 통한 로우레벨에서의 방화벽 우회를 막기 위해 방화벽은 되도록 단순하게 설계하는 방법과 계층 방어를 통해 피해를 줄인다. 계층 방어 공격을 몇 단계에 걸쳐서 방어하여 피해를 최소화 하는 것 물리보안(경비원, 도어락) – 보안 정책(무엇을 어떻게 보호할까?) – 네트워크(방화벽) – OS(백신) – 어플리케이션(프로그램내의 보안 로직) – 데이터(암호화)
Outer Firewall Configuration(2) DMZ mail server Only know firewall’s address Try to send a mail Virus, malicious logic check If only no, pass a mail to the DMZ mail server 모든 외부로부터의 패킷은 반드시 알려진 방화벽 주소로 우선 들어오게 하고 프록시로 해당 패킷을 검사한 뒤 서버에 전달할지, 거절할지 결정됩니다. Scan the message of a client Only know firewall’s address Try to contact a Web server DMZ Web Server Outer firewall
Inner Firewall Configuration Goals restrict access to corporate internal network Rule block all traffic except for that specifically authorized to enter Outer firewall DMZ Zone Prevent a NFS packet from going to internet Inner firewall Internal network (NFS information) 내부 방화벽에 대해 알아보겠습니다. 이는 회사의 most sensitive data 에 대한 접근 제한을 목표로 하는 것으로, 특별히 authorized된 트래픽을 제외한 모든 것을 막는 것을 규칙으로 합니다. 예를 들어 드립은 NFS(network file system)를 내부 시스템에서 활용하고 있는 데, 이는 내부에서만 사용되고 DMZ역시 이런 정보에 접근할 필요가 없기 때문에 외부 및 내부 방화벽은 이러한 nfs 패킷을 모두 불허하고 있습니다. 만약 내부 방화벽에서 이러한 패킷을 막는데 실패한다면 외부 방화벽에서는 데이터 패킷의 흐름을 일순 막거나 하는 식으로 방어를 할 수 있습니다. Unless hosts in the DMZ require NFS information, prevent a NFS packet from going to DMZ (least privilege)
추가
Next Generation FireWall, NGFW 기존 방화벽의 문제점 OSI Layer3,4 에만 관여 (IP주소, Port) HTTP, DNS, FTP, SMTP만 보호 가능 SNS, P2P, 메신저에 대한 보호는 어려움 트래픽 사용량을 확인하기 쉽지 않고, 이런 어플리케이션이 안전한지에 대한 여부를 일일이 식별하기 어려움 차세대 방화벽 Layer 7 에 관여하여 기존의 방화벽이 막을 수 없는 특정 애플리케이션 (토렌트, 네이트, 페이스북) 제어 가능 기존의 방화벽 기능 + 어플리케이션 인지 제어 기능을 추가 WEB2.0, 클라우딩, SaaS, 소셜 네트워크, 데이터 통합 등 현재 IT 패러다임에 급격한 변화에 대응할 수 있는 애플리케이션 제어와 가시성을 제공하는 차세대 방화벽이 요구됨
Palo Alto Network 애플리케이션, 콘텐츠, 사용자를 기반으로 보안 정책을 적용 차세대 방화벽 기능 App-ID User-ID Content-ID 차세대 방화벽 기능 인터넷 애플리케이션 식별/제어 가능 컨텐츠를 식별 가능 기업 내부로 유입되는 악성코드 및 네트워크 위협을 탐지/ 차단 가능 IP주소가 아닌 사용자를 식별함으로써 더 정교한 정책 수립 가능 인터넷 어플리케이션을 식별하고 제어 가능 (트위터나 페이스북 내용을 붙일 수는 있지만 글이나, 사진을 올릴수 없게 한다든가, 메신저로 대화는 하지만 파일 전송은 안되게 할 수 있다) 컨텐츠 식별 기능 (내부의 사용자가 파일 또는 메일로 개인 정보나 금융정보, 내부 정보를 유출하는 것을 차단한다) 기업 내부로 유입되는 악성코드 및 네트워크 위협을 기업의 관문에서 원칙적으로 탐지/차단 SNS나 P2P로 업/다운로드 되는 컨텐츠의 위험도를 분석 가능 IP주소가 아닌 사용자를 식별함으로써 더 정교한 정책 수립 가능
App-ID 포트가 아닌 어플리케이션에 따른 트래픽 분류 포트가 아닌 어플리케이션에 따른 트래픽 분류 트래픽은 첫번째로 IP주소와 포트 기반으로 분류 다음으로 어플리케이션을 식별하기 위해 서명이 앞에서 허용된 트래픽이 적용된다 만약 App-ID 암호화가 사용되고 있고 그 복호화 정책이 있다면, 어플리케이션은 복호화되고 어플리케이션 서명을 다시 체크 된다 프로토콜 분석이나, 서명분석으로 제대로 식별되지 않은 어플리케이션에 한해서는 휴리스틱한 식별 과정을 거친다 포트가 아닌 어플리케이션에 따른 트래픽 분류
User-ID -> 다양한 user의 정보가 user repository에 저장 보통 보안 정책은 ip주소를 기반으로 적용되어 왔다. 그러나 최근의 다이나믹한 유저 및 어플리케이션의 환경속에서 IP는 유저의 activity를 컨트롤하거나 모니터링 하기에 역부족 때문이 수많은 유저와 그룹을 보안정책에 함께 담고 유저 id를 기반으로 보안 정책 적용 다양한 유저의 user repository에 담긴다 유저 로그인을 하면 어떤 장치에서 로그인을 하든 일관적인 보안 정책을 적용하는 것이 가능 일단 어플리케이션과 유저가 식별되면 권한이 있는 유저에 한해 정책 변경, 로깅, 리포팅등의 모든 것이 가능해진다 <- 권한 있는 user에게 정책 변경, 로깅, 리포팅등의 기능 제공
Content-ID URL 데이터 베이스, 어플리케이션내의 허가되지 않은 데이터, 파일 전송 등을 사용하여 실시간 위협 요소들을 탐지 URL필터링 회사내의 고용자들의 웹 서핑을 감시, 통제 가능 파일 및 데이터 필터링 특정 타입에 대한 파일 블럭킹 민감한 데이터의 패턴(예를 들면 신용카드 정보) 필터링 파일을 전송하는 기능을 제어
Palo Alto Network 웹 방화벽 차세대 방화벽 Layer 7에 관여 사용자의 URL이 정상이고 사용자의 요청이 올바른지를 판별 기존 방화벽 위에 위치하여 HTTP, HTTPS에 특화된 기능 Layer 7 에 관여 네트워크상에 돌아다니는 패킷이 정상인지를 판별 기존의 방화벽의 기능을 포함하면서 모든 트래픽의 L7레벨을 확인하고 제어 IPS antivirus, url 필터링까지 하나의 정책에 일괄 적용 가능 기존 방화벽 위에 위치하여 http, https에 특화된 기능을 통해 해킹 방지, 차세대 방화벽은 기존의 방화벽의 기능을 포함하면서 모든 트래픽의 L7레벨을 확인하고 제어함 웹 http https에 특화 메소드값 설정, 임계치 설정하여 차단 차세대 방화벽은 어플리케이션을 제어하고, IPS antivirus, url 필터링까지 하나의 정책에 일괄 적용 가능 기존의 보안 제품을 완벽하게 대체 가능