수집 서버의 특정 포트를 밖에서 못 붙게 DROP으로 막기로 했다. 규칙을 넣고 밖에서 확인해 봤는데 연결이 그대로 붙었다.
Table of contents
Open Table of contents
규칙은 있는데 붙던 연결
iptables -L로 조회해 보니 내가 넣은 줄이 분명히 있었고 있는데도 안 걸리는 상황이었다.
목록에 있다는 것과 그 규칙이 적용된다는 것이 다르다는 것을 그때 알았다. 규칙이라는 것은 위에서부터 순서대로 훑기 때문이다.
내가 쓴 것은 -A였는데 문서에도 선택한 체인의 끝에 규칙을 덧붙이는 것으로 적혀 있다. INPUT 체인의 그 위쪽에 이미 전부 ACCEPT로 보내는 규칙이 있었다.
들어온 연결이 그 규칙에서 ACCEPT로 결정되면 아래는 아예 안 본다. 그러니 내가 넣은 규칙까지는 아예 도달하지 않는다. -I로 규칙 번호를 지정해 앞쪽에 끼워 넣으니 그때 막혔다.
카운터로 확인한다
이 문제를 빨리 찾을 수 있는 방법도 알게 됐다. 각 규칙에 걸린 패킷 수와 바이트 수가 계속 세어지고 있고 -L에 -v를 붙이면 그 값이 함께 나온다.
목록을 볼 때 그 숫자를 함께 보면 내 규칙이 실제로 쓰이는지가 바로 나온다. 그 값이 계속 0이면 거기까지 도달하지 않는 것이다. 목록에 있는지가 아니라 그 숫자로 확인하는 것이 맞았다.
계열이 다른 관리 도구
다른 장비에서 같은 작업을 했더니 이번에는 넣은 규칙이 얼마 뒤에 사라졌다. 그 장비에는 firewalld 같은 관리 도구가 돌고 있었다.
firewalld가 자기가 아는 규칙으로 iptables 쪽을 주기적으로 덮어쓰고 있었다. 그러니 직접 넣은 규칙은 그때마다 없어진다. 그래서 장비마다 iptables를 직접 쓰는지 firewalld 아래에 있는지를 먼저 확인하고 그 계열의 방식으로 넣게 했다.
막혔는지는 밖에서 본다
넣은 규칙이 재부팅을 넘기고도 남는지 확인해야 했다. 명령으로 넣은 것은 메모리에만 있어서 다시 뜨면 사라진다.
그래서 iptables-save로 저장하고 실제로 재부팅해서 남아 있는지를 봤다. 그리고 막혔는지는 서버 안에서가 아니라 밖에서 nc로 확인했다. 막아야 할 포트와 함께 열어 둬야 할 포트도 같이 확인했는데 SSH로 원격 작업할 때는 자기 접속을 DROP시킬 수 있어서 되돌리는 것을 미리 예약해 두었다.
정리
- 규칙이 목록에 있다는 것과 적용된다는 것은 다르다
-A는 체인 끝에 붙으므로 위의 통과 규칙에서 걸려 도달하지 않는다-I로 규칙 번호를 지정해 앞쪽에 넣는다- 걸렸는지는 목록이 아니라
-L -v의 패킷 수로 본다 - 관리 도구가 돌면 직접 넣은 규칙이 덮인다
- 장비마다 어느 계열인지 먼저 확인한다
- 명령으로 넣은 것은 재부팅하면 사라지므로 저장하고 실제로 확인한다
- 막혔는지는 밖에서 보고 열어 둘 포트도 함께 확인한다