ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [F5] SSLO 기능 테스트 (L2 Inline Service)
    Network 2023. 11. 10. 06:24
    728x90
    반응형

    F5 Networks 의 SSLO 솔루션을 사용하면
    SSL 가시화를 통해서 보안장비의 부하를 줄여 줄 수 있습니다.



    더불어 조건부 체인 설정을 통해서 유연한 트레픽 플로우를 설정 가능합니다.
    간단하게 사용 테스트를 해보도록 하겠습니다.


    SSLO 는 기존의 LTM 라이센스로는 이용 불가능하고 별도의 SSLO 라이센스를 사용해야 합니다.
    더불어 AVR 까지 켜주면 보다나은 대시보드를 이용가능합니다.



    최근 일부 공공 사업에서 NPB를 이용한 Inline 가시화 솔루션이 도입되고 있어
    L3 inline 모드로 SSLO 솔루션 테스트를 해보았습니다.


    테스트 구성은 SSLO 는 L3 모드로 Inline 구성
    서비스는 L2의 Inline 구성으로 진행하였습니다.

    SSLO 설정을 해주기 앞서 기본 네트워크 설정을 먼저 해주어야 하는데
    아래와 같이 VLAN, Self IP, Routing 설정 까지 먼저 해주었으며,
    서비스구간의 vlan은 사실 미리할 필요는 없으나 편의를 위해서 미리 해 두었습니다.



    #Vlan


    #Self IP


    #Routing



    SSLO 라이센스를 활성화 시키면
    SSL Orchestrator 라는 메뉴가 활성화 되며


    Configuration 메뉴로 진입하면 guide tool을 통해서 설정이 가능합니다.



    Config Guide 를 사용하면 
    Topology - SSL - Service - Serivce Chaining - Security Policy - Interception Rules - Egress - Log 순서로 편리하게 설정 하게 됩니다.

    1.Topology



    먼저 토폴로지 설정을 하게 되는데 여기서는 서비스 프로토콜 종류와
    네트웍 구성종류만 지정해 주면됩니다.
    저는 L3의 outbound 서비스를 골라서 테스트 진행하였습니다.

    2. SSL 설정

     

    SSLO 특성상 외부로 나가는 트레픽에 대해서 Forward Proxy 동작을 하게 되므로 SSL설정이 필요합니다.


    Forward Proxy 동작을 하기 위해 사용자에게 배포할 인증서를 설정해 주어야 하는데
    저는 미리 만들어 놓은 Astin 인증서를 사용해서 진행하였습니다.

     

     

    3. Service


    그 다음으론 서비스 설정을 하게 되는데
    다양한 보안장비들과 연동이 지원하고 있으니 솔루션에 맞는 것을 고르면 됩니다.



    저는 F5 장비를 Virtual Wire 로 물려서 진행할 예정이라 Generic Inline Layer2 서비스를 선택 하였습니다.




    여기서는 어떤 vlan으로 전달하고 어떤 vlan으로 전달 받을 것인지 선택해주고
    해당 서비스 모니터링 방식을 지정해 주면됩니다.
    (모니터는 LTM 메뉴에서 생성가능합니다.)

    4. Service Chain


    SSL 가시화 에서 어떤어떤 서비스를 태울것인지 chain을 지정하는 곳으로
    지금은 서비스를 1개만 등록 해놓았기때문에 1개를 선택해 주었습니다.

    5. Security Policy

     


    어떤 트레픽에 대해서 어떤 서비스 체인을 태울것인지 지정해주어야 됩니다.
    기본적으로 Pinners_rule이라는 바이패스 예외 url이 지정 되 어 있고
    그 외에 All Traffic 을 앞서 만든 서비스를 태워보겠습니다.

    6. Interception Rule


    트래픽 Ingress 를 지정하는 부분입니다.
    어느 vlan 에서 들어오는 트래픽을 대상으로 서비스 적용할지 지정하는곳입니다.
    Enablend vlan 설정이라 생각하면 될것 같습니다.

    7 . Egress


    가시화 서비스 구간을 지나고나서 트레픽을 외부로 보내는 구간에서 
    SNAT을 적용 할것인지 라우팅은 어떻게 하것인지 정하는 부분입니다.

    저는 테스트 환경이 사설IP 라서 Automap 을 통해서 테스트 진행하였습니다.
    추가적으로 상단 GW에서 외부로 나갈때 공인ip로 추가적인 SNAT 설정을 해두었습니다.

    8. Log


    로그 레벨을 지정하는 곳으로 별도의 변경없이 진행하였습니다.



    마지막으로 설정했던 내용을 검토하는 부분으로
    각 항목들을 눌러 내용 확인 수정이 가능합니다.
    Deploy 를 누르면 앞서 작성한 내용을 기반으로 설정이 만들어 집니다.


    Deploy 한 후 Services 란에 가면 현재 서비스 모니터링 상태가 표시가 되며
    세부 항목을 보면 설정한적이 없는 ipv4 와 ipv6로 구성되어 있는것이 보입니다.


    실제로 selfIP 로 가보면 Route Domain 을 사용해서
    ipv4 및 ipv6로 네트워크 설정이 자동으로 생성된것을 확인 할 수 있습니다.


    더불어 Virtual Server도 필요한 설정이 모두 자동으로 만들어지며,
    (빨간색은 가시화 처리가 필요없는 UDP 와 그외 트래픽을 bypass하기 위해 별도로 만들었습니다.)

     

    irule 까지도 자동 생성되어 적용되어 있음을 확인 가능합니다.


    기존에는 수동으로 구성을 짜서 힘들게 만들던 설정들이
    이제 SSLO의 컨피그 가이드를 통해서 자동으로 만들어 주어 훨씬 편리해 졌습니다.

    이제 테스트를 위해서 앞서 만들어 놓은 인증서를 클라이언트에 설치하고 테스트를 진행해 보겠습니다.


     저는 테스트를 위해 Astin 이라는 이름의 인증서를 4K 로 사전에 만들어 적용 하였고
    이를 export 하여 사용자 PC에 설치 진행 하였습니다.

    실제로 정상동작하는지 네이버, 카카오 페이지에 접속 테스트 해보았습니다.


    네이버와 카카오 홈페이지가 정상적으로 접속되었고
    발급자가 Astin_LAB으로 정상적인 Forward Proxy 동작을 하고있음을 확인하였습니다.

    더불어 AirGap 에서 패킷을 확인해보면 SSL을 정상적으로 가시화 처리 했음도 확인하였습니다.


    이제 예외처리기능을 한번 확인해 보겠습니다.


    저는 차단리스트를 테스트 해보기 위해서
    SSL Orchestrator - Policies - URL Categories
    메뉴 에서 Deny 라는 카테고리를 생성하였고 (네이버 주소 차단)
    Secure Policy 에서 Deny_URL 이라는 이름으로 Deny를 Reject 하라는 정책을 추가 하였습니다.


    이 후 테스트 해보면 네이버로 접속할 경우
    차단페이지가 나옴을 확인 할 수 있습니다.



    ASM솔루션에서는 차단페이지에서 Support ID 를 제공하였지만
    SSLO에서는 어떤 카테고리에 의해서 차단되었는지 표시해줌을 확인 할 수 있었습니다.
    따라서 카테고리 이름을 지을때도 신중해야겠단 생각이 드네요.

     


    대시보드에 들어가보면 카테고리별 hit량이 나오며, 어떤 암호화 알고리즘으로 네고되었는지도 확인 가능합니다.
    이번에는 Service Chain 을 늘려서 장애시 동작에 대해서 알아보겠습니다.


    앞서와 동일한 방법으로 새로운 VLAN으로
     Generic L2 서비스를 하나더 추가 하고


    Service Chain에서 두번째에 추가해보았습니다.


    그림에서도 느껴지듯이 2개의 체인이 적용되었음을 확인이 가능했고

     

    Policy 메뉴에서 살펴보면 서비스 플로우에서 Chain 에서 2개의 서비스가 적용되어 있음이 확인가능합니다.
    ( Policy 에서 수동으로 추가 동작을 설정해보려 하였으나 막혀 있는거 같습니다.)


    이제 두번째 서비스를 Down 시켜 보면 설정한 모니터에 의해서
    서비스 2번이 Down 되었음이 확인 가능합니다.





    이때의 서비스 동작을 확인해 보면


    서비스는 정상적으로 동작하며,


    첫번째 서비스인 2.1인터페이스로는 정상적으로 트레픽이 확인되지만


    다운된 서비스가 있는 1.3 인터페이스로는 트레픽이 확인되지 않았음을 확인하였습니다.

    즉, 설정한 모니터링에 의해서 서비스가 down 되면 서비스 Chain 에서 해당 서비스는 제외하고 트레픽 처리를 합니다.

    내용이 길어져서 SSLO에서 Mirror 테스트는 따로 작성하도록 하겠습니다.

    아래의 링크에서 확인해 주세요.

    728x90
    반응형
Designed by Tistory.