UFW 방화벽

UFW 방화벽
UFW 방화벽
상태: 활성
규칙: 6 | 열린 포트: 5
4
허용
2
거부
열린 시스템 포트
22 80 443 3306 8083
방화벽 규칙
포트작업출발지
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
8083/tcp ALLOW Anywhere
3306/tcp DENY Anywhere
25/tcp DENY Anywhere

방화벽 규칙을 되짚어 보기 위한 UFW 웹 화면

UFW가 존재하는 까닭은 날것의 iptables 문법이 아무것도 봐주지 않기 때문이며, 그 일에서는 제 몫을 합니다. 하지 못하는 것은 몇 달 뒤에 규칙 묶음을 다시 살피기 쉽게 만드는 일입니다. ufw status numbered가 서른 줄을 돌려주고, 그중 어느 것이 아직 필요한지 가려내려 애쓰는 그때 말입니다.

이 페이지는 같은 규칙을 보여 주되, 들어오는 쪽과 나가는 쪽의 기본 정책을 맨 앞에 놓습니다. 정작 잊히는 것이 바로 그것이기 때문입니다. 들어오는 쪽 기본 정책이 allow로 남아 있다면, 아무리 빡빡해 보이는 규칙 묶음도 아무 뜻이 없습니다. 규칙은 동작, 포트, 프로토콜, 출처와 함께 나오며, IPv6 항목은 목록을 두 배로 늘리는 대신 짝이 되는 IPv4 항목 옆에 섭니다.

찾아볼 만한 실수는 이렇습니다. 한 번의 시험을 위해 열고 끝내 닫지 않은 포트. localhost면 충분했는데 모든 인터페이스에서 듣고 있는 서비스. 주소 하나면 될 자리에 서브넷 전체를 들이는 규칙. 열린 포트 페이지는 그림의 나머지 절반, 곧 그 규칙들 뒤에서 실제로 무엇이 듣고 있는지를 보여 줍니다.

이 두 그림은 정기적으로 맞대어 볼 값어치가 있습니다. 둘은 조용히 어긋나기 때문입니다. 어떤 규칙은 아무도 듣고 있지 않은 포트를 막고 있을 수 있고, 그렇다면 그 규칙은 규칙 집합 속의 짐일 뿐입니다. 반대도 있습니다. 닫혀 있다고 여긴 규칙 뒤에서 서비스가 모든 인터페이스에서 듣고 있는 경우입니다. 이 물음에 대한 옛 대답은 netstat이고, 지금도 옳은 대답입니다. 다만 그 출력은 매번 눈으로 다시 읽어야 합니다.