열린 포트의 목록은 당신의 서버에 이르는 길의 목록입니다. 나머지 전부 — 방화벽, WAF, 침입 탐지 — 는 그 위에 지어집니다. 그래서 어떤 점검에서든 「여기서 무엇이 대기 중인가」가 가장 먼저 오고, 그래서 이것이 가장 자주 불쾌한 답을 주는 확인이기도 합니다. 발견되는 것의 절반은 당신이 아니라 어떤 패키지의 설치 스크립트가 연 것입니다.

출력 읽기

sudo ss -tulpn

플래그는, t는 TCP, u는 UDP, l은 대기 중인 것만, p는 프로세스, n은 숫자를 숫자로 두라는 뜻입니다. sudo가 없으면 프로세스 열이 비고 이 작업 자체의 의미가 사라집니다.

중요한 것은 Local Address:Port 열이며, 거기의 차이는 근본적입니다.

  • 127.0.0.1:3306 — 서비스는 그 머신 자체에서만 닿습니다. 이것은 좋습니다;
  • 0.0.0.0:3306 — 모든 IPv4 주소에서, 즉 인터넷에서. 바로 이것을 확인해야 합니다;
  • [::]:3306 — IPv6에 대한 같은 것. 별도의 줄이며 정기적으로 놓칩니다;
  • 203.0.113.25:443 — 특정 주소에서, 대개는 의도한 것입니다.

그다음 0.0.0.0이나 [::]가 있는 각 줄에 대해 질문은 하나입니다. 낯선 사람이 여기에 닿아도 되는가. 80과 443에 대한 답은 예입니다. 나머지 거의 전부에 대한 답은 아니오입니다.

흔한 발견

Redis, 포트 6379. 거기서 가장 위험한 줄입니다. 기본적으로 Redis는 비밀번호를 요구하지 않고, 그 명령은 디스크에 파일을 쓰는 것을 허용합니다 — 즉 authorized_keys에 남의 키를 넣을 수 있다는 뜻입니다. Redis가 공인 주소에 나타나고 이용되기까지는 몇 시간, 때로는 그보다 짧습니다. 설정의 bind 127.0.0.1protected-mode yes를 확인하세요.

Memcached, 11211/UDP. 안에 값진 것이 없더라도 당신의 서버는 남의 공격의 증폭기가 됩니다 — 그리고 항의는 당신의 서비스 업체로부터 옵니다.

MySQL과 PostgreSQL, 3306과 5432. 비밀번호는 있지만 그것에 대한 추측은 끊임없이 이루어지고, 데이터베이스의 버전은 바라는 만큼 자주 업데이트되지 않습니다. 그것들이 밖을 향할 필요는 거의 없습니다. 애플리케이션은 같은 머신에 있고, 자기 작업에는 SSH 터널이면 충분합니다.

Elasticsearch 9200, MongoDB 27017. 역사적으로 기본에 인증이 없었습니다. 이것들의 공개 인스턴스는 데이터 유출 뉴스의 상시 공급원입니다.

Docker API, 2375. 열린 Docker 제어 포트는 비밀번호도 없는 호스트의 root 그 자체입니다. 대개 Docker 원격 접근 실험 뒤에 나타납니다.

관리 패널과 phpMyAdmin, 각자의 포트에서: 8080, 8083, 10000. 절대 열면 안 된다는 것은 아니지만, 시도의 대부분을 끌어모으는 것이 바로 이것들입니다.

방화벽이 아니라 서비스에서 고치기

발견한 것마다 UFW 규칙으로 막고 싶은 마음은 이해가 갑니다만, 그것은 첫 번째 선이 아니라 두 번째 선입니다. 규칙은 실수로 지워질 수 있고, 문제를 살피는 동안 방화벽이 잠시 꺼질 수도 있으며, Docker는 아예 UFW를 우회해 포트를 공개합니다. 서비스 자체의 설정에 있는 바인딩 지정은 그 모두를 견뎌 냅니다.

  • MySQL/MariaDB — bind-address = 127.0.0.1;
  • PostgreSQL — listen_addresses = 'localhost';
  • Redis — bind 127.0.0.1 ::1;
  • Docker Compose — "127.0.0.1:5432:5432" 형태로 공개.

방화벽은 그 위에 보험으로 얹는 것이지, 이를 대신하는 것이 아닙니다.

분명하지 않을 때 프로세스 찾기

ss는 이름과 pid를 줍니다. 그다음:

sudo systemctl status <pid>
sudo lsof -i :8080

첫 명령은 그 프로세스가 어느 systemd 유닛의 것인지 알려 줍니다 — 대개 그것이 무엇이고 필요한지 이해하기에 충분합니다. 높은 포트에서 대기하면서 시스템 디렉터리 밖에서 — 예컨대 /tmp/dev/shm에서 — 실행된 낯선 프로세스는 이제 설정의 문제가 아니라 별도 조사의 근거입니다.

외부에서의 확인은 필수

ss가 답하는 것은 「무엇이 대기 중인가」이지 「어디에 닿을 수 있는가」가 아닙니다. 그 둘 사이에는 방화벽과 NAT와 업체 자신의 규칙이 서 있습니다. 정직한 답은 다른 머신에서의 스캔으로만 얻어집니다.

nmap -Pn -p- 203.0.113.25
nmap -Pn -p- -6 2001:db8::1

두 번째 명령을 건너뛰지 마세요. 거의 모든 VPS에 IPv6 주소가 있고, 그 규칙은 따로 쓰이며, 서비스는 프로토콜의 두 버전에서 동시에 대기합니다.

이것은 한 번뿐인 확인이 아니다

열린 포트의 목록은 스스로 바뀝니다. 패키지를 설치했더니 서비스가 딸려 와 포트를 열었다. 패널을 업데이트했더니 기본값이 되돌아왔다. 컨테이너를 띄웠더니 방화벽을 우회해 포트가 공개됐다. 한 번뿐인 확인은 오늘에 대해서만 답할 뿐 그 이상은 아닙니다.

가치는 목록 자체가 아니라 그 변화에 있습니다. 어제는 없던 새 포트는 짧고 매우 정보가 많은 신호입니다. 바로 그렇게 지켜볼 가치가 있습니다 — 기억에서 떠올린 ss의 출력이 아니라, 이력이 있는 스냅샷으로서. 아래 데모 페이지가 보여 주는 것이 바로 그것입니다.