Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

예를 들면 다음과 같습니다. Telnet 및 SSH 액세스를 차단하기 위한 필터 구성

요구 사항

공유 네트워크 링크가 Junos OS 실행되는 2대의 디바이스. 이 예제를 구성하기 전에 기본 장비 초기화(관리 인터페이스, 원격 액세스, 사용자 로그인 계정 등)를 넘어서는 특별한 구성이 필요하지 않습니다. 엄격한 요구 사항은 아니지만 R2 장비에 대한 콘솔 액세스가 권장됩니다.

주:

콘텐츠 테스트 팀은 이 예시를 검증하고 업데이트했습니다.

개요 및 토폴로지

이 예에서는 패킷이 192.168.1.0/24 서브넷에서 보낸 경우를 라우팅 엔진 로컬 패킷에 전송된 Telnet 또는 SSH 패킷을 기록하고 거부하는 IPv4 스테이트리스 방화벽 필터를 생성합니다. 필터는 루프백 인터페이스에 적용되어 로컬 장비로 연결되는 트래픽만이 영향을 하도록 보장합니다. 입력 방향으로 필터를 적용합니다. 출력 필터는 사용되지 않습니다. 그 결과, 로컬에서 생성된 모든 트래픽이 허용됩니다.

  • 특정 서브넷 또는 IP Prefix에서 시작된 패킷을 일치하기 위해 입력 방향에 적용된 source-address IPv4 일치 조건을 사용하게 됩니다.

  • Telnet 포트 및 SSH 포트로 전달되는 패킷을 일치하기 위해 입력 방향에 적용된 IPv4 일치 조건과 결합된 일치 조건을 protocol tcpport telnetport ssh 사용하게 됩니다.

토폴로지 예

그림 1 이 예제에 대한 테스트 토폴로지가 표시됩니다. 방화벽 필터가 R2 장비에 적용되어 테스트(DUT) 중입니다. R1 및 R2 장비는 192.168.1.0/24의 서브넷에 할당된 링크를 공유합니다. 두 장비 모두 /32 서브넷 마스크를 사용하여 192.168.255.0/24 Prefix에서 루프백 주소를 할당합니다. 정적 경로는 이 기본 예제에서 내부 게이트웨이 프로토콜이 구성되지 않은 경우 루프백 주소 간의 연결성을 제공합니다.

그림 1: 토폴로지 예토폴로지 예

구성

다음 예제에서는 구성 계층의 다양한 수준을 탐색해야 합니다. 네트워크의 네트워크 CLI 대한 자세한 내용은 configuration mode에서 CLI Editor 사용 을 참조하십시오.

경고:

샘플 필터는 R1의 공유 서브넷에서 시작되지 않는 한 Telnet 및 SSH 액세스를 R2로 제한합니다. SSH 또는 Telnet을 사용하여 R2 장비에 직접 액세스하면 필터가 적용될 때 연결이 끊어지게 됩니다. 이 예제를 구성할 때 콘솔 액세스 권한을 가지는 것이 좋습니다. 필요한 경우 R1 디바이스를 점프 호스트로 사용하여 필터를 적용한 후 SSH 세션을 R2로 시작할 수 있습니다. 또는 R2 장비에 액세스하는 데 사용하는 머신에 할당된 IP 서브넷을 허용하도록 샘플 필터를 수정하는 것이 고려됩니다.

다음 작업을 수행하여 다음 예제를 구성합니다.

CLI 빠른 구성

R1 장비에 대한 빠른 구성

R1 디바이스가 필요 시 다음 명령을 신속하게 구성하고 계층 수준에서 CLI 디바이스에 [edit] 붙여넣기 할 수 있습니다. 구성 모드에서 변경을 commit 활성화하려면 반드시 발행해야 합니다.

R2 장비에 대한 빠른 구성

R2 디바이스가 필요 시 다음 명령을 신속하게 구성하고 계층 수준에서 CLI 디바이스에 [edit] 붙여넣기 할 수 있습니다. 구성 모드에서 변경을 commit 활성화하려면 반드시 발행해야 합니다.

팁:

디바이스에 대한 원격 액세스에 영향을 미칠 수 있는 commit-confirmed 변경 시 사용할 것을 고려합니다. 활성화를 통해 Junos OS 확인 필요 자세한 내용을 확인하시기 바랍니다.

R1 디바이스 구성

단계별 절차

다음 단계를 따라 R1 디바이스를 구성합니다.

  1. 인터페이스 구성:

  2. R2 장치의 루프백 주소로 호스트 이름과 정적 경로를 구성합니다. 또한 Telnet 및 SSH 액세스를 구성합니다.

R1 디바이스에서 구성 확인 및 커밋

단계별 절차

아래 단계를 따라 R1 장치에서 지원자 구성을 확인하고 커밋합니다.

  1. 구성 모드 명령으로 인터페이스 show interfaces 구성을 확인 명령 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 명령을 반복하여 구성을 수정합니다.

  2. R2 장치의 루프백 주소에 도달하는 데 사용되는 정적 경로와 SSH 및 Telnet 액세스가 활성화되어 있는지 검증합니다. 및 show routing-optionsshow system services 구성 모드 명령을 사용 합니다. 명령 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 명령을 반복하여 구성을 수정합니다.

  3. R1 디바이스의 구성에 만족하면 후보 구성을 커밋합니다.

R2 디바이스 구성

단계별 절차

아래 단계를 따라 R2 디바이스를 구성합니다. 먼저 Telnet 및 SSH 액세스를 선택적으로 차단하는 스테이트리스 방화벽 필터를 정의하는 것으로 시작됩니다.

  1. 다음 edit firewall family inet filter 계층에서 local_acl 포지션:

  2. 에서 필터 용어를 terminal_access. 이 용어는 지정된 소스 prefix에서 Telnet 및 SSH를 허용합니다.

  3. 에서 필터 용어를 terminal_access_denied. 이 용어는 다른 모든 소스 주소에서 SSH 및 Telnet을 거부합니다. 이 용어는 용어와 일치하는 로그를 기록하고 패킷 소스에 대한 명시적인 ICMP(Internet Control Message Protocol) 대상에 대한 응답을 생성하도록 구성됩니다. 필터 로깅 옵션에 대한 자세한 내용은 방화벽 필터 로깅 작업을 참조하세요.

    팁:

    해당 조치를 사용하여 소스로 다시 ICMP 오류 메시지 생성을 discard 억제할 수 있습니다. 자세한 내용은 방화벽 필터 종료 작업을 참조하십시오.

  4. 필터 용어 기본 용어를 정의합니다. 이 용어는 다른 모든 트래픽을 허용합니다. 스테이트리스 필터를 Junos OS 종료 시 암시적 거부 용어가 있습니다. 기본 용어는 명시적 수락 작업으로 필터를 종료하여 이 동작을 까다로워 합니다. 그 결과, 파일러가 허용하는 다른 모든 트래픽이 접수됩니다.

  5. 루프백 인터페이스를 구성하고 필터를 입력 방향에 적용합니다.

  6. 호스트 이름, ge-0/0/0 인터페이스, R1 장치의 루프백 주소에 대한 정적 경로 구성하고 SSH 및 Telnet을 통해 원격 액세스를 지원:

디바이스 R2에서 구성 확인 및 커밋

단계별 절차

아래 단계를 따라 R2 장치에서 지원자 구성을 확인하고 커밋합니다.

  1. 구성 모드 명령으로 스테이트리스 방화벽 필터의 show firewall 구성을 확인합니다. 명령 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 명령을 반복하여 구성을 수정합니다.

  2. 구성 모드 명령으로 인터페이스 구성 및 필터 show interfaces 애플리케이션을 확인 명령 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 명령을 반복하여 구성을 수정합니다.

  3. R1 장비의 루프백 주소에 도달하는 데 사용되는 정적 경로와 Telnet 및 SSH 액세스가 활성화되어 있는지 검증합니다. 및 show routing-optionsshow system services 구성 모드 명령을 사용 합니다. 명령 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 명령을 반복하여 구성을 수정합니다.

  4. R2 디바이스의 구성에 만족하면 후보 구성을 커밋합니다.

    팁:

    디바이스에 대한 원격 액세스에 영향을 미칠 수 있는 commit-confirmed 변경 시 사용할 것을 고려합니다. 활성화를 통해 Junos OS 확인 필요 자세한 내용을 확인하시기 바랍니다.

스테이트리스 방화벽 필터 검증

Telnet 및 SSH 액세스를 제한하는 방화벽 필터가 제대로 작동하고 있는지 확인합니다.

승인된 패킷 확인

목적

트래픽이 192.168.1.0/24 서브넷에서 소스되면 방화벽 필터가 SSH 및 Telnet을 올바르게 허용하는지 확인합니다.

실행

  1. 라우터 또는 스위치의 방화벽 로그를 지우기.

  2. 192.168.1.0/24 서브넷 내의 IP 주소의 호스트에서 명령을 사용하여 허용된 소스 주소에서 ssh 192.168.255.2 SSH를 사용하여 장비에 로그인할 수 있는지 확인합니다. 이 패킷은 수락해야 합니다. 이 패킷에 대한 패킷 헤더 정보는 해당 패킷의 방화벽 필터 로그 버퍼에 패킷 전달 엔진. 이 디바이스 간의 사용자로 첫 번째 SSH 로그인인 경우 SSH 호스트 키를 저장하라는 메시지가 표시될 것입니다.

    주:

    기본적으로 R1 장치는 대상에 도달하는 데 사용되는 egress 인터페이스에서 SSH 트래픽을 소스화합니다. 그 결과, 이 트래픽은 R1 장치의 ge-0/0/0 인터페이스에 할당된 192.168.1.1 주소에서 발신됩니다.

  3. R2 디바이스에서 CLI 로그아웃하여 SSH 세션을 닫습니다.

  4. 192.168.1.0/24 서브넷 내의 IP 주소의 호스트에서 명령을 사용하여 허용된 소스 주소에서 telnet 192.168.255.2 Telnet을 사용하여 라우터 또는 스위치에 로그인할 수 있는지 확인합니다. 이 패킷은 수락해야 합니다. 이 패킷에 대한 패킷 헤더 정보는 해당 패킷의 방화벽 필터 로그 버퍼에 패킷 전달 엔진.

  5. Telnet CLI 로그아웃하여 R2 장비에 닫습니다.

  6. 이 명령을 사용하여 R2 장비의 PFE(패킷 전달 엔진)의 방화벽 로그 버퍼가 show firewall log 192.168.1.0/24 서브넷의 소스 주소가 있는 엔트리가 없는지 확인합니다.

로깅 및 거부된 패킷 검증

목적

방화벽 필터가 192.168.1.0/24 서브넷에서 시작되지 않은 SSH 및 Telnet 트래픽을 올바르게 거부하는지 확인합니다.

실행

  1. 라우터 또는 스위치의 방화벽 로그를 지우기.

  2. R1 장치의 루프백 주소에서 소스된 SSH 트래픽을 생성합니다. 이 트래픽의 소스 주소는 허용된 192.168.1.0/24 서브넷 외부에 있습니다. 이 명령을 사용하여 이 소스 주소에서 SSH를 사용하여 장비에 로그인할 ssh 192.168.255.2 source 192.168.255.1 수 없는지 확인합니다. 이 패킷은 거부되어 패킷 헤더 정보는 방화벽 필터 로그 버퍼에 로깅됩니다.

    출력은 SSH 연결이 거부된 경우를 보여줍니다. 이를 통해 필터가 ICMP 오류 메시지를 생성하고, 수신되지 않는 소스 주소에서 전송될 때 SSH 트래픽을 올바르게 차단하는지 확인합니다.

  3. R1 장비의 루프백 주소에서 소스된 Telnet 트래픽을 생성합니다. 이 트래픽의 소스 주소는 허용된 192.168.1.0/24 서브넷 외부에 있습니다. 이 명령을 사용하여 이 소스 주소에서 Telnet을 사용하여 장비에 로그인할 telnet 192.168.255.2 source 192.168.255.1 수 없는지 확인합니다. 이 패킷은 거부됩니다. 그리고 이 패킷에 대한 패킷 헤더 정보는 PFE의 방화벽 필터 로그 버퍼에 로깅됩니다.

    출력은 Telnet 연결이 거부된 경우를 보여줍니다. 이를 통해 필터가 ICMP 오류 메시지를 생성하고, 수신되지 않는 소스 주소에서 전송될 때 Telnet 트래픽을 올바르게 차단하는지 확인합니다.

  4. 이 명령을 사용하여 R2 장치의 방화벽 로그 버퍼가 192.168.255.1의 소스 주소가 있는 패킷을 보여주는 엔트리가 포함되어 있는지 show firewall log 확인합니다.

    출력을 통해 192.168.255.1 소스 주소의 트래픽이 필터의 기본 용어와 terminal_access_denied 확인됩니다. 열은 이러한 패킷이 거부된 것을 나타내는 ActionR 를 나타냅니다. 인터페이스, 전송 프로토콜, 소스 및 대상 주소도 나열됩니다. 이러한 결과를 통해 방화벽 필터가 이 예에서 제대로 작동하고 있는지 확인할 수 있습니다.