리눅스 기반 랜섬웨어의 서버 공격, 막을 방법은?

리눅스 악성코드를 막을 수 있을까? 웹 서버를 패치하고 이를 지속적으로 업데이트하면 막을 수 있지만, 이 방법은 말처럼 그리 간단하지 않다. 


이미지 출처 : Thinkstock
소포스랩스(SophosLabs)에 따르면 리눅스/랜섬-C(Ransm-C) 랜섬웨어(Ransomware)는 새로운 리눅스 기반 랜섬웨어 공격의 예로, 작은 명령줄 프로그램으로 제작되었으며 사기꾼들이 리눅스 서버를 통해 돈을 갈취할 수 있도록 돕는다.

센추리링크(CenturyLink)의 사이버 방어 책임자 빌 스웨어링겐은 이러한 리눅스 랜섬웨어 공격이 최종 사용자를 노리는 것에서 리눅스 서버, 즉 웹 서버를 노리는 것으로 바뀌고 있다고 설명했다. 이어서 그는 “리눅스 랜섬웨어 공격이 데이터를 암호화하는 소프트웨어를 이용하는데 이는 지금까지 우리가 본 크립토월(CryptoWall), 크립토록커(CryptoLocker) 등과 비슷하다"고 전했다.

공격자들이 강력하게 암호화할 수 있는 손쉬운 코딩 그리고 익명 통화 및 익명 호스팅을 사용할 수 있는 한 랜섬웨어는 사라지지 않을 것이라고 스웨어링겐은 말했다. 소포스랩스 등의 보안 업체가 새로운 리눅스 랜섬웨어의 변종을 발견하고 추적하는 상황에서 기업들은 서버 소유자, 사용자, 운영자로서 주요 표적이 될 수 있기 때문에 그 위험과 해결 방법을 스스로 찾아야 한다.

일반 기업과 사용자는 실수를 저지른다
리눅스 웹 서버에서 다양한 오픈소스 소프트웨어가 사용되고 있는 상황에서 공격자들이 패치 되지 않은 취약점을 가진 워드프레스(WordPress), 드루팔(Drupal), 줌라(Joomla) 등의 CMS 시스템을 이용해 리눅스 암호기/랜섬웨어를 위장하고 기업 웹 서버와 데이터를 볼모로 대가를 노리고 있다고 스웨어링겐은 말했다.

스웨어링겐에 따르면 초기 리눅스 랜섬웨어는 코딩이 형편 없었지만 앞으로는 점차 효과가 증대될 것이다. 공격자들이 새로운 리눅스 암호기를 작성하면서 기업들은 이에 대항하기 위해 대비해야 한다.

리눅스 악성코드에 대응하는 확실한 방법은 CMS 제품과 웹 서버를 지속적으로 패치하고 업데이트하는 것이다. 하지만 패치 자체도 쉽지는 않다. 리눅스 웹 서버조차도 OS 계층, 애플리케이션 계층, 데이터베이스 계층 등 기업들이 여러 계층을 패치해야 한다고 스웨어링겐은 말했다. "전통적으로 기업들은 운영 체제 계층에 집중하여 취약점 스캐너를 운용한다. 하지만 공격자들이 표적으로 삼는 것은 애플리케이션 계층이다"고 스웨어링겐은 말했다. 기업은 모든 수준에서 구멍을 찾아 패치하기 위해 노력을 기울여야 한다. 이를 위해서는 별도의 시간과 돈이 필요하다.

패치에 결함이 있어 자체적인 문제가 발생할 수 있기 때문에 즉각적인 패치가 실용적이지 못한 경우가 많다. 기업들은 생산 환경에 설치하기에 앞서 새로운 패치를 엄격하게 시험해야 한다. 또 적절한 시험을 위해서는 시간, 노력, 추가 자금이 필요하다. 기업들은 시험을 시작할 수 있는 한계를 수립해야 한다. 비용의 정당성을 확보하지 못하는 경우가 많다.

제대로 동작하는 패치라 하더라도 일반적으로 충돌과 상호 운용성 부재로 특정 인접 애플리케이션과 소프트웨어 의존성에 부정적인 영향을 끼쳐 CMS 및 기타 리눅스 웹 서버 제품이 문제를 경험하거나 모두 작동을 중지할 수 있다. 궁극적으로 기업들은 패치 솔루션에 접근할 때 패치 위험과 비용을 고려해야 한다.

만약 같은 취약점을 수 년 동안 패치하지 않은 상태로 유지하는 경우 공격자들의 표적이 될 가능성이 가장 높다. "공격자들은 외부 애플리케이션의 잘 알려지고 기록된 취약점을 활용한다"고 스웨어링겐은 말했다. 결국 패치하지 않으면 멈추게 될 수 밖에 없다.

개발 보안
웹 애플리케이션 보안을 위한 최고의 순간은 개발 초기다. 개발자들은 애플리케이션에 발생할 수 있는 가장 위험한 취약점을 다루는 코딩 표준을 따를 때 공격이 성공할 수 있는 가능성이 크게 낮아진다. “맞춤형 애플리케이션에서는 개발자들이 OWASP 상위 10대(OWASP Top Ten) 목록을 참조하도록 해야 한다”고 스웨어링겐은 말했다.

OWASP 상위 10대 애플리케이션 보안 위험에는 주입 결함, 불량하게 이행한 인증, 사이트간 스크립트 작성 결함, 직접 객체 참조, 안전하지 못한 구성, 민감한 데이터, PII 노출, 기능 레벨 접근 통제 누락, 사이트간 요청 위조, 알려진 취약한 구성요소, 검증되지 않은 다시 보내기(Redirect) 등이 있다. 각각의 경우에 보안 구멍으로 인해 공격자는 데이터 또는 구성요소를 삽입하거나 이에 접근하여 해킹이 더욱 광범위해질 수 있다.

개발자들이 앱을 작성하면서 각 취약점을 확인하고 해결함으로써 심지어 앱이 세상의 빛을 보기도 전에 공격을 예방할 수 있다.

취약점 모니터링
OS와 마찬가지로 CMS 및 웹 애플리케이션에 맞추어 개발한 취약점 스캐너가 존재한다. “워드 프레스 사이트를 운영하는 경우 이를 시험할 수 있는 WPScan 이라는 사이트가 있다"고 스웨어링겐은 말했다. 해커타깃(HackerTarget)은 여러 개의 웹 및 CMS 스캐너를 사용할 수 있다. OWASP는 워드프레스 스캐너가 있다. 또한 소스 코드를 확인할 수 있는 스캐너가 있다.

물론, 취약점을 발견한 후에는 패치하거나 WAF 등의 다른 솔루션을 찾아 보호해야 한다.

"공격자가 암호화하고 몸값을 요구하는 상황에서 시스템을 복원할 수 있는지 시험하고 검증할 수 있는 백업 전략을 포함하여 보안 모범 사례를 이행해야 한다"고 스웨어링겐은 말했다. 누군가 서버를 제공했고 기업이 애플리케이션 계층을 담당하고 있다면 환경에 따라 애플리케이션과 데이터베이스를 백업해야 한다고 그는 설명했다.

일반적으로 백업으로 리눅스 랜섬웨어 공격에 대응하기 위해서는 다른 위치에 있는 다른 시스템에 다른 크리덴셜로 백업을 보관하여 서버 해킹으로 인해 백업도 해킹되는 일이 없도록 해야 한다. "백업을 위해 서버 스냅샷(Snapshot)을 사용하는 경우 백업 시스템이 해킹된 원본 시스템에 마운트(Mount)되어 있지 않도록 해야 한다"고 스웨어링겐은 말했다.

보안 활동
보안 모범 사례를 통해 기업은 외부에 노출된 서버와 다른 네트워크로부터 웹 서버를 분리하고 매우 제한적인 접근 제어를 활용할 수 있다고 스웨어링겐은 말했다. 항상 가능한 모든 방어 계층을 활용해야 한다.

추가 보안 활동으로는 특정 앱을 컨테이너(Container)에서 구동하여 나머지 시스템으로부터 고립하는 것이 있다고 비트나인 + 카본 블랙(Bit9+Carbon Black)의 수석 보안 전략가 벤 존슨은 말했다. "한 컨테이너의 앱 또는 웹 서버는 다른 컨테이너의 앱을 공격할 수 없다. 한 컨테이너가 공격을 당했다 하더라도 다시 다른 것을 공격할 수는 없다"고 존슨은 밝혔다.

도움이 되는 잘 알려진 통제 형태도 존재한다. "화이트리스트(White List)를 이용해 웹 서버에서 구동할 수 있는 앱을 승인하고 다른 곳에서는 차단한다"고 존슨은 말했다. 사용하지 않는 포트 닫기를 포함한 시스템 강화는 애플리케이션 차단과 관련되어 있다.

"꾸준한 IT보안이 최고의 조치다. 공격 문제의 90%를 해결할 수 있다"고 존슨은 말했다.