회사 홈페이지에 알 수 없는 이름의 사용자가 등록되어 있는 것을 확인 했다. 사용자 이름이 sql injection 을 일으킬만한 이름으로 회원 가입이 되어 있었다. 로그를 확인해보니 엄청나게 다양한 시도를 했다. 이 서버에는 사용자들이 어떻게 들어 왔는지 확인하기 위해 간단한 내부적인 pixel tracking 코드가 동작하는데 이 사용자 IP 에서도 이런 코드가 발견되었다. 이렇다는 것은 javascript 가 동작했다는 것이고 단순히 User agent 를 속이고 동작시킨게 아니라 실제로 웹브라우저가 동작했다는 의미이다. 요즘에는 취약점을 점검할 때 웹브라우저를 동작시키나 보다.
어째는 이 서버에는 fail2ban 이 설정되어 있다. 그런데 이게 왜 동작하지 않았는지 확인해 보았다. fail2ban 을 동작시키기 위해서는 로그파일을 설정해야 하는데 이 로그 파일이 Logrotate (https://yiunsr.tistory.com/749 ) 에 의해 이름이 변경되면서 문제가 되었다. 예를 들어 fail2ban 에 access.log 이렇게 되어 있는데 Logrotate 에 주기적으로 Logrotate access.log.1 이런식으로 파일을 만들고 여기에 로그를 쌓아서 문제가 된 것이다. 또 다른 서버에는 access.log.20250914 이런식으로 설정되어 있던 Logrotate 설정도 있었다.
다행히 fail2ban 은 glob pattern 을 지원한다. 완전한 regular expression 을 지원하는 것은 아니지만 없는 것 보다는 이것으로 어떻게든 설정할 수 있었다. https://www.digitalocean.com/community/tools/glob 에서 이러한 형식을 테스트 해 볼 수 있다. 그리고 여러개 등록이 가능하다.
첫 서버에는
* 등록되어야 하는 파일이름
access.log access.log.1
* 등록되면 안되는 파일이름
access.log.2.gz access.log.3.gz
이런 식이라 access.log , access.log.1 을 같이 넣었다.
2번째 서버가 좀 골치 아팠다.
* 등록되어야 하는 파일이름
access.log.20250914 다만 이름이 계속 변경됨
* 등록되면 안되는 파일이름
access.log.20250913.gz 다만 이름이 계속 변경됨
이런식으로 파일이 생성되었다. 어떻게 할지 고민하다가 [0-9]를 8개 넣어 해결했다.
access.log.[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9] 이렇게 설정했다.
다음날 확인해 보니 꽤 많은 ip 들이 ban 되고 있었다.
우선 간단히 fail2ban 으로 막았지만 너무 다양한 공격들이 들어오고 있어 어떻게 더 효율적으로 막을 수 있는지 고민해 봐야 할 것 같다.