적용 대상: .NET Core 2.1, .NET Core 3.1, .NET 5
이 문서에서는 Linux VM(가상 머신)을 보호하도록 로컬 방화벽을 구성하는 방법을 소개합니다.
필수 조건
자습서의 이 부분을 완료하기 위한 필수 구성 요소는 없습니다.
이 부분의 목표
방화벽을 구성하여 Linux VM을 보호하는 방법을 알아봅니다.
이 부분에 대한 필수 구성 요소는 없지만 이상적인 설정은 이전 부분의 지침을 따릅니다. 다음 항목이 있어야 합니다.
- Nginx가 자동으로 실행되고 포트 80에서 전송된 요청 수신 대기
- Nginx는 역방향 프록시로 구성되고 포트 5000에서 수신 대기하는 ASP.NET Core 애플리케이션으로 들어오는 요청을 라우팅합니다.
- 서버를 다시 시작한 후 또는 프로세스가 중지되거나 충돌할 때 자동으로 시작되도록 구성된 ASP.NET Core 애플리케이션
원격 컴퓨터의 액세스를 허용하도록 로컬 방화벽 구성
거의 모든 Linux 배포판에는 iptable이라는 로컬 방화벽이 포함됩니다. 이 초보자 가이드 는 빠른 시작을 위해 충분합니다. Iptables는 정책 체인을 사용하여 트래픽을 허용하거나 차단하는 가볍고 강력한 방화벽입니다.
Ubuntu 커뮤니티 도움말 페이지에 따르면 기본적으로 iptable은 모든 공식 Ubuntu 배포에 설치되며 모든 트래픽을 허용하도록 구성됩니다.
iptable은 경량 방화벽이지만 영구 규칙을 관리하는 것은 쉽지 않습니다. 다행히 Linux에서 방화벽 규칙을 구성하는 작업을 훨씬 쉽게 수행할 수 있는 몇 가지 방화벽 구성 도구가 있습니다. 공식 Ubuntu 방화벽 설명서에 따르면 Ubuntu의 기본 방화벽 구성 도구는 다음과 같습니다ufw. 이 도구는 iptables가 IPv4 또는 IPv6 호스트 기반 방화벽을 만드는 데 제공하는 것보다 사용자에게 더 친숙한 메서드를 제공합니다.
참고 항목
ufw 는 처음에 기본적으로 사용하지 않도록 설정됩니다. 따라서 사용할 수 있도록 설정해야 합니다.
이 자습서 전체에서 사용된 Linux VM은 방화벽 규칙으로 보호되지 않습니다. iptable이 설치되고 실행 중이지만 정의된 규칙이 없기 때문입니다.
여기서 목표는 HTTP 및 SSH(Secure Shell) 트래픽만 외부에서 VM에 도달하도록 허용하는 것입니다. 이렇게 하려면 다음 단계를 수행합니다.
- 사용하도록 설정
ufw하기 전에 기본 정책 규칙이 허용되도록 설정되어 있는지 확인합니다. 그렇지 않으면 VM에 대한 SSH 연결이 손실될 위험이 있습니다. 기본 규칙은 일치하는 다른 규칙이 없는 경우 처리되는 규칙입니다. 기본 "허용" 규칙을 사용하도록 설정하면 들어오는 SSH 트래픽이 차단되지 않습니다. 이 시점에서는 "거부" 규칙이 전혀 없습니다. 따라서 들어오는 모든 트래픽이 허용됩니다. -
Important
SSH 및 HTTP "허용" 규칙을 명시적으로 추가합니다. 또한 SSH 포트를 기본값인 22와 다른 값으로 구성한 경우 해당 포트를 허용해야 합니다. 예를 들어 SSH 포트를 2222로 변경한 경우 다음 명령을
sudo ufw allow 2222실행해야 합니다. - 기본 규칙을 "거부" 규칙으로 설정합니다. 이렇게 하면 프로토콜이 SSH 또는 HTTP와 다른 경우 기본 "거부" 규칙이 트래픽을 거부합니다. 예를 들어 들어오는 HTTP 트래픽이 거부됩니다.
- 를
ufw사용하도록 설정합니다.
이러한 단계에 대한 명령은 다음 스크린샷에 나열됩니다.
이 작업은 각 단계에서 발생합니다.
명령을 실행하여 ufw의 상태를 확인합니다
sudo ufw status verbose. 기본적으로 ufw는 사용하도록 설정되지 않으며 비활성 상태입니다.는 명령을 실행합니다
sudo ufw default allow. 기본 "허용" 규칙 이외의 다른 규칙은 없으므로 VM의 모든 포트는 열려 있는 것으로 간주됩니다.-
Important
명령을 실행하여 허용된 목록에 SSH 프로토콜을 추가합니다
sudo ufw allow ssh. Protocol.ssh 는 알려진 프로토콜이며 /etc/services 파일에 정의 됩니다 . 따라서 "ssh"는 "22" 대신 사용할 수 있습니다. 기본 포트 22가 아닌 다른 포트에서 수신 대기하도록 SSH 서비스를 구성하는 경우 다른 포트를 명시적으로 추가해야 합니다. 예를 들어 포트 2222를 수신 대기하도록 SSH를 구성하는 경우 다음 명령을sudo ufw allow 2222실행합니다. 를 실행
sudo ufw allow http하여 HTTP 프로토콜을 허용합니다. HTTP는 /etc/services 파일에 정의된 알려진 프로토콜입니다. 따라서 프로토콜 이름을 사용할 수 있으며sudo ufw allow http명령을 실행할 수 있습니다. 실행sudo ufw allow 80도 완벽하게 유효합니다.참고 항목
SSH 및 HTTP 프로토콜을 모두 허용한 후에는 다른 모든 프로토콜을 "거부" 목록에 추가하려고 합니다.
명령을 실행
sudo ufw default deny하여 거부하도록 기본 규칙을 변경하여 이 작업을 수행할 수 있습니다. SSH 및 HTTP 프로토콜만 허용됩니다. 다른 프로토콜은 거부됩니다.ufw사용
이 절차를 완료한 후의 sudo ufw status verbose 출력은 다음과 같습니다.
방화벽이 구성되면 작동 여부를 테스트합니다.
로컬 방화벽 테스트
방화벽을 쉽게 테스트합니다. HTTP 프로토콜에 대한 "거부" 규칙을 만든 다음 다른 컴퓨터에서 사이트에 액세스하려고 합니다. 요청을 차단해야 합니다.
이 "거부" 규칙을 만들기 전에 현재 구성에서 브라우저에서 애플리케이션에 액세스할 수 있는지 확인합니다. 이렇게 하려면 buggyamb 호스트 이름을 추가하고 Linux VM의 공용 IP 주소를 사용하여 클라이언트 컴퓨터에서 C:\Windows\System32\drivers\etc\hosts 파일을 편집합니다. buggyamb 호스트 이름은 Linux VM IP 주소를 확인합니다. 호스트 파일에 호스트 이름을 추가하거나 Linux VM의 공용 IP 주소에 직접 연결할 수 있습니다.
HTTP 요청이 VM에 도달할 수 있는지 확인한 후 HTTP 트래픽을 차단하는 규칙을 사용하도록 설정해 봅니다. 이렇게 하면 방화벽이 작동합니다. 이렇게 하려면 실행 sudo ufw deny http하여 HTTP에 대한 "거부" 규칙을 추가합니다. 이렇게 하면 HTTP 프로토콜에 대한 두 가지 "거부" 규칙이 추가됩니다(포트 80). 하나는 IPv4용이고, 다른 하나는 IPv6용입니다.
브라우저를 다시 연 다음 Linux에서 실행되는 ASP.NET Core 애플리케이션에 액세스합니다.
이 스크린샷은 예상 결과를 보여줍니다.
명령을 사용하여 Linux VM 내에서 직접 유사한 테스트를 실행할 수 있습니다 wget . 다음 스크린샷은 동일한 테스트를 실행 wget하여 필요한 단계를 보여줍니다.
이 작업은 각 단계에서 발생합니다.
HTTP 프로토콜에 대한 "거부" 규칙이 추가되었습니다.
명령이
wget buggyamb-external실행되었습니다. 짐작할 수 있듯이 "buggyamb-external" 호스트 이름은 Linux VM의 공용 IP 주소를 확인합니다. 이렇게 하려면 vi를/etc/hosts사용하여 파일을 편집합니다. 표시된 것처럼 연결wget하려고 했지만 성공하지 못했습니다. 작업을 중단하려면 Ctrl+C를 눌러야 했습니다.HTTP 프로토콜에 대한 "허용" 규칙이 추가되었습니다.
명령을 다시 실행하면
wget buggyamb-external다른 결과가 생성됩니다. 이번에는wgetHTTP 프로토콜이 허용되었기 때문에 연결할 수 있었습니다. 표시된wget것처럼 Index.html 파일을 현재 디렉터리에 다운로드합니다.
이제 ASP.NET Core 애플리케이션을 디버그하는 데 필요한 구성을 완료하는 데 한 걸음 더 가까워졌습니다. 다음 부분으로 이동하기 전에 로컬 방화벽에서 SSH와 HTTP가 모두 허용되는지 다시 확인합니다.
다음 단계
2.5부 - 개발 환경에서 Linux VM으로 파일을 복사한 다음 Linux에서 파일을 추출합니다.