WOOZOO LINUX

RHEL 8/9에서 GRUB Default Kernel을 확인하고 이전 커널로 변경하는 방법을 단계별로 안내합니다. GRUB Default Kernel 변경 방법: 커널 선택과 복구 전략 리눅스 시스템에서는 부팅 시 기본적으로 GRUB 설정에 따라 특정 커널이 로드됩니다. 이때 선택되는 커널을 Default Kernel 이라고 하며, 이는 리눅스의 핵심 구성요소로서 하드웨어와 소프트웨어를 제어하는 역할을 합니다. 커널에는 지속적으로 보안 패치와 기능 개선이 이루어지기 때문에, 시스템 운영 중 yum update 명령으로 커널을 종종 업데이트 하게됩니다. 이때 기존 커널을 덮어쓰고 업데이트 하는것이 아니라 새로운 커널이 별도로 설치되며, YUM은 최대 3개의 커널을 유지하면서 가장 오래된 커널을 순차적으로 제거합니다. 이는 새로운 커널이 시스템과 호환되지 않을 경우, 이전 커널로 부팅해 문제를 복구할 수 있도록 하기 위함으로 해석됩니다. 환경 Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 현재 커널 버전 확인 시스템 부팅 시 로드된 커널 버전을 확인하는 방법은 다음과 같습니다. 가장 많이 사용하는 방법으로는 uname 명령어 실행 또는 /proc/cmdline 파일을 열어서 확인해 보는 두 가지 방법이 있습니다. uname 사용 [root@rhel8 ~]# uname -r 4.18.0-513.24.1.el8_9.x86_64 /proc/cmdline 파일 확인 /proc 디렉터리 아래 위치한 파일의 경우 사용자가 생성하는 파일이 아니고 실행 중인 커널과 프로세스 정보 등을 담고 있는 특별한 파일이다. [root@rhel8 ~]# cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-513.24.1.el8_9.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.l...

 CVE 보안 패치용 RPM 패키지를 이용해 로컬 YUM 리포지토리를 구성하고, 여러 시스템에 손쉽게 업데이트하는 방법을 단계별로 설명합니다. 로컬 YUM 리포지토리를 구성하는 이유 보안 패치나 특정 패키지를 설치할 때 RPM 파일을 수동으로 다운로드한 후 yum localinstall 명령어로 설치할 수도 있지만, 의존성 문제를 해결하거나 여러 서버에 반복 배포할 경우 비효율적일 수 있습니다. YUM 리포지토리를 구성하면 패키지 관리가 자동화되어 설치와 업데이트가 훨씬 안정적으로 수행됩니다. 이번 글에서는 보안 취약점(CVE-2024-1086) 대응을 위해 준비된 18개의 패키지를 기반으로 로컬 YUM 리포지토리를 구성하고, 이를 통해 시스템에 커널 패치를 적용하는 과정을 설명합니다. CD 이미지를 이용한 방식이 아닌, 개별 패키지 기반 리포지토리 구성법입니다.  만약 CD 이미지를 local repo로 구성하는 방법을 원하시면 LOCAL REPO 를 참조하실 수 있습니다.   패키지 준비 및 메타데이터 생성 먼저 설치 대상인 RPM 파일들을 한 디렉터리에 모읍니다. 예제에서는 /root/cve-2024-1086 디렉터리에 커널 및 관련 패키지 18개를 준비했습니다. 이들은 모두 동일한 보안 패치 버전( 4.18.0-513.24.1.el8_9 )을 기반으로 합니다. [root@rhel8 cve-2024-1086]# pwd /root/cve-2024-1086 [root@rhel8 cve-2024-1086]# ls bpftool-4.18.0-513.24.1.el8_9.x86_64.rpm bpftool-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm kernel-4.18.0-513.24.1.el8_9.x86_64.rpm kernel-abi-stablelists-4.18.0-513.24.1.el8_9.noarch.rpm kernel-core-4.18.0-513.24.1.el8_9.x86_64.rpm k...

glibc iconv 보안 취약점 CVE-2024-2961 대응 방법과 RHEL 대상 패치 및 완화 조치 안내   glibc 보안 취약점 CVE-2024-2961 glibc는 리눅스 시스템에서 가장 핵심적인 라이브러리 중 하나로, 대부분의 배포판에 기본 포함되어 있습니다. 최근 공개된 CVE-2024-2961 취약점은 glibc의 iconv 라이브러리 중 ISO-2022-CN-EXT 플러그인에서 발생하며, 원격 코드 실행을 포함한 심각한 보안 위협을 초래할 수 있습니다. 해당 모듈이 활성화된 시스템은 공격에 노출될 가능성이 있어, 시스템 관리자는 즉시 패치를 적용하는 것이 권장됩니다.   영향 받는 버전 이번 취약점은 다음의 Red Hat Enterprise Linux 버전에 영향을 미칩니다. Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9   조치 방법: 패치 또는 모듈 비활성화 가장 권장되는 대응 방법은 glibc 패키지를 최신 버전으로 업데이트하는 것입니다. 그러나 특정 애플리케이션의 호환성 문제 등으로 인해 업데이트가 어려운 경우, 임시 조치로 ISO-2022-CN-EXT 모듈을 비활성화할하여 완화할 수 있습니다. glibc 업데이트   Red Hat Enterprise Linux 8: 최신 버전 : glibc-2.28-236.el8_9.13.x86_64.rpm 이상 버전으로 업데이트 또는, 프리미엄 서브스크립션의 경우 아래 EUS 패키지를 통한 업데이트가 가능합니다. RHEL8.6 EUS : glibc-2.28-189.10.el8_6.x86_64.rpm 이상 버전으로 업데이트 RHEL8.8 EUS : glibc-2.28-225.el8_8.11.x86_64.rpm 이상 버전으로 업데이트 새로 업데이트된 glibc 라이브러리를 적용하기 위해서는 프로그램을 재시작 해야 합니다. 거의 대부분의 프로그램에서 glib...

 OpenShift SNO 설치 후 Web Console에 접속하는 방법을 설명합니다. 콘솔 주소 확인, hosts 설정, 브라우저 접속까지 단계별로 안내합니다. OCP SNO 설치 후 Web Console 접속 개요 이 문서에서는 OpenShift Single Node (SNO) 클러스터를 설치한 후, Web Console에 접속하는 방법을 설명합니다. 설치를 완료하지 못하셨다면, 먼저 OCP SNO 설치 가이드 를 참고하시는 것이 좋습니다. OpenShift의 Web Console은 버전이 올라갈수록 개선되어 현재는 시각적으로도 직관적이고 사용하기 편리한 도구가 되었습니다. 특히 컨테이너나 Kubernetes 환경에 익숙하지 않은 사용자에게는 CLI보다 Web Console을 통한 서비스 생성 및 관리를 권장합니다. 초보자뿐 아니라 실무 환경에서도 이 인터페이스는 널리 사용됩니다. 요약 및 Web Console 주소 확인 방법 OpenShift는 설치만 완료되면 오퍼레이터에 의해 Web Console이 자동으로 기동됩니다. 즉, 별도의 설치 없이 콘솔 주소만 알면 바로 접속할 수 있습니다. 콘솔 주소는 보통 도메인 기반으로 접근하게 되며, 설치 방식에 따라 확인 방법이 다릅니다. Red Hat Cloud Console을 통한 assisted-installer 방식으로 설치했다면 설치 완료 후 웹에서 바로 주소를 확인할 수 있습니다. 터미널을 통해 확인하는 방법도 두 가지가 있으며, 이들에 대해 아래에서 자세히 설명합니다.   Web Console 주소 확인: CLI를 통한 두 가지 방법 첫 번째 방법은 OpenShift CLI에서 oc whoami --show-console 명령어를 사용하는 것입니다. 이 명령은 현재 로그인된 사용자의 콘솔 주소를 바로 출력해 줍니다. [root@api-int ~]# oc whoami --show-console <https://console-openshift-console.apps.sno.e...

기본적으로 SFTP 서버는 사용자 활동에 대한 로그를 기록하지 않습니다. 그러나 파일 송수신 중 문제를 해결하거나, 보안 정책상 사용자 기록을 추적해야 할 경우 로그 활성화가 필요합니다. 로그 활성화 방법은 아주 간단하며 레드햇 리눅스의 SSHD데몬에 포함된 기능중 하나인 sftp의 로그 설정 방법에 대해 알아봅니다.   환경 Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 기본 로그 설정: /var/log/messages에 기록하기 SFTP 로그를 남기기 위해서는 /etc/ssh/sshd_config 파일 내 Subsystem sftp 항목을 수정해야 합니다. 기본 설정은 다음과 같이 주석 처리한 후, 로그 레벨을 명시한 형태로 변경합니다. [root@rhel8 ~]# vim /etc/ssh/sshd_config ... # override default of no subsystems # Subsystem sftp /usr/libexec/openssh/sftp-server --> 기존 설정 주석 처리 Subsystem sftp /usr/libexec/openssh/sftp-server -l INFO ... -l <로그 레벨>: INFO 수준의 로그를 남김. 그 외 옵션으로는 QUIET, ERROR, DEBUG 등이 있으며, 로그 양에 따라 조절 가능합니다. -f <로그 채널(facility)>: possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 옵션에 관한 자세한 내용은 man 페이지를 참조할 수 있다. [root@rhel8 ~]# man sftp-server ... -f log_facility Specifies the facility code that is used ...

tshark를 이용해서 서버에서 DNS 조회를 하고 있는 모든 패킷을 추적하고 어느 프로세스가 사용하고 있는지 분석해 보도록 하겠습니다.   DNS 요청 트래픽 분석이 필요한 이유 최근 내부 DNS 서버의 서비스 종료 통보를 받으면서, 서버들이 어떤 도메인을 참조하고 있는지 파악할 필요가 생겼습니다. 그러나 현재 환경에서는 애플리케이션이 어떤 도메인을 사용하는지 확인할 수 있는 수단이 부족합니다. 이 글에서는 tshark를 활용해 DNS 트래픽을 캡처하고 분석하여 서버의 도메인 사용 현황을 파악하는 방법을 설명합니다. 또한 gethostlatency를 통해 DNS 요청을 발생시킨 프로세스까지 추적하는 방법도 함께 다룹니다. tshark 설치 및 기본 환경 분석 도구로 사용할 tshark 는 네트워크 트래픽을 캡처하고 필터링하는 기능을 갖춘 강력한 CLI 기반 도구입니다. dnf 명령으로 wireshark-cli 패키지를 설치하면 함께 포함됩니다. # dnf install wireshark-cli 이 문서에서 사용하는 테스트 환경은 다음과 같습니다. Red Hat Enterprise Linux 8 Red Hat Enterprise Linux 9 tshark로 DNS 요청과 응답 필터링 tshark 를 사용하면 실시간으로 DNS 요청과 응답을 캡처하고 구분할 수 있습니다. 필터 dns.flags.response 값을 기준으로 요청( 0 )과 응답( 1 )을 구분할 수 있습니다. DNS 요청만 캡처하기 다음 명령어를 사용하여 실시간으로 DNS 요청을 캡처할 수 있습니다. # tshark -i any -Y "dns.flags.response == 0" Running as user "root" and group "root". This could be dangerous. Capturing on 'any' 10 1.772920969 192.168.155.84 → 8.8.8...

RHEL9에서 SHA1 암호화 지원이 필요한 레거시 시스템과의 SSH 접속 문제 해결 방법을 설명합니다.   개요 RHEL9 시스템에서 RHEL6이나 AIX 7.2와 같은 레거시 시스템으로 SSH 접속 시 암호화 방식 불일치로 인해 연결 오류가 발생할 수 있습니다. 본 문서에서는 이 문제를 해결하기 위해 SHA1 알고리즘을 시스템 정책에 포함시키는 방법을 설명합니다. 문제 설명 RHEL9에서 RHEL6 시스템으로 SSH 접속을 시도하면 다음과 같은 오류가 발생합니다 Unable to negotiate with 192.168.155.60 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 이는 RHEL9의 기본 암호화 정책( DEFAULT )이 SHA1 기반의 키 교환 알고리즘을 지원하지 않기 때문입니다. 정책을 DEFAULT:SHA1 로 변경하면 이러한 알고리즘을 포함시켜 문제를 해결할 수 있습니다. 시스템 버전 별 에러 로그 RHEL9 → AIX7 # ssh -vvv aix7 ... debug1:send_pubkey_test: no mutual signature algorithm ... RHEL9 → RHEL6 Unable to negotiate with 192.168.155.60 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss RHEL6 → RHEL9 no hostkey alg 이처럼 상호 인증에 필요한 암호화 알고리즘이 맞지 않으면 연결이 이루어지지 않습니다. 해결 방법: 암호화 정책 변경 1) 암호화 정책 변경 SHA1 기반 알고리즘을 허용하려면 시스템 암호화 정책을 변경해야 합니다. 다음 명령어로 SHA1을 포함하도록 설정합니다 # upda...