AI × SI·개발
아무도 노리지 않는데 뚫린다 - 자동화 공격 시대의 웹 보안
침해 사고의 다수는 천재 해커가 아니라 자동화된 스캐너가 열린 문을 발견하면서 시작됩니다. "우리를 누가 노린다고"라는 착각을 걷어내고, 공격자의 채산을 무너뜨리는 문단속 다섯 가지를 정리했습니다.
유성제 · 테크유니온 주식회사 대표 6분 읽기
해커가 등장하지 않는 해킹이 있습니다. 침해 사고의 다수는 사람이 아니라 프로그램이 문을 두드리면서 시작되거든요. 그리고 그 프로그램은 어젯밤에도 여러분 사이트에 다녀갔을 확률이 높습니다.
우리를 노린 걸까? 아무도 노리지 않았다
"작은 회사인데 누가 우리를 노리겠어"라는 말에는 위안이 담겨 있습니다. 표적 공격이었을까요? 아닙니다. 그 직감은 맞습니다 - 아무도 여러분을 고르지 않았습니다. 진짜 문제는 요즘 공격이 '선택'이 아니라 '수확'이라는 데 있습니다.
공격자는 표적을 정해 공들여 뚫는 대신, 전체 웹을 자동으로 훑는 프로그램을 돌립니다. 알려진 보안 결함이 남아 있는 서버, 기본값 그대로인 관리자 계정, 어디선가 유출된 비밀번호가 통하는 로그인 화면 - 걸리는 것만 거둬 갑니다. 밭을 고르는 농부가 아니라 바다에 그물을 던지는 배에 가깝고, 그물에는 회사 규모가 안 적혀 있습니다.
이 그물이 실재한다는 건 서버 로그가 증언합니다. 리눅스 서버가 있다면 이 한 줄이면 됩니다.
# 최근 실패한 로그인 시도 목록 (리눅스)
sudo lastb | head -20
처음 열어 본 서버에서도 낯선 IP 의 시도가 줄줄이 나오는 게 보통입니다. 공개된 지 몇 분 안 된 서버에도 스캔은 옵니다.
그럼 보안 장비를 사면 되지 않나?
이쯤 되면 "방화벽이나 보안 솔루션을 들이면 되지 않냐"는 답이 떠오릅니다. 문제는 실제 침해 사고의 단골 원인들이 장비 바깥에 있다는 겁니다. 그물에 걸리는 문은 대개 이 다섯입니다.
재사용된 비밀번호. 어디선가 유출된 계정 목록을 다른 사이트에 자동 대입해 보는 공격을 크리덴셜 스터핑이라 부릅니다. 담당자가 개인 계정과 같은 비밀번호를 회사 관리자 계정에 썼다면, 우리 시스템의 보안 수준은 그 사람이 가입한 가장 허술한 사이트의 보안 수준으로 내려갑니다.
방치된 업데이트. 보안 패치의 공개는 공격자에게는 결함 지도의 공개이기도 합니다. 패치를 미룬 기간이 그대로 문이 열려 있던 기간이 되죠.
노출된 관리자 페이지. 주소 뒤에 /admin 만 붙이면 나오는 백오피스에 약한 비밀번호가 겹치면, 침입은 기술조차 필요 없는 일이 됩니다.
권한 검증 구멍. 주소창의 문서 번호를 바꿔치기하면 남의 데이터가 열리는 결함입니다. 화면에서 버튼을 숨기는 건 권한 관리가 아닙니다 - 요청마다 서버가 확인해야 권한 관리입니다.
입력 처리 부실. 검색창·문의 폼에 넣은 값이 시스템 명령의 일부로 섞여 드는 고전적 결함으로, 요즘은 주로 프레임워크의 안전장치를 우회한 오래된 코드에서 납니다.
보다시피 다섯 문 모두 값비싼 장비를 둘러도 열려 있습니다. 장비는 성벽인데, 뚫리는 곳은 성문이거든요.
발상의 전환 - 막는 게 아니라 채산을 무너뜨린다
그래서 발상을 뒤집습니다. 어떤 공격도 못 뚫는 성벽을 쌓는 대신, 자동화 공격의 경제학을 공략하는 겁니다.
그물 공격의 본질은 박리다매입니다. 시도 한 번의 비용이 사실상 0원이라, 걸리는 서버가 천 대 중 하나만 돼도 남는 장사입니다. 뒤집어 말하면 - 자동화 공격은 쉬운 문만 수확하도록 설계돼 있어서, 기본 문단속이 된 사이트는 뚫는 게 아니라 건너뜁니다. 다음 서버로 넘어가는 게 더 싸니까요. 목표는 난공불락이 아니라, 그물의 채산 밖으로 나가는 것입니다.
그 문단속이 이 다섯 가지입니다.
| 열린 문 | 잠그는 법 | 드는 품 |
|---|---|---|
| 재사용된 비밀번호 | 관리자 계정만이라도 고유 비밀번호 + 2단계 인증 | 반나절 |
| 방치된 업데이트 | 월 1회 '패치 확인일'을 달력에 고정 | 매월 한 시간 |
| 노출된 관리자 페이지 | 접속 IP 제한, 로그인 시도 제한 | 한나절 |
| 권한 검증 구멍 | "번호 바꿔치기하면 남의 게 보이나" 점검을 개발사에 요청 | 문의 한 건 |
| 백업 없음 | 자동 백업 + 연 1회 복원 리허설 | 반나절 |
목록에 값비싼 항목이 없다는 게 요지입니다. 특히 백업은 성격이 다릅니다 - 앞의 넷이 그물을 피하는 장치라면, 백업은 그래도 걸렸을 때를 위한 마지막 장치입니다. 그리고 복원을 한 번도 해 본 적 없는 백업은, 물이 나오는지 확인 안 해 본 소화전과 같습니다.
성벽의 시대에서 문단속의 시대로
사고 후 보고서에 적히는 원인은 놀라울 만큼 반복됩니다. 미룬 업데이트, 재사용된 비밀번호, 확인 안 한 권한. 보안이 어려워서 뚫린 게 아닙니다. 소수의 침입자를 성벽으로 막던 시대가 막을 내리고, 무차별 그물 앞에서 문단속이 빠른 쪽이 살아남는 시대로 바뀐 겁니다.
직접 서버를 만지지 않는 운영자라도 이 전환에 동참할 수 있습니다. 개발사나 호스팅사에 세 가지만 물으면 됩니다 - 보안 업데이트는 누가 언제 적용하나요, 관리자 페이지는 어떻게 보호돼 있나요, 백업 복원 테스트는 언제 해 봤나요. 구체적으로 답하지 못하는 항목이 바로 열려 있는 문입니다.
리뉴얼이나 신규 구축을 앞두고 있다면 기술 체크리스트에 이 문단속 항목을 함께 얹으면 되고, 운영 중이라면 오늘 확인할 건 하나면 됩니다. 지금 쓰는 관리자 비밀번호 - 다른 어딘가에서도 쓰는 비밀번호인가요?
자주 묻는 질문
방문자도 적은 사이트인데 정말 공격이 오나요?
자동화 스캔은 방문자 수와 무관하게 IP 대역과 도메인 전체를 훑습니다. 트래픽이 없는 사이트도 스팸 발송 경유지, 악성코드 배포지, 다른 공격의 발판으로 쓸모가 있어서 수확 대상이 됩니다. 위의 `lastb` 명령으로 직접 확인해 보는 것이 가장 빠른 실감입니다.
침해가 의심되면 무엇부터 해야 하나요?
순서는 보존 → 차단 → 복구입니다. 당황해서 서버부터 밀면 원인 추적이 불가능해지니 로그와 상태를 먼저 보존하고, 의심 계정 잠금과 접속 차단으로 확산을 막은 뒤, 백업으로 복구합니다. 개인정보 유출 정황이 있다면 규모에 따라 통지·신고 의무가 따르므로, 이 순서를 사고 전에 한 번 읽어 두는 것만으로도 대응 속도가 달라집니다.
글쓴이
유성제 · 테크유니온 주식회사 대표
기획·컨설팅부터 소프트웨어 개발, AI 솔루션, 호스팅 운영까지 이끌고 있습니다.
회사 소개