Bong's Log

SELinux vs AppArmor 요약

 어떤 환경에서 어떤 것이 유리할까?

✅ 결론

• RHEL 계열은 기업 보안, 규제 대응, 정부기관에 최적화된 "강력한 보안 프레임워크(SELinux)"와 안정성 위주의 구조를 갖고 있음.
• Ubuntu 계열은 비교적 "빠르고 간단한 보안 모델(AppArmor)"을 통해 개발과 운영의 유연성을 확보하는 쪽에 초점이 있음.

기업에서 운영체제 선택은 단순한 기술 선택이 아니라, 보안, 유지관리, 비용, 인증 등 다양한 요소를 고려한 전략적 결정입니다. 최근에는 많은 기업들이 Red Hat Enterprise Linux(RHEL) 대신 Rocky Linux를 선택하거나, 요구하는 사례가 늘고 있습니다. 그 이유를 구체적으로 살펴보겠습니다.

 1. 보안성

SELinux 기본 탑재

Rocky Linux는 RHEL과 마찬가지로 SELinux(Security-Enhanced Linux)가 기본 활성화되어 있어, 프로세스 간 권한 통제를 정밀하게 설정할 수 있습니다. 이는 보안 사고를 사전에 방지하는 데 큰 역할을 합니다.

빠른 보안 패치

RHEL에서 제공하는 보안 업데이트를 거의 실시간으로 반영하여, 최신 보안 위협에 대한 빠른 대응이 가능합니다. 기업 내 정보보안 정책 준수에 매우 유리합니다.

 2. RHEL과 1:1 호환

Rocky Linux는 RHEL과 이진 호환성(binary compatibility)을 목표로 설계되어, RHEL에서 실행되던 애플리케이션이 그대로 Rocky에서도 실행됩니다.

• 기존 RHEL용 패키지, Ansible 스크립트, 운영 자동화 도구 등 모두 그대로 사용 가능
• 테스트 환경에서 Rocky를 활용하고, 운영환경은 RHEL로 구성하는 하이브리드 운영도 가능

 3. 비용 절감

RHEL은 안정성과 기술지원을 제공하지만, 서브스크립션 비용이 부담될 수 있습니다. 특히 수십~수백 대의 서버를 운용하는 기업에서는 큰 비용 차이를 만들 수 있습니다.

Rocky Linux는 완전히 무료이므로,

• 예산이 제한된 중소기업
• 교육/연구기관
• 테스트/스테이징 환경 운영 기업 에게 매우 매력적인 대안입니다.

 4. CentOS의 자연스러운 후계자

CentOS가 2021년 이후로 롤링 릴리즈 방식(CentOS Stream)으로 전환되면서, 많은 기업들이 안정적인 대체제를 찾기 시작했고 그 답이 바로 Rocky Linux였습니다.

• CentOS 사용자라면 운영체제 변경 없이 그대로 Rocky로 마이그레이션 가능
• 이로 인해 대규모 조직에서도 빠르게 채택되고 있음

 5. 감사 및 규제 대응

Rocky는 RHEL과 동일한 시스템 감사 툴과 구성을 제공하므로, 기업의 보안 인증(ISMS, ISO 27001 등) 대응에 적합합니다.

• OpenSCAP을 통한 취약점 스캔
• AIDE, Auditd 등을 통한 감사 로그 및 무결성 확인
• 보안 정책 자동화 툴과의 호환성 보장

 6. 클라우드 및 DevOps 환경에 적합

Rocky Linux는 AWS, Azure, GCP 등 주요 클라우드 플랫폼에서도 공식 이미지로 지원되고 있으며, Terraform, Ansible, Jenkins 같은 DevOps 도구들과도 완벽 호환됩니다.

• CI/CD 파이프라인 구축
• 컨테이너 기반 개발 환경(Kubernetes, Docker 등) 연동
• 클라우드 인프라 자동화

✅ 결론

기업에서 Rocky Linux를 요구하는 이유는 단순히 "무료라서"가 아닙니다. 그것은 다음과 같은 복합적인 장점 때문입니다:

• RHEL 수준의 보안성과 안정성
• 100% 무료로 비용 절감 가능
• CentOS 사용자에게는 자연스러운 대체제
• DevOps 및 클라우드 환경에 최적화
• 감사 및 컴플라이언스 대응 가능

리눅스를 사용하다 보면 "어떤 배포판을 써야 할까?"라는 고민이 꼭 생깁니다. 특히 서버 환경이나 개발 환경을 세팅할 때, Red Hat Enterprise Linux(RHEL), Rocky Linux, Ubuntu 세 가지는 가장 자주 언급되는 배포판입니다.

이번 글에서는 이 세 배포판을 다양한 기준으로 비교해보고, 각 환경에 맞는 추천 포인트까지 정리해보겠습니다.

배포판 핵심 비교

 어떤 상황에서 어떤 배포판을 쓸까?

✍️ 마무리

세 가지 배포판은 각기 다른 철학과 목적을 가지고 있지만, 모두 강력하고 실무에 적용 가능한 리눅스입니다.

• 기업에서 안정성과 공식 지원이 중요하다면 RHEL
• 무료로 RHEL 환경을 쓰고 싶다면 Rocky Linux
• 개발자나 클라우드 중심이라면 Ubuntu

Ubuntu 22에서 Nginx를 설치하고 메인 페이지를 수정하는 방법을 정리해보겠습니다.

웹 서버를 처음 다뤄보는 분들도 쉽게 따라 할 수 있도록 단계별로 설명할게요.

1. Nginx 설치하기

1-1. 패키지 업데이트

먼저, 최신 패키지 목록을 가져옵니다.

1-2. Nginx 설치

이제 Nginx를 설치합니다.

설치가 완료되면 Nginx가 자동으로 실행됩니다. 아래 명령어로 정상적으로 실행되고 있는지 확인하세요.

실행 중이라면 다음과 같은 출력이 나옵니다.

부팅 시 자동 실행되도록 설정하려면 다음 명령어를 사용하세요.

2. Nginx 기본 페이지 확인하기

curl ifconfig.me

해당 ip로 접속 시, Nginx 기본 페이지가 보이면 정상적으로 설치된 것입니다.

3. Nginx 메인 페이지 수정하기

기본적으로 Nginx의 웹 페이지 파일은 /var/www/html/index.nginx-debian.html에 위치합니다.
이 파일을 수정하면 메인 페이지를 변경할 수 있습니다.

3-1. 기존 파일 백업

3-2. HTML 파일 수정

기본 제공되는 페이지를 수정해보겠습니다.

아래와 같은 HTML을 입력하거나 수정하세요.

3-3. 변경 사항 적용 및 확인

변경 사항이 적용되었는지  브라우저에서 접속해보세요.
수정한 내용이 정상적으로 표시된다면 성공입니다

최근 VM에 암복호화 솔루션을 설치하면서 공식 문서 대신 직접 설치 경로와 관련 로그 파일을 찾아가는 과정이 있었습니다. 그 과정에서 리눅스와 유닉스 환경에서 메모리, 디스크, 네트워크 등의 상태를 점검하고 문제를 해결하는 다양한 명령어들을 활용하게 되었는데요. 이번 포스팅에서는 그 경험을 공유하며 자주 사용하는 명령어들을 정리해보려 합니다.

1. 디스크 사용량 확인 및 분석

시스템에서 디스크 용량이 가득 찼다는 알림을 받으면, 우선 어느 경로에서 많은 파일이 쌓였는지 확인해야 합니다.

1-1. 전체 디스크 상태 확인

• df -h
  사람이 읽기 쉬운 단위(GB/MB)로 파일 시스템의 전체 사용량을 확인합니다.
  이를 통해 어느 파티션이 거의 가득 찼는지 빠르게 파악할 수 있습니다.

1-2. 특정 경로 내 용량 많은 디렉터리/파일 찾기

최상위 디렉터리 용량 확인루트(/) 아래 각 폴더의 용량을 요약하여 확인할 수 있습니다.

• du -sh /*

하위 디렉터리에서 큰 파일/폴더 찾기/var와 같이 용량이 클 것으로 예상되는 디렉터리에서 가장 많은 용량을 차지하는 파일 또는 폴더 10개를 정렬해 보여줍니다.

• du -ah /var | sort -rh | head -10

특정 크기 이상의 파일 검색1GB 이상인 파일을 시스템 전체에서 검색하여 불필요한 파일을 정리할 때 유용합니다.

• find / -type f -size +1G 2>/dev/null

2. 메모리 사용 현황 점검

VM 환경에서 메모리 부족 현상이 발생할 경우, 어떤 프로세스가 메모리를 많이 사용하는지 확인하는 것이 중요합니다.

2-1. 메모리 전체 상태 확인

• free -m
  메모리의 총 용량, 사용 중인 용량, 캐시 용량 등을 MB 단위로 확인할 수 있습니다.
   

2-2. 프로세스별 메모리 사용량 확인

메모리 사용량 높은 프로세스 정렬메모리 사용률이 높은 상위 10개의 프로세스를 확인할 수 있습니다.

• ps aux --sort=-%mem | head -10

실시간 모니터링또는를 사용하여 실시간으로 메모리와 CPU 사용 현황을 점검할 수 있으며, Shift + M로 메모리 기준 정렬도 가능합니다.

• top

2-3. 캐시 메모리 관리

• 캐시 메모리 해제
  echo 3 > /proc/sys/vm/drop_caches sync
  캐시가 과도하게 쌓여 있는 경우, 임시로 캐시를 비워 메모리를 확보할 수 있습니다. 단, 캐시 해제는 시스템 성능에 영향을 줄 수 있으니 신중하게 사용해야 합니다.

3. 네트워크 트래픽 분석 (TCPDump 활용)

애플리케이션의 네트워크 트래픽을 분석할 때 TCPDump는 매우 유용한 도구입니다.

3-1. 기본적인 패킷 캡처

네트워크 인터페이스 선택 및 캡처 시작먼저 사용 가능한 인터페이스 목록을 확인한 후, 원하는 인터페이스에서 패킷 캡처를 시작합니다.

• tcpdump -D tcpdump -i eth0

특정 IP 또는 포트 필터링특정 IP나 포트를 대상으로 하는 트래픽만 캡처할 수 있습니다.

• tcpdump -i eth0 host 172.111.222.100 tcpdump -i eth0 port 80

3-2. 패킷 상세 분석 및 저장

• 패킷 내용 상세 출력 (HEX 및 ASCII)
   

  tcpdump -X -i eth0 port 80
• 전체 패킷 캡처 및 파일 저장
   

  tcpdump -i eth0 -s 0 -w capture.pcap

4. 애플리케이션 및 서비스 관리

솔루션이 VM에 설치된 경우, 애플리케이션 관리와 서비스 상태 점검도 매우 중요합니다.

4-1. 프로세스 관리

• 프로세스 조회 및 종료
   

  ps aux | grep <솔루션명 또는 관련 키워드>

  kill -9 <PID>

  pkill -9 <프로세스명>
  설치 경로나 로그 파일 위치를 찾기 위해 관련 프로세스를 조회하고, 필요시 종료하는 과정이 필요할 수 있습니다.

4-2. 서비스 관리 (systemd 기반)

• 서비스 상태 확인 및 재시작
   

  systemctl status <서비스명>

  systemctl restart <서비스명>
  서비스를 재시작하거나 상태를 확인하여 애플리케이션의 정상 작동 여부를 점검할 수 있습니다.

5. 기타 유용한 명령어

애플리케이션 로그를 모니터링하고, 실시간 시스템 상태를 확인할 수 있는 명령어들도 함께 정리합니다.

5-1. 로그 모니터링

• 실시간 로그 확인
   

  tail -f /var/log/<로그파일명> 
  로그 파일의 내용을 실시간으로 모니터링하면서 문제 발생 시 원인을 분석할 수 있습니다.

5-2. 실시간 시스템 상태 모니터링

• watch 명령어 활용
   

  watch -n 1 free -m
  1초 간격으로 메모리 상태를 지속적으로 확인할 수 있습니다.

5-3. 네트워크 포트 사용 확인

• 포트 사용 현황 확인
   

  netstat -tulnp | grep 80 ss -tulnp | grep 80
  네트워크 포트와 연결된 프로세스를 확인하는 데 유용합니다.

결론

공식 문서가 부족한 상황에서, VM에 설치된 암복호화 솔루션의 설치 경로와 관련 로그 파일을 직접 찾아가며 시스템 상태를 점검했던 경험은 매우 유익했습니다. 위에서 소개한 명령어들을 활용하면, 디스크와 메모리 사용 현황, 네트워크 트래픽, 애플리케이션 상태 등 다양한 측면에서 시스템을 효과적으로 관리할 수 있습니다. 여러분도 필요에 따라 이 명령어들을 적용하여 보다 안정적인 시스템 운영에 도움이 되시길 바랍니다.

1. 개요

사내 보안 정책상 외부망에서 내부망으로 파일을 전송해야 하는 경우, 직접적인 접근이 차단되어 있기 때문에 Proxy를 통해 해결할 수 있을지 고민하게 됩니다. 특히 Nginx와 같은 HTTP Proxy로 SFTP를 처리할 수 있는지, 혹은 HAProxy 같은 TCP 기반 프록시를 활용할 수 있는지에 대한 의문이 있을 수 있습니다.

이 글에서는 Proxy를 통해 SFTP 파일 전송이 어려운 이유를 설명하고, 가능한 대안으로 HAProxy를 검토해보겠습니다.

2. Proxy를 활용한 SFTP 전송이 어려운 이유

프록시는 기본적으로 특정 프로토콜의 트래픽을 중계하는 역할을 합니다. 그러나 SFTP와 같은 SSH 기반 프로토콜을 Proxy로 처리하는 것은 여러 제약이 따릅니다.

2.1. HTTP Proxy(Nginx, Squid 등)는 SFTP를 지원하지 않음

Nginx나 Squid와 같은 일반적인 프록시는 주로 HTTP/HTTPS 트래픽을 처리하도록 설계되었습니다. 하지만 SFTP는 HTTP 기반이 아니라 SSH 기반의 프로토콜이기 때문에 이러한 웹 프록시에서는 처리할 수 없습니다.

2.2. TCP 기반 Proxy(HAProxy)를 활용한 접근

HAProxy는 L4(TCP) 레벨에서 트래픽을 중계할 수 있기 때문에, SSH/SFTP 연결을 프록싱할 가능성이 있습니다. 하지만 SSH 연결은 보안성을 위해 세션을 유지하는 방식이며, 단순한 TCP 프록시만으로는 SSH 인증 과정을 제대로 처리하기 어려울 수 있습니다. 또한, SSH의 키 교환 및 암호화 방식이 중간에서 트래픽을 가로채는 구조와 충돌할 가능성이 있습니다.

3. 가능한 대안

Proxy를 통한 파일 전송이 어렵다면, 다른 방법을 고려해야 합니다.

3.1. SSH 터널링

SSH 터널을 활용하면 외부망에서 내부망의 SFTP 서버에 안전하게 접근할 수 있습니다.

ssh -L 2222:internal-sftp-server:22 user@proxy-server

위와 같이 설정하면, 로컬에서 localhost:2222로 접속하면 내부망의 SFTP 서버로 연결됩니다.

3.2. 데이터 중계 서버 활용

외부망과 내부망 사이에 중계 서버(베스천 호스트)를 두고, 외부망에서 중계 서버로 업로드한 후 내부망에서 가져가는 방식도 가능합니다.

3.3. 전용 파일 전송 솔루션 도입

SFTP 대신 HTTP 기반의 WebDAV 또는 MFT(Managed File Transfer) 솔루션을 활용할 수도 있습니다.

4. 결론

Nginx와 같은 HTTP Proxy는 SFTP를 처리할 수 없으며, HAProxy를 사용하더라도 SSH/SFTP의 특성상 원활한 프록싱이 어렵습니다. 대신, SSH 터널링, 데이터 중계 서버, 또는 전용 파일 전송 솔루션을 활용하는 것이 보다 현실적인 해결책이 될 수 있습니다.