웹사이트 검색

서버를 보호하기 위해 권장되는 보안 조치

소개

대부분의 경우 클라우드 애플리케이션을 시작하고 실행하는 데 중점을 둡니다. 설정 및 배포 프로세스의 일부로 시스템 및 응용 프로그램이 공개되기 전에 강력하고 철저한 보안 조치를 구축하는 것이 중요합니다. 애플리케이션을 배포하기 전에 이 자습서의 보안 조치를 구현하면 배포 후 구현될 수 있는 임시 조치와 달리 인프라에서 실행하는 모든 소프트웨어에 보안 기본 구성이 있는지 확인할 수 있습니다.

이 가이드는 서버 인프라를 구성하고 설정하는 동안 취할 수 있는 몇 가지 실용적인 보안 조치를 강조합니다. 이 목록은 서버 보안을 위해 수행할 수 있는 모든 작업의 전체 목록은 아니지만 구축할 수 있는 시작점을 제공합니다. 시간이 지남에 따라 환경 및 애플리케이션의 특정 요구 사항에 맞는 보다 맞춤화된 보안 접근 방식을 개발할 수 있습니다.

SSH 키

SSH 또는 보안 셸은 서버를 관리하고 서버와 통신하는 데 사용되는 암호화된 프로토콜입니다. 서버 작업을 할 때 SSH를 통해 서버에 연결된 터미널 세션에서 대부분의 시간을 보내게 될 것입니다. 암호 기반 로그인의 대안으로 SSH 키는 암호화를 사용하여 서버에 안전하게 로그인하는 방법을 제공하며 모든 사용자에게 권장됩니다.

SSH 키를 사용하면 인증을 위해 개인 및 공개 키 쌍이 생성됩니다. 개인 키는 사용자가 비밀로 유지하고 안전하게 유지하는 반면 공개 키는 공유할 수 있습니다. 이것은 일반적으로 다른 곳에서 볼 수 있는 패턴인 비대칭 암호화라고 합니다.

SSH 키 인증을 구성하려면 서버의 예상 위치(일반적으로 ~/.ssh/authorized_keys)에 공개 SSH 키를 넣어야 합니다. SSH 키 기반 인증 작동 방식에 대해 자세히 알아보려면 SSH 암호화 및 연결 프로세스 이해를 참조하십시오.

SSH 키는 어떻게 보안을 강화합니까?

SSH를 사용하면 암호 인증을 포함한 모든 종류의 인증이 완전히 암호화됩니다. 그러나 암호 기반 로그인이 허용되면 악의적인 사용자는 특히 공용 IP 주소가 있는 경우 반복적으로 자동으로 서버에 액세스를 시도할 수 있습니다. 동일한 IP에서 여러 번의 시도 실패 후 액세스를 잠그는 방법이 있지만 악의적인 사용자는 서버에 얼마나 빨리 로그인을 시도할 수 있는지에 따라 실제로 제한됩니다. 사용자가 그럴듯하게 액세스를 시도할 수 있는 모든 상황 반복적인 무차별 대입 공격으로 스택에 보안 위험이 발생할 수 있습니다.

SSH 키 인증을 설정하면 암호 기반 인증을 비활성화할 수 있습니다. SSH 키는 일반적으로 암호보다 더 많은 데이터 비트를 가지고 있습니다. 12자 암호에서 128자 SSH 키 해시를 생성할 수 있으므로 무차별 대입이 훨씬 더 어렵습니다. 그럼에도 불구하고 일부 암호화 알고리즘은 충분히 강력한 컴퓨터에서 암호 해시를 충분히 리버스 엔지니어링하려고 시도함으로써 크랙 가능한 것으로 간주됩니다. 최신 SSH 클라이언트에서 생성된 기본 RSA 키를 비롯한 다른 키는 아직 크랙할 가능성이 없습니다.

SSH 키 구현 방법

SSH 키는 모든 Linux 서버 환경에 원격으로 로그인하는 데 권장되는 방법입니다. ssh 명령을 사용하여 로컬 시스템에서 한 쌍의 SSH 키를 생성한 다음 공개 키를 원격 서버로 전송할 수 있습니다.

서버에서 SSH 키를 설정하려면 Ubuntu, Debian 또는 CentOS용 SSH 키 설정 방법을 따르십시오.

암호 액세스가 필요하거나 무차별 대입 공격을 받기 쉬운 스택의 모든 부분에 대해 서버에서 fail2ban과 같은 솔루션을 구현하여 암호 추측을 제한할 수 있습니다.

root 사용자가 SSH를 통해 직접 로그인하도록 허용하지 않는 것이 가장 좋습니다. 대신 권한이 없는 사용자로 로그인한 다음 필요에 따라 최소 권한 원칙에 따라 권한을 에스컬레이션하십시오. 서버에 연결하고 SSH로 작동하는 것으로 확인된 권한 없는 계정을 만든 후에는 /에서 PermitRootLogin no 지시문을 설정하여 루트 로그인을 비활성화할 수 있습니다. etc/ssh/sshd_config를 서버에 설치한 다음 sudo systemctl restart sshd와 같은 명령으로 서버의 SSH 프로세스를 다시 시작합니다.

방화벽

방화벽은 서비스가 네트워크에 노출되는 방식과 지정된 서버에서 들어오고 나가는 트래픽 유형을 제어하는 소프트웨어 또는 하드웨어 장치입니다. 적절하게 구성된 방화벽은 공개적으로 사용 가능한 서비스만 서버 또는 네트워크 외부에서 도달할 수 있도록 합니다.

일반적인 서버에서는 여러 서비스가 기본적으로 실행될 수 있습니다. 이들은 다음과 같은 그룹으로 분류할 수 있습니다.

  • 인터넷에서 누구나 종종 익명으로 액세스할 수 있는 공공 서비스입니다. 이에 대한 예는 실제 웹사이트를 제공하는 웹 서버입니다.
  • 승인된 계정의 선택된 그룹 또는 특정 위치에서만 액세스해야 하는 개인 서비스. 예를 들어 phpMyAdmin과 같은 데이터베이스 제어판입니다.
  • 공개 인터넷에 서비스를 노출하지 않고 서버 자체 내에서만 액세스할 수 있어야 하는 내부 서비스. 예를 들어 로컬 연결만 수락해야 하는 데이터베이스입니다.

방화벽은 소프트웨어에 대한 액세스가 다양한 세분화 수준으로 위의 범주에 따라 제한되도록 할 수 있습니다. 공용 서비스는 개방된 상태로 두고 인터넷에서 사용할 수 있으며 개인 서비스는 연결 유형과 같은 다양한 기준에 따라 제한될 수 있습니다. 내부 서비스는 인터넷에 완전히 액세스할 수 없도록 만들 수 있습니다. 사용하지 않는 포트의 경우 대부분의 구성에서 액세스가 완전히 차단됩니다.

방화벽은 어떻게 보안을 강화합니까?

서비스가 보안 기능을 구현하거나 서비스를 실행하려는 인터페이스로 제한되는 경우에도 방화벽은 애플리케이션에서 트래픽을 처리하기 전에 서비스와의 연결을 제한하여 보호의 기본 계층 역할을 합니다.

적절하게 구성된 방화벽은 일반적으로 해당 서비스와 연결된 포트만 열어 개방 상태를 유지해야 하는 특정 서비스를 제외한 모든 것에 대한 액세스를 제한합니다. 예를 들어 SSH는 일반적으로 포트 22에서 실행되고 웹 브라우저를 통한 HTTP/HTTPS 액세스는 일반적으로 각각 포트 80 및 443에서 실행됩니다. 일부 소프트웨어만 노출하면 서버의 공격 표면이 줄어들어 악용에 취약한 구성 요소가 제한됩니다.

방화벽 구현 방법

Linux 시스템에 사용할 수 있는 많은 방화벽이 있으며 일부는 다른 것보다 더 복잡합니다. 일반적으로 서버에서 실행 중인 서비스를 변경할 때만 방화벽 구성을 변경하면 됩니다. 시작하고 실행할 수 있는 몇 가지 옵션은 다음과 같습니다.

  • UFW(복잡하지 않은 방화벽)는 Ubuntu와 같은 일부 Linux 배포판에 기본적으로 설치됩니다. Ubuntu 20.04에서 UFW로 방화벽을 설정하는 방법에서 자세히 알아볼 수 있습니다.\n
  • Red Hat, Rocky 또는 Fedora Linux를 사용하는 경우 firewalld를 사용하여 방화벽을 설정하는 방법을 읽어 기본 도구를 사용할 수 있습니다.\n
  • UFW 및 firewalld와 같은 많은 소프트웨어 방화벽은 구성된 규칙을 iptables라는 파일에 직접 기록합니다. iptables 구성으로 직접 작업하는 방법을 알아보려면 Iptables Essentials: Common Firewall Rules and Commands를 검토할 수 있습니다.\n. Docker와 같이 자체적으로 포트 규칙을 구현하는 일부 다른 소프트웨어도 iptables에 직접 작성하고 UFW로 만든 규칙과 충돌할 수 있으므로 읽는 방법을 아는 것이 도움이 됩니다. 이와 같은 경우 iptables 구성.

참고: DigitalOcean을 포함한 많은 호스팅 공급자는 방화벽을 직접 구현하지 않고 클라우드 서버에서 외부 계층으로 실행되는 서비스로 방화벽을 구성할 수 있도록 합니다. 관리 도구를 사용하여 네트워크 에지에서 구현되는 이러한 구성은 실제로는 덜 복잡하지만 스크립팅 및 복제가 더 어려울 수 있습니다. DigitalOcean의 설명서를 참조할 수 있습니다.

방화벽 구성이 알 수 없는 트래픽을 차단하도록 기본 설정되어 있는지 확인하십시오. 이렇게 하면 배포하는 모든 새 서비스가 실수로 인터넷에 노출되지 않습니다. 대신 액세스를 명시적으로 허용해야 서비스 실행, 액세스 방법 및 서비스를 사용할 수 있는 사람을 평가해야 합니다.

VPC 네트워크

Virtual Private Cloud(VPC) 네트워크는 인프라 리소스를 위한 사설 네트워크입니다. VPC 네트워크는 공용 인터넷에서 네트워크 인터페이스에 액세스할 수 없기 때문에 리소스 간에 보다 안전한 연결을 제공합니다.

VPC 네트워크는 어떻게 보안을 강화합니까?

일부 호스팅 공급자는 기본적으로 클라우드 서버에 하나의 공용 네트워크 인터페이스와 하나의 개인 네트워크 인터페이스를 할당합니다. 인프라의 일부에서 공용 네트워크 인터페이스를 비활성화하면 이러한 인스턴스가 내부 네트워크를 통해 사설 네트워크 인터페이스를 사용하여 서로 연결할 수만 허용됩니다. 즉, 시스템 간의 트래픽이 공용 인터넷을 통해 라우팅되지 않습니다. 노출되거나 차단됩니다.

VPC 네트워크의 리소스와 공용 인터넷 간의 유일한 액세스 지점으로 인그레스 게이트웨이라고도 하는 몇 개의 전용 인터넷 게이트웨이만 조건부로 노출하면 공용 트래픽을 더 잘 제어하고 볼 수 있습니다. 리소스에 연결합니다. Kubernetes와 같은 최신 컨테이너 오케스트레이션 시스템은 기본적으로 선택적으로 노출되어야 하는 많은 사설 네트워크 인터페이스를 생성하기 때문에 매우 잘 정의된 수신 게이트웨이 개념을 가지고 있습니다.

VPC 네트워크 구현 방법

많은 클라우드 인프라 제공업체를 사용하면 데이터 센터 내부의 VPC 네트워크에 리소스를 생성하고 추가할 수 있습니다.

참고: DigitalOcean을 사용 중이고 자체 VPC 게이트웨이를 설정하려는 경우 드롭릿을 VPC 게이트웨이로 구성하는 방법 가이드에 따라 Debian, Ubuntu 및 CentOS 기반 서버에서 방법을 배울 수 있습니다.

개인 네트워크를 수동으로 구성하려면 고급 서버 구성 및 네트워킹 지식이 필요할 수 있습니다. VPC 네트워크 설정의 대안은 서버 간에 VPN 연결을 사용하는 것입니다.

VPN 및 개인 네트워킹

VPN 또는 가상 사설망은 원격 컴퓨터 간에 보안 연결을 생성하고 마치 로컬 사설망인 것처럼 연결을 제공하는 방법입니다. 이렇게 하면 사설 네트워크에 있는 것처럼 서비스를 구성하고 보안 연결을 통해 원격 서버에 연결할 수 있습니다.

예를 들어, DigitalOcean 사설 네트워크는 동일한 지역 내에서 동일한 계정 또는 팀의 서버 간에 격리된 통신을 가능하게 합니다.

VPN은 어떻게 보안을 강화합니까?

VPN을 사용하면 서버만 볼 수 있는 사설 네트워크를 매핑할 수 있습니다. 통신은 완전히 비공개이며 안전합니다. VPN 소프트웨어가 노출하는 가상 인터페이스를 통해 트래픽을 전달하도록 다른 애플리케이션을 구성할 수 있습니다. 이렇게 하면 공용 인터넷에서 클라이언트가 사용하도록 되어 있는 서비스만 공용 네트워크에 노출되어야 합니다.

VPN 구현 방법

사설 네트워크를 사용하려면 일반적으로 서버를 처음 배포하고 이러한 인터페이스를 선호하도록 애플리케이션 및 방화벽을 구성할 때 네트워크 인터페이스에 대한 결정을 내려야 합니다. 이에 비해 VPN을 배포하려면 추가 도구를 설치하고 추가 네트워크 경로를 생성해야 하지만 일반적으로 기존 아키텍처 위에 배포할 수 있습니다. VPN의 각 서버에는 VPN 연결을 설정하는 데 필요한 공유 보안 및 구성 데이터가 있어야 합니다. VPN이 실행되고 나면 VPN 터널을 사용하도록 애플리케이션을 구성해야 합니다.

Ubuntu 또는 CentOS를 사용하는 경우 Ubuntu 20.04에서 OpenVPN 서버를 설정 및 구성하는 방법을 따를 수 있습니다.

와이어가드

서비스 감사

우수한 보안에는 시스템 분석, 사용 가능한 공격 영역 이해, 구성 요소를 최대한 잠그는 작업이 포함됩니다.

서비스 감사는 주어진 시스템에서 실행 중인 서비스, 통신에 사용하는 포트, 해당 서비스가 말하는 프로토콜을 파악하는 방법입니다. 이 정보는 공개적으로 액세스할 수 있는 서비스, 방화벽 설정, 모니터링 및 경고를 구성하는 데 도움이 될 수 있습니다.

서비스 감사는 어떻게 보안을 강화합니까?

실행 중인 각 서비스는 내부용이든 공개용이든 악의적인 사용자를 위한 확장된 공격 표면을 나타냅니다. 실행 중인 서비스가 많을수록 취약성이 소프트웨어에 영향을 미칠 가능성이 커집니다.

시스템에서 어떤 네트워크 서비스가 실행되고 있는지 잘 알고 있으면 이러한 서비스 분석을 시작할 수 있습니다. 서비스 감사를 수행할 때 실행 중인 각 서비스에 대해 다음과 같은 질문을 하십시오.

  • 이 서비스를 실행해야 합니까?
  • 서비스가 실행되어서는 안 되는 네트워크 인터페이스에서 실행되고 있습니까?
  • 서비스가 공용 또는 개인 네트워크 인터페이스에 바인딩되어야 합니까?
  • 내 방화벽 규칙이 합법적인 트래픽을 이 서비스로 전달하도록 구성되어 있습니까?
  • 내 방화벽 규칙이 합법적이지 않은 트래픽을 차단하고 있습니까?
  • 각 서비스의 취약점에 대한 보안 경고를 받을 수 있는 방법이 있습니까?

이러한 유형의 서비스 감사는 인프라에서 새 서버를 구성할 때 표준 관행이어야 합니다. 몇 달마다 서비스 감사를 수행하면 의도치 않게 변경되었을 수 있는 구성이 있는 서비스를 파악하는 데에도 도움이 됩니다.

서비스 감사 구현 방법

시스템에서 실행 중인 네트워크 서비스를 감사하려면 ss 명령을 사용하여 서버에서 사용 중인 모든 TCP 및 UDP 포트를 나열하십시오. TCP 및 UDP 트래픽을 수신하는 데 사용되는 프로그램 이름, PID 및 주소를 보여주는 예제 명령은 다음과 같습니다.

  1. sudo ss -plunt

p, l, u, n 및 t 옵션은 다음과 같이 작동합니다. :

  • p는 주어진 소켓을 사용하는 특정 프로세스를 보여줍니다.
  • l은 연결을 적극적으로 수신하는 소켓만 표시합니다.
  • u에는 TCP 소켓 외에 UDP 소켓이 포함됩니다.
  • n은 숫자 트래픽 값을 표시합니다.
  • t에는 UDP 소켓 외에 TCP 소켓이 포함됩니다.

다음과 유사한 출력이 표시됩니다.

Output
Netid       State        Recv-Q       Send-Q             Local Address:Port             Peer Address:Port      Process
tcp         LISTEN       0            128                      0.0.0.0:22                    0.0.0.0:*         users:(("sshd",pid=812,fd=3))
tcp         LISTEN       0            511                      0.0.0.0:80                    0.0.0.0:*         users:(("nginx",pid=69226,fd=6),("nginx",pid=69225,fd=6))
tcp         LISTEN       0            128                         [::]:22                       [::]:*         users:(("sshd",pid=812,fd=4))
tcp         LISTEN       0            511                         [::]:80                       [::]:*         users:(("nginx",pid=69226,fd=7),("nginx",pid=69225,fd=7))

주의가 필요한 주요 열은 Netid, 로컬 주소:포트 및 프로세스 이름 열입니다. 로컬 주소:포트가 0.0.0.0이면 서비스가 모든 IPv4 네트워크 인터페이스에서 연결을 수락합니다. 주소가 [::]이면 서비스는 모든 IPv6 인터페이스에서 연결을 수락합니다. 위의 예제 출력에서 SSH와 Nginx는 모두 IPv4 및 IPv6 네트워킹 스택의 모든 공용 인터페이스에서 수신 대기하고 있습니다.

SSH와 Nginx가 두 인터페이스 모두에서 수신하도록 허용할지 또는 둘 중 하나만 수신하도록 허용할지 결정할 수 있습니다. 일반적으로 사용하지 않는 인터페이스에서 실행 중인 서비스는 비활성화해야 합니다.

무인 업데이트

좋은 기본 수준의 보안을 보장하려면 서버를 패치로 최신 상태로 유지해야 합니다. 오래되고 안전하지 않은 소프트웨어 버전의 서버는 대부분의 보안 사고에 대한 책임이 있지만 정기적인 업데이트는 취약성을 완화하고 공격자가 서버에 발판을 마련하지 못하도록 방지할 수 있습니다. 무인 업데이트를 통해 시스템은 대부분의 패키지를 자동으로 업데이트할 수 있습니다.

무인 업데이트는 어떻게 보안을 강화합니까?

무인, 즉 자동 업데이트를 구현하면 서버를 안전하게 유지하는 데 필요한 노력이 줄어들고 서버가 알려진 버그에 취약할 수 있는 시간이 단축됩니다. 서버의 소프트웨어에 영향을 미치는 취약점이 있는 경우 업데이트를 실행하는 데 걸리는 시간에 관계없이 서버가 취약해집니다. 일일 무인 업그레이드를 통해 패키지를 놓치지 않고 취약한 소프트웨어가 수정되는 즉시 패치를 적용할 수 있습니다.

무인 업데이트를 구현하는 방법

Ubuntu에서 자동 업데이트 구현에 대한 개요는 Ubuntu 서버를 업데이트된 상태로 유지하는 방법을 참조할 수 있습니다.

공개 키 인프라 및 SSL/TLS 암호화

공개 키 인프라(PKI)는 개인을 식별하고 통신을 암호화하기 위한 인증서를 생성, 관리 및 검증하도록 설계된 시스템을 말합니다. SSL 또는 TLS 인증서를 사용하여 서로 다른 엔터티를 인증할 수 있습니다. 인증 후에는 암호화된 통신을 설정하는 데에도 사용할 수 있습니다.

PKI는 어떻게 보안을 강화합니까?

인증 기관(CA)을 설정하고 서버에 대한 인증서를 관리하면 인프라 내의 각 엔터티가 다른 구성원의 ID를 확인하고 트래픽을 암호화할 수 있습니다. 이렇게 하면 공격자가 트래픽을 가로채기 위해 인프라의 서버를 모방하는 중간자 공격을 방지할 수 있습니다.

중앙 인증 기관을 신뢰하도록 각 서버를 구성할 수 있습니다. 이후에는 이 기관에서 서명한 모든 인증서를 암시적으로 신뢰할 수 있습니다.

PKI 구현 방법

인증 기관을 구성하고 다른 공개 키 인프라를 설정하려면 상당한 초기 노력이 필요할 수 있습니다. 또한 인증서를 관리하면 새 인증서를 생성, 서명 또는 해지해야 할 때 추가적인 관리 부담이 생길 수 있습니다.

많은 사용자에게 완전한 공개 키 인프라를 구현하는 것은 인프라 요구 사항이 커질 때만 의미가 있습니다. PKI가 추가 관리 비용을 지불할 가치가 있는 시점에 도달할 때까지는 VPN을 사용하여 구성 요소 간 통신을 보호하는 것이 더 나은 중간 조치일 수 있습니다.

자체 인증 기관을 생성하려는 경우 사용 중인 Linux 배포판에 따라 인증 기관(CA) 설정 및 구성 방법 가이드를 참조할 수 있습니다.

결론

이 자습서에 설명된 전략은 시스템의 보안을 개선하기 위해 수행할 수 있는 몇 가지 단계에 대한 개요입니다. 보안 조치를 구현하는 데 시간이 오래 걸릴수록 효과가 감소한다는 점을 인식하는 것이 중요합니다. 보안은 나중에 생각해서는 안 되며 인프라를 처음 프로비저닝할 때 구현해야 합니다. 구축할 보안 기반이 있으면 기본적으로 보안 환경에서 실행된다는 확신을 가지고 서비스 및 애플리케이션 배포를 시작할 수 있습니다.

안전한 시작 환경이 있더라도 보안은 지속적이고 반복적인 프로세스라는 점을 명심하십시오. 변경 사항이 보안에 미치는 영향과 소프트웨어에 대해 항상 안전한 기본 구성 및 환경을 생성하기 위해 취할 수 있는 조치를 항상 스스로에게 물어보십시오.