보안

NAC

Network Access Control은 네트워크에 접속하는 장치들을 제어하기 위해 개발되었다.

• 네트워크에 접속할 때 인가된 사용자만 내부망에 접속할 수 있고 인가 받기 전이나 승인에 실패한 사용자는 접속할 수 없도록 제어하는 기술이다.
• 외부 PC가 내부망에 접속해 보안 사고를 일으키거나 악성 코드를 전파하는 문제점들이 많이 발생하자 이것을 해결하기 위해서 개발되었다.

IP 제어

• IP 제어 솔루션은 겉으로 보면 NAC 솔루션과 공통적인 기술을 이용하거나 기능이 비슷한 경우도 많은데 IP 제어 솔루션은 국내에서 많이 사용하는 기술이다.
• 보안 사고 추적이 쉽도록 고정 IP 사용 권고 지침이 금융권에 내려오면서 IP를 할당하고 추적하는 솔루션이 필요해졌고 할당된 IP를 관리하고 정확히 의도된 IP 할당이 아니면 정상적으로 네트워크를 사용하지 못하도록 하는 기능이 필요해졌다.
  • 내부망에는 private IP를 사용해야 하고 외부망에는 public IP를 사용해야 하는데 사용자가 직접 IP 관리를 하는 것은 힘들기 때문에 자동적으로 할당해주는 프로그램이 있다.

접근 통제

• 서버나 데이터베이스에 대한 직접적인 접근을 막고 작업 추적 및 감사를 할 수 있는 접근 통제 솔루션을 개발했다.
• Agent 기반, AgentLess 기반, 베스천 호스트 기반으로 구분된다.
• 베스천 호스트 기반: 서버 접근을 위한 모든 통신은 베스천 호스트에서만 가능하다.
  • 베스천 호스트: 침입 차단 소프트웨어가 설치되어 내부와 외부 네트워크 사이에서 일종의 게이트웨이 역할을 수행해주는 호스트
• 최근의 접근 통제 솔루션들은 단순한 접근 제어뿐 아니라 감사, 보안 이슈 대응 등을 위해서 사용자가 작업한 모든 이력을 저장한다.
• 윈도우의 경우는 화면을 레코딩하고 CLI 기반의 솔루션은 전체 키보드 타이핑을 저장한다.
• 사용자가 접근 제어 솔루션을 통과해 서버에 접근하면 그에 대한 감사 로그도 모두 저장한다.
• 권한을 제어해서 사용 가능한 명령어의 수준도 제한 가능하다.

Firewall

네트워크 보안은 호스트에서 수행하는 보안과 달리 많은 호스트들을 한꺼번에 관리하고 보호할 수 있다는 장점이 있지만 많은 트래픽을 감당해야 하기 때문에 속도를 유지하면서 보안을 제공할 수 있어야 한다는 어려움이 있고 성능 저하 없이 보안을 향상하는 기술이 필요했다. → 방화벽 등장

• 네트워크 중간에 위치해서 해당 장비를 통과하는 트래픽을 사전에 주어진 정책 조건에 맞추어 허용하거나 차단하는 장비
• 네트워크에서 보안을 제공하는 장비를 넓게는 모두 방화벽으로 볼 수 있지만 방화벽은 네트워크 3, 4계층에서 동작하며 세션을 인지하는 상태 기반 엔진으로 동작한다.

3계층 보안 장비 (IP): 컴퓨터를 구분하기 때문에 컴퓨터 단위로 얘껀 받고 얘껀 안 받을 거야.

4계층 보안 장비 (Port): 서비스를 구분하기 때문에 데이터를 받고 안 받고를 결정할 수 있다. (컴퓨터 안에서 데이터 단위로 이 데이터는 받고 이 데이터는 안 받을거야.)

• 초창기 방화벽
  • 현재의 방화벽은 상태 기반 엔진(SPI)을 가지고 있어야 한다.
  • 초기 방화벽에서는 패킷의 인과 관계를 확인하지 못했다.
    • 장비에 등록된 정책만으로 단순히 패킷을 필터링했다.
    • HTTP는 Stateless → A 페이지 눌렀다 B 페이지 눌렀다 C 페이지를 누른 기억을 못한다. (인과 관계 파악 못함) → 챗봇은 http로 못 만들고 웹 소켓으로 만들어야 한다.
    • 이 정보를 Client에 저장해놓자 : Cookie
      • 웹사이트 들어갈 때 쿠키 설정 물어보는 이유 → 그걸 바탕으로 사용자들이 어디 어디를 클릭하는지 알고 UI 바꾸려고
      • 클라이언트에 저장했을 때의 단점: 보안에 취약
    • 이 정보를 Server에 저장해놓자 : Session
      • 서버에 저장했을 때의 단점: 느리다.
  • 패킷의 세션 정보나 방향성과 상관없이 순수하게 방화벽에 설정된 정책에 따라 동작하기 때문에 이런 초기 방화벽을 Stateless 또는 Packet Filter 방화벽이라고 한다.
  • 동작 방식
    • 패킷이 장비에 인입되면 해당 패킷이 방화벽에 설정된 정책에 일치되는 것이 있는지 확인한다.
    • 이 때 참고하는 조건을 5-Tuple이라고 하는데 Source IP, Destination IP, Protocol No, Source Port, Destination Port
    • 방화벽에 일치된 정책이 있으면 해당 정책에 다라 그 패킷을 허용하거나 차단한다.
  • 패킷 필터링 방화벽은 지정된 구간에서 간단한 정책을 정의할 때는 큰 문제가 없지만 인터넷 통신과 같이 불특정 다수 기반의 정책을 정의할 때는 Ruleset이 복잡해지고 보안이 약화되는 문제가 발생한다.
  • 패킷 단위의 필터링이므로 5-tuple 이외의 3, 4계층 헤더를 변조해서 공격하면 방어가 불가능하다.
  • 패킷 필터링 자체는 다른 세대의 방화벽 엔진들보다 부하가 적고 간단히 동작하므로 완전히 없어지지 않고 현대적인 일부 방화벽에서도 특수한 기능을 위해서 남겨두었다.
  • 지정된 IP들을 방어하는 데는 간단한 패킷 필터링이 부하가 적어 블랙리스트 처리를 위해 방화벽 내부에 패킷 필터링 엔진을 배치한다.
• 현대적 방화벽
  • 세션 기반으로 동작하는 상태 기반 엔진(SPI)을 탑재한 방화벽
  • 내부 사용자가 외부의 특정 웹 페이지에 접속할 때 3 way-handshake를 거친 후 HTTP 요청과 응답 과정을 거침
    • 패킷 필터 방화벽에서 이런 트래픽을 처리하려면 목적지가 불특정 다수의 웹이 될 수 있기 때문에 외부로 나가는 목적지에 대해서는 모든 패킷을 허용해야 한다.
    • 이렇게만 정책을 설정하면 내부에서 외부 웹 사이트로 나갈 수 있지만 외부에서 내부로 들어오는 응답에 대한 정책이 없기 때문에 정상적인 통신이 불가능하다.
    • 응답에 대한 정책을 설정해야 한다면 외부의 사이트는 불특정이기 때문에 출발지가 모든 IP 이어야 하고 목적지 서비스 포트는 내부에서 외부 호출 시 랜덤 포트를 지정하므로 모든 포트가 되어야 한다.
    • 모든 IP와 모든 Port를 열어야 하므로 보안 상 매우 취약하다.
      • SPI 엔진을 탑재하면 내부에서 외부 인터넷으로 통신을 시도해 받은 응답과 외부에서 내부로 직접 들어오는 패킷을 구분할 수 있다.
        • 화이트리스트 기반: 내가 원하는 것만 허용하겠다. → 인터넷처럼 열려 있는 공간에서는 불가능
        • 블랙리스트 기반: 내가 원하는 것만 막겠다. (내가 차단할 목록을 써준다. → 관리 쉽지 않음)
  • 동작 방식
    • 내부 컴퓨터에서 요청 → 세션 테이블 확인 → 매칭 되면 포워딩 테이블 확인 (포워딩 테이블에 있으면 패킷 포워딩을 하고 없으면 폐기)
    • 내부 컴퓨터에서 요청 → 세션 테이블 확인 → 매칭 되지 않으면 정책을 확인하고 정책에 있으면 세션 테이블에 기록하고 포워딩 테이블을 확인하러 가지만 매칭되는 정책이 없으면 폐기된다.
  • 세션 인지 기능이 있어서 5-Tuple 조건만 확인하는 것이 아니라 OSI 3, 4계층의 세부적인 필드도 함께 확인한다.
  • TCP 컨트롤 플래그에 따라 동작 방식이 변하거나 시퀀스와 ACK 번호가 갑자기 변경되는 것을 인지해 세션 탈취 공격을 일부 방어할 수 있다.

ALG

그냥 포트 번호만 보고 막으면 FTP 같은 복잡한 통신은 안 된다.

ALG는 그런 복잡한 통신을 이해하고, 필요한 포트를 알아서 열어주는 똑똑한 방화벽 내부 장비다.

• 패킷 필터 엔진보다 헤더 정보를 상세히 확인하고 세션을 인지할 수 있지만 애플리케이션 헤더 정보를 인지할 수 없다.
• 세션 방화벽 이전에 등장한 프로토콜들은 방화벽과 같은 세션 장비를 고려하지 못해서 통신 중간에 방화벽이 있으면 정상적인 통신이 불가능하다.
• FTP(File Transfer Protocol)가 대표적이다.
• FTP는 컨트롤 프로토콜과 데이터 프로토콜이 반대로 세션을 맺기 때문에 방화벽이 FTP 프로토콜을 이해해서 동작하지 않으면 정상적인 서비스가 불가능하다.
• FTP의 동작
  • 클라이언트는 랜덤 포트 2000을 통해서 서버 포트 21에 접속하고 데이터 포트로 사용할 2001 포트 정보를 서버에 전송한다.
  • 서버에서 클라이언트의 2001번 포트로 응답한다.
  • 서버는 서버의 데이터 포트(20)를 클라이언트의 데이터 포트(2001)에 접속한다.
  • 클라이언트에서 서버의 데이터 포트에 응답한다.
• 위의 문제를 해결하기 위해서는 FTP 통신 방식을 패시브 모드로 전환해야 하는데 이를 제공하지 못하는 컴포넌트도 있고 이미 개발된 애플리케이션을 변경할 수 없는 경우도 있어서 방화벽에서 FTP 액티브 모드를 통과시키기 위해서 애플리케이션 프로토콜을 확인하고 필요에 따라 세션을 인지해서 포트를 자동으로 열어주는 장비를 ALG라고 한다.

방화벽의 한계

• 공격 목표가 시스템이나 계정 탈취에서 서비스 중단으로 변경되면서 DDoS 공격이 새로운 트렌드가 되었다.
• 바이러스나 백도어 인터넷 웜 등을 방어할 수 없다.
• 이런 공격을 막기 위해서 등장한 것이 IPS다!

IPS/IDS

• 방화벽은 3, 4계층 보안 장비이고 IDS/IPS는 3, 4, 5, 6, 7 계층 보안 장비이다. (단순히 '누가 어디서 들어오는지' 뿐만 아니라, '안에 어떤 내용이 들어있는지'까지 확인)
• 방화벽은 네트워크 보안을 위해서 필수 솔루션이지만 3, 4계층 방어만 가능하므로 애플리케이션 계층에서 이루어지는 공격은 방어할 수 없다.
  • 애플리케이션 공격은 서비스를 이용하는 시스템 자체의 취약점을 이용하는 경우가 많은데 예를 들면 웹 서비스를 제공하려면 TCP 80 포트를 외부 사용자에게 공개해야 하는데 Apache나 IIS 서버를 악용한 공격은 방화벽에서 필터링하고 모니터링 할 수 없다. → 방화벽의 한계점
• IDS(Intrusion Detection System): 공격자가 시스템을 해킹할 때 탐지를 목적으로 개발된 시스템, 패킷을 복제해서 검토한다. 감시자 역할
• IPS(Intrusion Prevention System): 공격이 발생하면 직접 차단하는 능력을 갖춘 장비
• → 트래픽을 차단하고 방어하는 것 이외에도 회피 공격을 차단하기 위한 세션 이해 기능도 가지고 있다.
• 동작 방식
  • 패턴 매칭 방식: 기존 공격이나 취약점을 통해 공격 방식에 대한 데이터베이스를 습득하고 그 최신 내용을 유지하다가 공격을 파악하는 패턴 방식
    • 패턴 매칭 방식의 방어가 유효하려면 실제로 공격이 들어오기 전에 해당 공격에 대한 패턴 데이터베이스가 확보되어야 하는데 이런 경우 극미한 변화만 생겨도 적절한 대응이 어렵고 인터넷 상으로 빠르게 전파되는 웜 공격 변종을 막아내기가 어렵다.
    • 초창기 웜은 인터넷에 퍼지는 속도가 한 달 정도로 충분히 데이터베이스를 업데이트해서 방어할 수 있었는데 최근에는 인터넷 웜이 4시간 만에 전파가 돼서 그 시간 내에 데이터베이스가 업데이트가 되지 않는다면 공격을 당할 수 밖에 없다.
  • Anomaly (이상 징후) 탐지: 분명히 공격으로 파악되지 않더라도 특정 기준 이상의 행위를 이상하다고 판단해서 방어한다.
• IPS/IDS의 한계와 극복(NGIPS)
  • IPS는 네트워크 상에서 빠른 속도로 애플리케이션 레벨까지 확인하기 위해서 Flow 엔진을 사용했는데 이 엔진은 패킷을 모아 데이터 형태로 변환해서 검사하는 것이 아니라 패킷이 흘러가는 상황을 모니터링 해서 공격을 탐지하기 때문에 IPS 장비를 쉽게 우회할 수 있게 된다.
  • IPS에서 오탐이 많이 발생하므로 초기에 설정된 환경에 맞는 튜닝 작업을 오래 해야 하고 별도의 관제 인력이 장비를 모니터링하고 환경에 맞는 최적화 작업을 지속적으로 수행해줘야 한다.
  • 너무 많은 오탐과 알람 때문에 장비가 공격을 정상적으로 방어하지 못하거나 정상적인 서비스도 차단될 수 있다.
  • 이 문제를 해결하기 위해 예외 처리되는 경우도 많고 설치만 하고 제대로 사용하지 못하는 경우도 많다.
  • 기존 IPS의 기능을 향상해서 문제점을 해결한 NGIPS(Next Generation IPS) 개념의 장비가 출시되었는데 애플리케이션을 인지하거나 다양한 시스템과 연동될 수 있고 APT(Advanced Persistent Threat, 지능형 지속 위협) 공격을 방어하기 위한 일부 기능이 탑재되어 있거나 외부 시스템과 연동할 수 있는 장비도 있다. *APT: 특정 목표를 위해 장기간에 걸쳐 은밀하고 지속적으로 이루어지는 사이버 공격

DDoS 방어 장비

방화벽 이후의 공격은 정상적인 서비스가 불가능하도록 하는데 초점을 맞췄다. → DoS

하나의 컴퓨터로 하나의 서비스를 불가능하게 하는 것은 한계가 있어서 보통 다수의 공격자를 만들어 동시에 DoS 공격을 한다. → DDoS

• DDoS 방어 장비는 Public cloud에서 굉장히 중요하다. (퍼블릭 클라우드에서는 트래픽 자체가 비용이기 때문에)
• DDoS 방어 장비는 Value Metric 공격을 방어하기 위해서 트래픽 프로파일링 기법을 주로 사용하고 인터넷의 다양한 공격 정보를 수집한 데이터베이스를 활용한다.
  • Value Metric 공격: 사용량이나 성능을 측정하는 지표를 악용해서 공격하는 것
  • 서비스 이용량 변조: 공격 대상의 서비스 이용량을 과장되게 보이도록 메트릭을 조작
  • 성능 지표 위변조: CPU 사용률, 메모리 사용률, 네트워크 트래픽 등과 같은 성능 지표를 조작해서 서비스의 성능이 저하되거나 마비되도록 할 수 있다.
  • 가격 변동 조작: 비용에 관련된 문제로 메트릭에 따라서 가격이 결정되는 경우 메트릭을 조작해서 서비스 가격이 상승하거나 하락하도록 조작하여 금전적인 피해를 입히는 공격
• 동작 방식
  • DDoS 탐지 장비와 방어 장비를 구분해두고 탐지 장비가 공격을 수행하는 IP 리스트를 방어 장비나 ISP 내부에 전송을 해서 이 IP를 버리는 방식이 가장 흔한 방식이다. (특정한 IP 리스트를 만들어두고 버려버리는 것)
• 탐지 장비가 DDoS 공격인지 판별하는 방법은 2가지
  • DB를 이용하는 방식
  • 평소 데이터 흐름을 습득해 일반적인 대역폭, 세션량, 초기 접속량, 프로토콜 별 사용량 등을 저장하고 있다가 이렇게 습득한 데이터와 일치하지 않는 과도한 트래픽이 인입되면 알려주는 방식
• 공격 타입
  • Value Metric: 대용량의 트래픽을 사용해 공격 대상의 대역폭을 포화시키는 공격, 간단한 증폭 기술을 사용해서 생성하기 쉬움
    • 공격에 의해 생성된 트래픽 양은 최종 자원(웹 사이트 또는 서비스)에 대한 액세스를 완전히 차단할 수 있다.
    • 쓸모없는 패킷이 회선을 모두 차지해 정상적인 서비스 트래픽이 통과할 수 없다. (트래픽을 전부 가져가는 것)
    • Ex. NTP 증폭, DNS 증폭, UDP 플러딩, TCP 플러딩
  • Protocol: 3, 4계층 프로토콜 스택의 취약점을 악용해 대상을 액세스 할 수 있게 만드는 공격
    • 공격 대상이나 중간 위험 리소스의 처리 용량을 모두 사용해서 서비스 중단을 유발한다.
    • 네트워크 장비나 네트워크 보안 장비를 대상으로 하는 경우가 많다.
    • 네트워크 장비의 CPU나 메모리 자원을 고갈시켜 정상적인 서비스를 불가능하게 한다. (자원을 전부 가져가는 것)
    • Ex. Syn 플러드, Ping of Death
  • Application: 7계층 프로토콜 스택의 취약점을 악용하는 공격으로 가장 정교하고 식별 및 완화가 가장 까다로운 공격이다.
    • 대상과의 연결을 설정한 후 프로세스와 트랜잭션을 독점해 서버 자원을 고갈시킨다.
    • 애플리케이션 프로토콜 자체의 취약점이나 서비스를 제공하는 플랫폼의 취약점을 악용하는 경우가 많다.
    • Ex. HTTP 플러드, DNS 서비스 공격, Slowloris 등
• DDoS 방어 장비는 자동 프로파일링 기법을 지원하고 있어서 사전에 정의된 공격 DB를 이용해 애플리케이션 공격 방어도 가능하지만 DDoS 방어 장비의 주요 방어 목표는 Value Metric과 Protocol Attack 이다.
• Value Metric 공격
  • 회선 사용량 이상의 트래픽을 발생시켜서 회선을 사용하지 못하도록 하는 공격이므로 회선을 공급해주는 ISP(인터넷 공급 사업자) 내부나 사용자 네트워크 최상단에 위치시켜서 이 공격을 완화해야 한다. (ISP랑 같이 해야지 혼자서는 쉽지 않다.)
  • 좀비 PC를 이용한 공격: Value Metric 공격은 특정 시간에 특정 타겟을 공격하는 형태로 발생한다.
    • 이런 공격을 하려면 미리 악성 코드에 감염된 좀비 PC를 많이 확보해야 한다.
    • 최근에는 증폭 공격(수백 Gbps에서 1Tbps 이상에 이르는 엄청나게 높은 대역폭의 공격)이 증가하는 추세인데 공격자가 적은 대역폭으로 중간 리플렉터에 패킷을 보내면 이 트래픽이 증폭되어 피해자 네트워크에 수십~수백배의 공격 트래픽이 발생한다.
    • 이런 방식의 공격은 직접 DDoS 장비를 보유하는 것도 중요하지만 혼자서는 대부분 방어가 불가능하므로 ISP를 통한 방어나 Cloud DDoS 솔루션을 통해 서비스 네트워크로 트래픽이 직접 전달되지 않도록 해야 한다.
    • 이 공격을 막기 위한 방법으로 Cloud 기반의 DDoS 방어 서비스를 고려할 필요가 있다.
    • 클라우드 기반 서비스는 DDoS, WAF와 같은 별도의 보안 장비 없이도 다양한 DDoS 공격을 방어할 수 있고 실제 서비스 앞에서 미리 클라이언트의 요청을 받아 처리한 후 문제가 없는 요청만 서버 쪽으로 전달한다.
    • 클라우드 기반 서비스의 최대 장점은 실제 서비스 네트워크가 가려지므로 네트워크 차원이나 대규모 Value Metric 공격도 방어가 가능하다.

VPN

Virtual Private Network (가상으로 만든 Private Network)

물리적 전용선이 아닌 공중망을 이용해 논리적으로 직접 연결한 것처럼 망을 구성하는 것

• 논리적으로 직접 연결된 것처럼 만들어주는 통로를 Tunnel 이라고 하며 VPN을 이용하면 터널을 이용해서 직접 연결한 것 처럼 동작한다.
• 터널링 기법만 제공해도 VPN 구성이 가능하지만 인터넷과 같은 공중망을 전용선과 같은 사설망처럼 사용하기 위해서 도입하기 때문에 강력한 보안을 제공해야 한다. → 대부분 IPSEC나 SSL과 같은 암호화 기법을 도입한다.
• 전용 회선과 VPN
  • 인터넷 망이 아닌 전용 회선으로 직접 연결할 때도 전용 회선을 통해 VPN을 추가로 구성하는 경우가 있다.
  • 전용 회선은 종단 간에 직접 연결하지만 회선 자체에는 데이터가 그래도 흐르므로 암호화가 되지 않는다.
  • 보안을 강화하기 위한 목적으로 전용 회선에도 VPN을 추가로 구성하기도 한다.
• 예전에는 VPN 서비스를 제공하는 별도의 하드웨어를 제공했지만 최근에는 방화벽이나 라우터 장비에 VPN 기능을 포함시켜 놓는다.
• 가장 많이 사용하는 VPN은 IPSEC와 SSL
  • IPSEC는 네트워크 연결용으로 많이 사용하고 SSLVPN은 사용자가 내부 네트워크에 연결할 때 주로 사용한다.
• VPN 구현 방식
  • Host to Host: 두 호스트 간에 직접 VPN 터널을 연동하는 기법으로 실제 잘 사용하지는 않는다.
  • Network to Network: 본사-지사 같은 특정 네트워크를 가진 두 종단을 연결하는 경우(Hybrid Cloud 구현 시 사용)로 IPSEC 스택을 이용한다.
  • Host to Network: 일반 사용자가 일반 인터넷 망을 통해서 사내망으로 연결하는 경우로 IPSEC나 SSL 프로토콜이 많이 사용된다.
• 최근에는 warning.or.kr 사이트를 우회하는 방법이나 특정 국가에서 결재해야 하는 직구 상품 덕에 다양한 VPN 서비스가 사용되고 있는데 클라우드 방식으로 브라우저 익스텐션과 같은 편리한 방법으로 VPN 서비스를 제공하기도 한다.
• 회피 공격: 공격자가 시도한 공격이 보안 장비에서는 공격으로 판단되지 않고 정상적인 통신으로 확인되지만 실제로 그 공격이 공격 타켓인 피해자에게 도착할 경우 공격으로 동작하는 것
  • 예를 들면 IPS에서 ATTACK이라는 단어가 들어가면 공격으로 판단하도록 설정되어 있는 경우 ATTACK이라는 단어를 보낼 때 한 글자씩 떼어서 보내던가 순서를 변경해서 보낸 후 단말에 도착하면 조립해서 공격을 시도하는 등의 방식을 이용한다.

리눅스 서버 보안

보안의 기본 조치

불필요한 서비스 통제

• 보안 위협은 네트워크를 통해 발생한다.
• 필요하지 않은 서비스 포트는 막아두어야 한다. (모든 포트를 막고 서비스를 제공하려는 포트만 열어주는 것이 좋다.)
• 서비스를 통제하는 방법으로는 불필요한 서비스 자체를 제거하는 방법과 방화벽에서 패킷을 필터링하는 방법이 있다.

소프트웨어 패치 설치

• Cent OS나 Ubuntu 같은 주요 리눅스 배포판은 이미 제공한 소프트웨어에 대한 패치를 지속적으로 제공한다.
• 시스템 관리자는 패치 관련 발표에 주의를 기울이고 있다가 패치가 나오면 즉시 설치한다.
• 패치를 설치하면 시스템 상태를 재확인할 필요가 있다.

주기적인 점검

• 프로세스의 목록과 사용자의 상태, 서비스의 동작 상태, 네트워크 연결 상태, 디스크의 남은 용량 등을 주기적으로 확인한다.
• 점검할 항목을 체크 리스트로 만들고 매일, 매주 등 주기를 정해서 점검한다.
• 시스템과 네트워크 점검을 도와주는 도구를 적극 활용한다.

백업

• 주요 시스템 설정과 소프트웨어, 사용자 데이터 등을 주기적으로 백업한다.

시스템 로그

• 로그는 커널과 리눅스 시스템이 제공하는 여러 서비스 및 응용 프로그램이 발생시키는 메시지
• 로그를 기록한 파일은 로그 파일이라고 리눅스에서는 다양한 로그 파일이 존재한다.
• 로그 파일을 통해 시스템 상태를 파악할 수 있기 때문에 보안 사고에 대비해 사고가 발생했을 때는 원인을 규명하고 침입 경로를 추적하기 위해 가장 기본적으로 로그 파일을 확인하게 된다.

주요 로그 파일

• 리눅스의 로그 파일은 /var/log 디렉토리에 존재한다.
• boot.log나 bootstrap.log: 부팅 시 서비스 데몬의 실행 상태를 기록, 시스템이나 애플리케이션의 초기화 및 부팅 과정에서 발생
• btmp: 실패한 로그인 기록으로 바이너리 파일이다.
• sudo cat /var/log/btmp # 로그인 실패한 기록을 볼 수 있다.
• journal 디렉토리: 데몬이 관리하는 메시지를 기록하는 디렉토리
• ls -l /var/log/journal # total 4 # drwxr-sr-x+ 2 root systemd-journal 4096 Jun 4 06:45 93713498bfd34911947a48d4505a108d
• ufw: 방화벽 데몬이 생성하는 메시지
• lastlog: 각 계정의 가장 최근 로그인 정보를 기록하는데 lastlog 명령으로도 확인 가능하다.
• mail.log: 메일 송수신과 관련된 메시지
• wtmp: 로그인 정보를 기록하는데 last 명령으로 확인 가능하다.
• syslog: 공통적인 로그를 기록하는데 커널이나 데몬에서 발생하는 대부분의 메시지가 기록된다.
  • 그냥 읽는 것은 쉽지 않음 → 파이썬 파일을 하나 만들어서 로그를 파악하는 게 좋다.

  with open('/var/log/syslog', 'r') as f:
      logs = f.readlines()
      for log in logs:
          messages = log.split()
          print(messages[0], messages[1]) # 어디서 누가 했는지 알고 싶다.
  

• rsyslog 데몬: 리눅스 시스템의 로그 파일 중 일부 파일은 rsyslog 라는 로그 관리 데몬에 의해 통제된다.
  • journal 데몬이 기본 도구 역할
  • 필터링: 설정 파일이 /etc/rsyslog.d 디렉토리에 있는 *.conf 파일
  • 어떤 로그를 어떻게 처리할 것인지를 규칙으로 정의한 파일
  • 텍스트 파일이므로 관리자가 편집 가능하다.
  • 규칙은 한 행에 필터와 동작으로 작성하고 공백 문자나 탭으로 구분한다.
  • 필터는 기능명.우선순위 형태로 작성
  • 우선 순위: 메시지의 심각도를 의미하는 것으로 8단계로 구분한다.
    • emerg: 매우 긴급한 상태
    • alert: 긴급한 상태
    • crit: 중대한 상태
    • err: 오류 상태

    ---

    • warning: 경고 메시지
    • notice: 단순 메시지
    • info: 정보성 메시지
    • debug: 디버깅용 메시지
    어딜 가더라도 ewid는 있다. (err, warning, info, debug)
  • 필터 예시
    • kern.*: 우선 순위에 상관없이 커널의 모든 메시지를 선택
    • mail.crit: 메일에서 crit 이상 우선순위의 모든 로그 메시지를 선택
    • cron.!info.!debug: info와 debug를 제외한 모든 메시지를 선택
    • mail.=info: 메일에서 info인 메시지를 선택
  • 동작: 필터가 선택한 메시지를 어떻게 처리할 지를 정의하는데 메시지를 파일로 저장하거나 메일로 전송하거나 화면으로 출력하기 등
  • kern의 crit 이상의 메시지를 kern.log 파일에 기록
  • kern.crit /var/log/kern.log
• journal의 기능
  • journal은 systemd 데몬의 구성 요소로 로그 파일의 관리를 담당한다.
  • 로깅 데이터는 journald 데몬이 수집해서 가공한 후 journals라고 불리는 바이너리 파일로 저장된다. (파일에는 커널이나 사용자 프로세스의 메시지, 시스템 서비스의 표준 출력과 표준 오류 등이 저장되고 사용자가 편집할 수 없다.)
  • 실행 파일의 이름은 systemd-journald
  • systemctl status systemd-journald

journalctl [옵션]

로그 확인

• 옵션
  • -n 행수: 가장 최근에 기록된 로그 중 행 수 만큼 출력
  • -r: 가장 최근 로그가 출력
  • -o {short | verbose}
    • short: syslog 형식으로 출력
    • verbose: 로그의 상세한 내용까지 출력 (자세히 나옴)
  • -f: 최근 로그를 자동으로 출력
  • -p 우선순위: 우선 순위로 필터링해서 출력
  • -b 시간: 시간 이후의 로그만 출력한다.
  • --since=시간 --until=시간: 시간을 필터링해서 출력
  • 필드명=값: 필드명으로 필터링해서 출력한다.
• 로그 파일의 전체 내용 보기: journalctl

•