집 > 고장 > 우분투에서 안전하게 서핑하세요. Ubuntu에서 안전한 서핑 불필요한 서비스 비활성화


우분투에서 안전하게 서핑하세요. Ubuntu에서 안전한 서핑 불필요한 서비스 비활성화





많은 사용자는 Ubuntu를 대중적인 것으로 간주하고 Ubuntu Server는 심각하지 않다고 생각합니다. 많은 사람들은 Ubuntu Server가 5년 동안 지원되었고 Debian 5.0이 2009년부터 2012년까지 3년 동안 시장에 출시되었다는 사실을 잊어버립니다.

지원 가격 - Red Hat과 비교했을 때 Ubuntu Server는 말할 수 있고 말해야 합니다. 연중무휴 24시간 지원을 주문하더라도 무료로 받을 수 있습니다.

Ubuntu의 모든 버전에 어떤 보안 솔루션이 구현되어 있는지 확인하고 이를 안전하고 안정적으로 만드세요.

가능성

보안 기능 매트릭스

기회 8.04 LTS(하디 헤론) 10.04 LTS(루시드 링크스) 11.04 (나티 일각고래) 11.10 (오니릭 오셀롯) 12.04 LTS(정확한 천산갑) 12.10 (퀀탈 케찰)
열린 포트 없음 정책 정책 정책 정책 정책 정책
비밀번호 해시 MD5 샤512 샤512 샤512 샤512 샤512
SYN 쿠키 -- 커널 및 sysctl 커널 및 sysctl 커널 및 sysctl 커널 및 sysctl 커널 및 sysctl
파일 시스템 기능 -- 핵심 핵심 핵심 핵심 핵심
구성 가능한 방화벽 으악 으악 으악 으악 으악 으악
PR_SET_SECCOMP 핵심 핵심 핵심 핵심 핵심 핵심
앱아머 2.1 2.5 2.6.1 2.7.0~베타1 2.7.0 2.7.0
SELinux 우주 우주 우주 우주 우주 우주
헤로인 -- 핵심 핵심 핵심 핵심 핵심
암호화된 LVM 대체 설치 프로그램 대체 설치 프로그램 대체 설치 프로그램 대체 설치 프로그램 대체 설치 프로그램 대체 설치 프로그램
eCryptfs -- ~/개인 또는 ~, 파일 이름 ~/개인 또는 ~, 파일 이름 ~/개인 또는 ~, 파일 이름 ~/개인 또는 ~, 파일 이름 ~/개인 또는 ~, 파일 이름
스택 보호 gcc 패치 gcc 패치 gcc 패치 gcc 패치 gcc 패치 gcc 패치
힙 보호 glibc glibc glibc glibc glibc glibc
난독화된 포인터 glibc glibc glibc glibc glibc glibc
ASLR 스택 핵심 핵심 핵심 핵심 핵심 핵심
Libs/mmap ASLR 핵심 핵심 핵심 핵심 핵심 핵심
실행 ASLR 커널(-mm 패치) 핵심 핵심 핵심 핵심 핵심
brk ASLR 커널(ASLR 실행) 핵심 핵심 핵심 핵심 핵심
VDSO ASLR 핵심 핵심 핵심 핵심 핵심 핵심
PIE로 빌드하기 -- 패키지 목록 패키지 목록 패키지 목록 패키지 목록 패키지 목록
-- gcc 패치 gcc 패치 gcc 패치 gcc 패치 gcc 패치
RELRO를 이용한 조립 -- gcc 패치 gcc 패치 gcc 패치 gcc 패치 gcc 패치
BIND_NOW를 사용하여 빌드 -- 패키지 목록 패키지 목록 패키지 목록 패키지 목록 패키지 목록
비실행 메모리 PAE만 해당 PAE, ia32 부분 NX 에뮬레이션 PAE, ia32 부분 NX 에뮬레이션 PAE, ia32 부분 NX 에뮬레이션 PAE, ia32 부분 NX 에뮬레이션
/proc/$pid/maps 보호 커널 및 sysctl 핵심 핵심 핵심 핵심 핵심
심볼릭 링크의 한계 -- -- 핵심 핵심 핵심 핵심
하드 링크의 한계 -- -- 핵심 핵심 핵심 핵심
ptrace 범위 -- -- 핵심 핵심 핵심 핵심
0-주소 보호 커널 및 sysctl 핵심 핵심 핵심 핵심 핵심
/dev/mem 보호 커널(-mm 패치) 핵심 핵심 핵심 핵심 핵심
/dev/kmem 비활성화됨 커널(-mm 패치) 핵심 핵심 핵심 핵심 핵심
모듈 로딩 차단 CAP_SYS_MODULES 삭제 sysctl sysctl sysctl sysctl sysctl
핵심 핵심 핵심 핵심 핵심 핵심
커널 스택 보호 -- 핵심 핵심 핵심 핵심 핵심
RO/NX 모듈 -- -- 핵심 핵심 핵심 핵심
-- -- 핵심 핵심 핵심 핵심
-- -- 핵심 핵심 핵심 핵심
시스템 호출 필터링 -- -- -- 핵심 핵심 핵심

열린 포트 없음

기본 Ubuntu 설치에는 네트워크 외부에서 액세스할 수 있는 열린 포트가 없습니다. 이 규칙의 유일한 예외는 DHCP 클라이언트 및 mDNS(Avahi/ZeroConf)와 같은 네트워크 인프라 서비스입니다.

Ubuntu Server가 설치되면 관리자는 Apache 웹 서버와 같은 추가 네트워크 서비스를 설치할 수 있습니다. 그러나 기본적으로 새로 설치된 시스템에서 netstat -an --inet | grep 듣기 | grep -v 127.0.0.1 그러면 Ubuntu가 네트워크에서 시스템에 액세스하기 위해 포트를 불필요하게 열지 않는지 쉽게 확인할 수 있습니다.

비밀번호 해시

Ubuntu에 로그인하는 데 사용되는 시스템 비밀번호는 /etc/shadow에 저장됩니다. 옛날에는 DES 비밀번호 해시가 /etc/passwd에 저장되었습니다. 하지만 최신 Linux는 오랫동안 /etc/shadow에 해시를 저장해 왔으며 처음에는 salt가 포함된 MD5 기반 해시를 사용했습니다(salted MD5 기반 해시 crypt id 1). 솔트를 사용하지 않고도 동일한 비밀번호에 동일한 해시가 있으므로 솔트를 도입하면 보안이 향상되고 시스템의 많은 사용자의 비밀번호를 해독하기가 더 어려워졌습니다.

이제 MD5는 신뢰할 수 없는 것으로 간주되며 컴퓨터의 컴퓨팅 성능이 향상됨에 따라 Ubuntu 8.10에서는 솔트가 포함된 SHA-512 해시가 사용됩니다(솔티드 SHA-512 기반 비밀번호 해시 crypt id 6). 이로 인해 모든 옵션을 엄청나게 어렵고 시간 소모적으로 시도함으로써 무차별 대입 해킹이 이루어집니다.

man crypt에 대한 자세한 내용.

테스트에는 test-glibc-security.py를 사용하세요.

SYN 쿠키

시스템이 새로운 네트워크 연결로 인해 초과되면 SYN 쿠키 메커니즘은 SYN 초과 공격으로 인한 피해를 줄이는 데 도움이 됩니다.

파일 시스템 기능

xattrs와 같은 파일 시스템 기능을 사용하면 실행하는 사람보다 더 높은 권한으로 실행되는 setuid 응용 프로그램의 필요성을 줄일 수 있습니다. 이러한 기능은 잠재적으로 위험한 setuid 응용 프로그램의 남용 위험을 줄여줍니다.

Linux 커널은 setuid 애플리케이션의 보안을 강화하기 위해 xattrs 유형 파일 기능을 사용하기 위한 libcap2-bin 지원 및 도구를 제공합니다.

테스트에는 test-kernel-security.py를 사용하세요.

구성 가능한 방화벽

ufw는 Ubuntu에 설치되어 사용되는 iptables의 프런트엔드이지만 사용자가 독립적으로 활성화해야 합니다. UFW는 체인 및 테이블과 함께 iptables 방화벽의 개념에 익숙하지 않은 사람들을 위해 사용하기 쉬운 인터페이스를 제공하도록 설계되었습니다.

동시에 UFW는 복잡한 iptables 명령을 단순화하여 자신이 하는 일을 알고 있는 관리자를 돕습니다.

UFW는 보조자이자 그래픽 프론트엔드의 기초입니다.

테스트에는 ufw 테스트를 사용하십시오.

PR_SET_SECCOMP

앱아머

SELinux

SELinux는 파일 시스템 인덱스 설명자인 inode 개념을 기반으로 하는 필수 액세스 제어 시스템입니다.

selinux 패키지를 설치하면 PC가 부팅되는 동안 필요한 변경 및 조정이 이루어집니다.

테스트에는 test-kernel-security.py를 사용하세요.

헤로인

SMACK은 파일 시스템 인덱스 설명자인 inode 개념을 기반으로 하는 유연한 필수 액세스 제어 시스템입니다.

테스트에는 test-kernel-security.py를 사용하세요.

파일 시스템 암호화

LVM 암호화

대체 설치 프로그램을 사용하는 사용자는 스왑 파티션을 포함한 모든 파티션을 암호화하는 암호화된 LVM(논리 볼륨 관리)에 Ubuntu를 설치할 수 있습니다.

eCryptfs

암호화된 폴더는 Ubuntu 8.10에서 중요한 사용자 정보를 저장하는 안전한 장소로 처음 구현되었습니다.

대체 및 서버 디스크 설치 프로그램을 사용하면 첫 번째 사용자에 대해 암호화된 폴더를 설정할 수 있습니다.

Ubuntu 9.04에서는 폴더 암호화 지원이 확장되었으며 사용자는 전체 홈 폴더를 암호화할 수 있었습니다. 홈 폴더 암호화는 user-setup/encrypt-home=true 매개변수를 통해 대체 설치 프로그램 및 데스크탑 설치 프로그램에서 지원됩니다.

사용자 공간 보안 강화

소프트웨어 패키지와 커널을 빌드할 때 많은 보안 기능이 컴파일 플래그를 통해 구현됩니다.

스택 보호

gcc -fstack-protector 플래그는 작은 난수를 마커로 배치하여 스택 오버플로 보호를 제공합니다. 이 방법을 사용하면 다양한 공격에 대한 스택 오버플로가 더 어려워집니다.

소수의 프로그램이 이 매개변수로 컴파일되고 해당 프로그램에 대해 -fstack-protector가 비활성화되면 제대로 작동하지 않습니다.

테스트에는 test-gcc-security.py를 사용하세요.

힙 보호

GNU C 라이브러리 힙 보호(ptmalloc에 ​​의한 자동 및 수동)는 glibc 메모리 관리자에서 손상된 목록/링크 해제/이중 해제/오버플로 보호를 제공합니다.

이렇게 하면 힙 메모리 오버플로를 통해 임의 코드가 실행되어 힙 영역의 구조가 손상될 가능성이 방지됩니다.

이 방어는 시간이 지남에 따라 발전하여 점점 더 많은 방어 옵션이 추가되었습니다. 현재 상태에서 glibc 2.10은 미묘한 공격 조건에도 성공적으로 저항합니다.

난독화된 포인터

일부 glibc 포인터는 glibc 내부적으로 PTR_MANGLE/PTR_UNMANGLE 매크로를 통해 난독화되어 런타임 시 포인터가 덮어쓰이는 것을 방지합니다.

test-glibc-security.py 테스트를 사용하세요.

주소 공간에 무작위로 배치됩니다. ASLR(주소 공간 레이아웃 무작위화)

ASLR은 커널에서 구현되며 ELF 로더는 스택, 힙, 공유 라이브러리 등 가장 중요한 구조를 임의의 주소에 배치합니다.

이로 인해 공격자가 익스플로잇을 시도할 때 주소를 예측하기가 어렵습니다.

ASLR은 /proc/sys/kernel/randomize_va_space를 통해 전역적으로 변경됩니다. Ubuntu 8.10 이전에는 값이 "1"(활성화)이었습니다. brk ASLR을 포함하는 이후 릴리스에서는 값이 "2"(brk ASLR로 활성화됨)로 설정됩니다.

ASLR 스택

각 프로그램 실행의 결과는 스택의 다른 부분에 배치됩니다. 메모리 내에서 찾아 악성 페이로드를 추가하여 프로그램을 공격하는 것은 어렵습니다.

Libs/mmap ASLR

라이브러리는 다양한 메모리 위치에 동적으로 로드되므로 공격자가 반환 지점을 찾기가 어렵습니다.

보호 기능은 커널 2.6.15(Ubuntu 6.06)에서 사용할 수 있습니다.

실행 ASLR

"-fPIE -pie" 옵션으로 작성된 프로그램은 다른 메모리 위치에 로드됩니다. 이는 메모리 수정 공격을 수행하기 위해 공격하거나 주소로 점프하는 것을 어렵게 만듭니다.

보호 기능은 커널 2.6.25(Ubuntu 8.04 LTS)에서 사용할 수 있습니다.

brk ASLR

exec ASLR과 마찬가지로 brk ASLR은 작은 메모리 할당 요청에 대해 exec와 brk 간의 메모리 주소를 조절합니다. 무작위화 brk exec 메모리 오프셋이 커널 2.6.26(Ubuntu 8.10)에 추가되었습니다.

VDSO ASLR

프로그램이 실행될 때마다 결과는 다른 vdso에 배치됩니다. 커널 2.6.18(x86, PPC) 및 2.6.22(x86_64)에 처음 등장했지만 Ubuntu 8.04 LTS에서 제거된 COMPAT_VDSO로 인해 Ubuntu 6.10에는 포함되지 않았습니다.

syscall 공격에 대한 점프를 방지합니다.

glibc 2.6에서는 x86만 지원되었습니다. glibc 2.7(Ubuntu 8.04 LTS)은 이미 x86_64 ASLR vdso를 지원했습니다.

libc6 이전의 정적 vdso가 필요한 사용자는 "vdso=2"를 커널 매개변수로 사용하고 COMPAT_VDSO를 다시 얻을 수 있습니다.

PIE로 빌드하기

"-fPIE -pie" 옵션을 사용하여 PIE(위치 독립적 실행 파일)로 컴파일된 모든 프로그램은 exec ASLR 보호를 활용할 수 있습니다.

이는 "텍스트로 복귀" 공격으로부터 보호하고 기존의 메모리 수정 공격을 쓸모없게 만듭니다.

PIE로 인해 소수의 범용 레지스터(예: x86)가 있는 아키텍처에서는 성능이 크게 저하(5-10%)됩니다.

따라서 PIE는 보안이 중요한 소수의 패킷에 사용됩니다.

x86_64용 PIE는 성능 문제가 없으며 모든 패키지에 사용되지만 더 나은 테스트가 필요합니다.

비닐 봉투 8.04 LTS 9.04 9.10 10.04 LTS 10.10 11.04 11.10
openssh 예 예 예 예 예 예 예
아파치2 -- 예 예 예 예 예 예
바인드9 -- 예 예 예 예 예 예
오픈랩 -- 예 예 예 예 예 예
접미사 -- 예 예 예 예 예 예
컵 -- 예 예 예 예 예 예
postgresql-8.3 -- 예 예 예 예 예 예
삼바 -- 예 예 예 예 예 예
비둘기장 -- 예 예 예 예 예 예
DHCP3 -- 예 예 예 예 예 예
ntp -- -- 예 예 예 예 예
amavisd-new -- -- 예 예 예 예 예
오징어 -- -- 예 예 예 예 예
사이러스-sasl2 -- -- 예 예 예 예 예
엑심4 -- -- 예 예 예 예 예
나기오스3 -- -- 예 예 예 예 예
nagios 플러그인 -- -- 예 예 예 예 예
xinetd -- -- 예 예 예 예 예
IPsec 도구 -- -- 예 예 예 예 예
mysql-dfsg-5.1 -- -- 예 예 예 예 예
증거하다 -- -- -- 예 예 예 예
파이어폭스 -- -- -- 예 예 예 예
그놈 제어 센터 -- -- -- -- -- 예 예
사소한 말다툼 -- -- -- -- -- 예 예
토템 -- -- -- -- -- 예 예
qemu-kvm -- -- -- -- -- -- 예
피진 -- -- -- -- -- -- 예

Fortify Source로 구축

"-D_FORTIFY_SOURCE=2"(및 -O1 이상)로 빌드된 프로그램은 glibc에서 여러 컴파일 및 런타임 보호를 활성화합니다.

  • 경계가 정의되지 않은 "sprintf", "strcpy" 호출은 버퍼 크기가 미리 알려진 경우 N이 제한된 관련 함수로 대체됩니다. 이는 메모리 오버플로를 방지합니다.
  • 문자열이 쓰기 액세스 권한이 있는 메모리 세그먼트에 있는 경우 문자열 형식 "%n"을 통해 공격을 중지합니다.
  • 가장 중요한 함수와 인수(예: 시스템, 쓰기, 열기)의 반환 코드를 확인해야 합니다.
  • 파일을 생성할 때 마스크를 명시적으로 표시해야 합니다.

RELRO를 이용한 조립

부트로더 메모리 덮어쓰기를 방지하기 위해 ELF 프로그램을 강화합니다. GOT 덮어쓰기 스타일 공격의 가능성을 줄입니다.

test-gcc-security.py 테스트를 사용하세요.

BIND_NOW를 사용하여 빌드

"즉시 바인딩"이라고도 하는 온디맨드 대신 시작 시 동적 문자를 확인하도록 ELF 프로그램을 표시합니다.

이는 RELRO 매개변수와 결합하여 GOT를 완전히 읽기 전용으로 만듭니다.

test-build-binaries.py 테스트를 사용하세요.

비실행 메모리

최신 프로세서는 코드 실행으로부터 데이터 메모리 영역(힙, 스택)을 보호합니다.

이 기술을 NX(Non-eXecute) 또는 XD(eXecute-Disable)라고 합니다. 보호는 공격자가 임의 코드를 배치할 수 있는 능력을 감소시킵니다.

보호에는 3GB 이상의 RAM 주소 지정을 허용하는 "PAE"가 필요합니다. 64비트 및 32비트 -server 및 -generic-pae 커널은 이미 PAE로 구축되었습니다.

Ubuntu 9.10부터 보호는 NX 하드웨어를 지원하지 않는 프로세서의 32비트 코어에서 부분적으로 에뮬레이션됩니다.

다운로드 후 NX 보호 지원 수준을 확인할 수 있습니다.

  • 하드웨어: [ 0.000000] NX(실행 비활성화) 보호: 활성
  • 에뮬레이션:
    [ 0.000000] x86 세그먼트 제한을 사용하여 NX 보호에 근접

NX에 대한 언급이 없으면 BIOS 설정을 확인하세요. Ubuntu 11.04부터 NX의 BIOS 설정은 커널에서 무시됩니다.

우분투 9.04 이하
CPU는 NX를 지원합니다 CPU는 NX를 지원하지 않습니다
BIOS에서 NX 활성화 NX는 BIOS에서 비활성화되어 있습니다.
i386 -386, -일반 커널(비PAE) nx는 지원되지 않습니다 nx는 지원되지 않습니다 nx는 지원되지 않습니다
-서버 커널(PAE) 진짜 nx nx는 지원되지 않습니다 nx는 지원되지 않습니다
amd64 모든 커널(PAE) 진짜 nx nx는 지원되지 않습니다 nx는 지원되지 않습니다

test-kernel-security.py 테스트를 사용하세요.

/proc/$pid/maps 보호

ASLR이 실행 중이면 프로세스의 현재 메모리 맵이 공격자에게 매우 중요해집니다. 맵 파일은 프로세스 자체와 프로세스 소유자만 읽을 수 있습니다.

커널 2.6.22부터 사용 가능합니다.

test-kernel-security.py 테스트를 사용하세요.

심볼릭 링크의 한계

이 결함을 악용하는 가장 일반적인 방법은 루트 권한으로 악의적인 작업을 수행하기 위해 공격자가 만든 심볼릭 링크를 루트가 사용하도록 강제하는 것입니다.

Ubuntu 10.10부터 /tmp와 같은 디렉토리의 심볼릭 링크는 "팔로어"와 디렉토리의 소유자가 심볼릭 링크의 소유자와 동일하지 않으면 따라갈 수 없습니다.

이 메커니즘은 Yama 메커니즘 /proc/sys/kernel/yama/protected_sticky_symlinks에 의해 제어됩니다. Yama는 Canonical에서 개발했습니다.

test-kernel-security.py 테스트를 사용하세요.

하드 링크의 한계

/etc/ 및 /home/ 디렉터리가 동일한 파티션에 있는 경우 일반 사용자는 홈 폴더에 비밀번호 해시를 사용하여 /etc/shadow 파일에 대한 하드 링크를 만들 수 있습니다. 물론 사용자가 특정 파일을 읽거나 쓸 수 없는 경우 해당 파일에 대한 하드 링크는 동일한 권한을 가지므로 해당 사용자도 액세스할 수 없습니다. 그러나 하드 링크를 사용하면 공격자는 해당 파일에 액세스할 수 있는 권한이 있는 응용 프로그램에 해당 파일을 "미끄러뜨릴" 수 있습니다.

Yama를 사용하면 소스 파일에 액세스할 수 있는 권한이 없는 사용자가 하드 링크를 생성하는 것을 방지하여 이 공격을 차단할 수 있습니다.

동작은 /proc/sys/kernel/yama/protected_nonaccess_hardlinks Yama에 의해 제어됩니다.

ptrace 범위

적절한 Yama 보호가 없으면 CAP_SYS_PTRACE 권한이 있는 모든 프로세스는 동일한 UID를 가진 모든 프로세스의 메모리에 액세스할 수 있습니다. Yama를 사용하면 해당 프로세스의 자손이 소유한 메모리로만 액세스 범위를 제한할 수 있습니다.

Ubuntu 10.10 이하에서는 사용자가 ptrace의 하위 항목이 아닌 이상 ptrace를 사용하여 프로세스를 디버그할 수 없습니다.

동작은 /proc/sys/kernel/yama/ptrace_scope Yama에 의해 제어됩니다.

test-kernel-security.py 테스트를 사용하세요.

커널 보호 강화

공격을 더욱 어렵게 만들기 위해 커널 방어 메커니즘을 활성화했습니다.

0-주소 보호

커널과 사용자 공간은 가상 메모리 주소를 공유하므로 "NULL" 메모리는 보호되어야 하며 "사용자" 메모리는 주소 0에서 시작할 수 없습니다. 이를 통해 커널 주소 역참조("NULL 역참조" 공격)를 방지할 수 있습니다.

보호는 sysctl 매개변수 "mmap_min_addr"을 통해 커널 2.6.22부터 가능합니다. Ubuntu 9.04부터 mmap_min_addr은 커널에 내장되어 있습니다. 주소는 x86의 경우 64k, ARM의 경우 32k입니다.

test-kernel-security.py 테스트를 사용하세요.

/dev/mem 보호

Xorg와 같은 일부 응용 프로그램은 사용자 공간의 물리적 메모리에 직접 액세스해야 합니다. 특수 파일 /dev/mem이 이러한 액세스를 제공합니다.

과거에는 공격자가 루트 접근 권한을 얻으면 이 파일을 통해 커널 메모리를 보고 수정하는 것이 가능했다.

이러한 시도를 차단하기 위해 CONFIG_STRICT_DEVMEM 옵션이 도입되었습니다(이 옵션은 원래 CONFIG_NONPROMISC_DEVMEM이라고 함).

test-kernel-security.py 테스트를 사용하세요.

/dev/kmem 비활성화됨

현대 사용자의 경우 /dev/kmem은 공격자가 루트킷을 다운로드하는 데 주로 사용했기 때문에 관련이 없습니다.

CONFIG_DEVKMEM은 이제 "n"으로 설정됩니다.

/dev/kmem 파일은 Ubuntu 8.04 LTS에서 Ubuntu 9.04까지의 릴리스에 존재하지만 커널의 어떤 것과도 연결되지 않았으며 사용되지 않습니다.

test-kernel-security.py 테스트를 사용하세요.

모듈 로딩 차단

Ubuntu 8.04 LTS 및 이전 버전에서는 CAP_SYS_MODULES 기능을 제거하여 새 커널 모듈의 로드를 방지할 수 있었습니다.

이는 손상된 시스템이 시작될 때 루트킷 다운로드를 방지하기 위한 또 다른 수준의 보호였습니다.

커널 2.6.25(Ubuntu 8.10)에서는 이 기능이 사라졌습니다. Ubuntu 9.10부터 /proc/sys/kernel/modules_disabled를 "1"로 설정하여 모듈을 다시 비활성화할 수 있습니다.

test-kernel-security.py 테스트를 사용하세요.

읽기 전용 데이터 섹션

커널 데이터 섹션을 읽기 전용으로 표시하면 변경 사항이 차단됩니다. 이는 일부 루트킷으로부터 보호하는 데 도움이 됩니다. CONFIG_DEBUG_RODATA 옵션을 통해 활성화됩니다.

test-kernel-security.py 테스트를 사용하세요.

커널 스택 보호

사용자 공간에서 ELF 프로그램을 보호하는 것처럼 커널은 CONFIG_CC_STACKPROTECTOR 옵션을 통해 내부 스택을 보호할 수 있습니다.

test-kernel-security.py 테스트를 사용하세요.

RO/NX 모듈

이 기능은 로드된 커널 모듈에 대한 제한 사항을 포함하도록 CONFIG_DEBUG_RODATA를 확장합니다. 이는 악용을 방지하는 데 도움이 됩니다. CONFIG_DEBUG_MODULE_RONX 매개변수를 통해 활성화됩니다.

test-kernel-security.py 테스트를 사용하세요.

커널 주소 표시 제한

공격자가 커널 취약점을 사용하여 어디서나 공격을 개발하려고 시도할 때 내부 커널 구조의 위치를 ​​알아야 합니다.

커널 주소는 중요한 정보로서 일반 사용자에게는 제공되지 않습니다.

Ubuntu 11.04부터 /proc/sys/kernel/kptr_restrict가 "1"로 설정되어 커널 주소 정보 유출을 차단합니다.

또한 각종 파일과 디렉토리를 루트만 읽을 수 있도록 만들어 놓았습니다.
/boot/vmlinuz*, /boot/System.map*, /sys/kernel/debug/, /proc/slabinfo

test-kernel-security.py 테스트를 사용하세요.

희귀 프로토콜 블랙리스트

일반적으로 커널은 MODULE_ALIAS_NETPROTO(PF_...) 매크로를 통해 요청 시 모든 네트워크 프로토콜이 자동으로 로드되도록 허용합니다.

이러한 프로토콜 중 다수는 오래되고 드물며 일반 Ubuntu 사용자에게는 거의 사용되지 않고 알려지지 않은 취약점을 포함할 수 있으므로 Ubuntu 11.04부터 블랙리스트에 올랐습니다.

블랙리스트: ax25, netrom, x25, rose, decnet, econet, rds 및 af_802154.

이러한 프로토콜이 필요한 경우 modprobe를 통해 또는 /etc/modprobe.d/blacklist-rare-network.conf를 편집하여 로드할 수 있습니다.

test-kernel-security.py 테스트를 사용하세요.

시스템 호출 필터링

프로그램은 seccomp_filter를 사용하여 커널 호출을 필터링할 수 있습니다.

이는 잠재적으로 신뢰할 수 없는 소프트웨어를 더욱 제한하기 위해 컨테이너 또는 샌드박스에서 수행됩니다.

test-kernel-security.py 테스트를 사용하세요.

결론

읽은 후에는 다음이 분명합니다. Canonical은 Ubuntu 보안을 중요하게 생각합니다.. AppArmor와 Yama라는 두 프로젝트는 오랫동안 Ubuntu와 연관되어 보안 개선에 도움을 주었습니다. Ubuntu는 기본적으로 네트워크에서 불필요한 포트 도어를 열지 않으며 연결 모험이 올 때까지 기다리지 않습니다. 네트워크와 함께 작동하는 주요 프로그램에 대해 AppArmor 프로필이 생성되어 프로그램을 점검합니다.

Ubuntu를 사용하면 컴퓨터가 안전해집니다!

Linux OS를 실행하는 서버가 가장 안전하고 외부 침입으로부터 보호된다는 일반적인 오해가 있습니다. 불행하게도 이는 사실이 아니며 모든 서버의 보안은 이를 보장하기 위한 다양한 요소와 조치에 따라 달라지며 실제로 사용되는 운영 체제와는 독립적입니다.

우리는 Ubuntu Server를 사용한 네트워크 보안에 관한 일련의 기사를 시작하기로 결정했습니다. 왜냐하면 이 플랫폼의 솔루션은 독자들에게 큰 관심을 갖고 있고 많은 사람들이 Linux 솔루션 자체가 안전하다고 믿기 때문입니다.

동시에, 전용 IP 주소를 가진 라우터는 로컬 네트워크에 대한 "게이트"이며, 이 게이트가 신뢰할 수 있는 장벽이 될지 아니면 폐쇄된 국가 게이트로 판명될지는 관리자에게만 달려 있습니다. 못.

또 다른 일반적인 오해는 "누가 그것을 필요로 하는지, 우리 서버는 흥미롭지 않습니다."라는 스타일로 추론하는 것입니다. 실제로, 로컬 네트워크는 공격자에게 아무런 관심이 없을 수도 있지만 해킹된 서버를 사용하여 스팸을 보내고 다른 서버에 대한 공격, 즉 익명 프록시를 음흉한 거래의 출발점으로 사용할 수 있습니다.

그리고 이것은 이미 불쾌하며 공급자부터 법 집행 기관에 이르기까지 다양한 문제의 원인이 될 수 있습니다. 그리고 바이러스 확산, 중요한 정보의 도난 및 파괴뿐만 아니라 기업의 가동 중지 시간으로 인해 상당한 손실이 발생한다는 사실을 잊어서는 안됩니다.

이 기사가 Ubuntu Server에 관한 것이라는 사실에도 불구하고 먼저 모든 플랫폼에 동일하게 적용되고 기본인 일반적인 보안 문제를 살펴보겠습니다. 이 문제가 없으면 문제를 더 자세히 논의할 필요가 없습니다.

안전은 어디에서 시작되나요?

아니요, 보안은 방화벽에서 시작되지 않으며 전혀 하드웨어에서 시작되지 않으며 보안은 사용자로부터 시작됩니다. 결국, 주인이 열쇠를 양탄자 아래에 남겨둔다면 최고의 전문가가 설치한 가장 멋진 금속 문이 무슨 소용이 있을까요?

따라서 가장 먼저 해야 할 일은 보안 감사를 실시하는 것입니다. 이 단어에 겁먹지 마십시오. 모든 것이 그렇게 복잡하지는 않습니다. 안전 구역, 잠재적 위험 구역 및 고위험 구역을 표시하는 개략적인 네트워크 계획을 그리고 다음을 수행해야 하는 사용자 목록을 작성하십시오. 액세스) 이 영역에 액세스합니다.

안전지대에는 외부에서 접근이 불가능하고 낮은 수준의 보안이 허용되는 내부 네트워크 자원이 포함되어야 합니다. 워크스테이션, 파일 서버 등이 될 수 있습니다. 액세스가 기업 로컬 네트워크로 제한되는 장치.

잠재적인 위험 영역에는 외부 네트워크에 직접 액세스할 수 없지만 개별 서비스를 외부에서 액세스할 수 있는 서버 및 장치가 포함됩니다. 예를 들어 방화벽 뒤에 있는 웹 및 메일 서버는 여전히 외부 네트워크의 요청을 처리합니다.

위험 구역에는 외부에서 직접 접근할 수 있는 장치가 포함되어야 하며, 이상적으로는 하나의 라우터여야 합니다.

가능하다면 잠재적으로 위험한 구역은 별도의 서브넷, 즉 추가 방화벽으로 주 네트워크와 분리된 비무장지대(DMZ)에 배치해야 합니다.

LAN 장치는 DMZ에서 필요한 서비스(예: SMTP, POP3, HTTP 등)에만 액세스할 수 있어야 하며 기타 연결은 차단되어야 합니다. 이를 통해 비무장지대에 있는 별도 서비스의 취약점을 이용하는 공격자나 악성 코드를 안정적으로 격리하여 주 네트워크에 대한 액세스를 거부할 수 있습니다.

물리적으로는 별도의 서버/하드웨어 방화벽을 설치하거나 라우터에 추가 네트워크 카드를 추가하여 DMZ를 구성할 수 있지만 후자의 경우 라우터의 보안에 세심한 주의를 기울여야 합니다. 그러나 어떤 경우에도 서버 그룹보다 단일 서버의 보안을 보장하는 것이 훨씬 쉽습니다.

다음 단계는 사용자 목록을 분석하여 DMZ와 라우터(공공 서비스 제외)에 모두 액세스해야 하는지 여부를 분석하는 것입니다. 외부에서 연결하는 사용자에게는 특별한 주의를 기울여야 합니다.

일반적으로 이를 위해서는 비밀번호 정책을 시행하는 매우 인기 없는 단계가 필요합니다. 중요한 서비스에 액세스할 수 있고 외부로 연결할 수 있는 사용자의 모든 비밀번호는 6자 이상이어야 하며 소문자 외에도 대문자, 숫자, 알파벳이 아닌 문자 등 세 가지 범주 중 두 가지 범주의 문자를 포함해야 합니다.

또한 비밀번호에는 사용자 로그인이나 그 일부가 포함되어서는 안 되며, 사용자와 연관될 수 있는 날짜나 이름도 포함되어서는 안 되며, 사전에 나오는 단어가 아니어야 합니다.

30~40일마다 비밀번호를 변경하는 습관을 들이는 것이 좋습니다. 이러한 정책으로 인해 사용자가 거부할 수 있다는 점은 분명하지만 다음과 같은 비밀번호는 항상 기억해야 합니다. 123 또는 쿼티양탄자 밑에 열쇠를 두는 것과 같습니다.

서버 보안 - 추가 사항은 없습니다.

이제 우리가 무엇을 보호하고 싶은지, 무엇으로부터 보호하고 싶은지 생각하고 서버 자체로 넘어 갑시다. 모든 서비스 및 서비스 목록을 작성한 다음 이 특정 서버에 모두 필요한지 아니면 다른 곳으로 이동할 수 있는지 생각해 보세요.

서비스 수가 적을수록 보안을 보장하기가 더 쉽고 서비스 중 하나의 심각한 취약점으로 인해 서버가 손상될 가능성이 줄어듭니다.

로컬 인터페이스에서만 요청을 수락하도록 로컬 네트워크(예: squid)를 제공하는 서비스를 구성합니다. 외부에서 사용 가능한 서비스가 적을수록 좋습니다.

취약점 스캐너는 보안을 보장하는 데 유용한 보조 도구이므로 서버의 외부 인터페이스를 스캔하는 데 사용해야 합니다. 우리는 가장 유명한 제품 중 하나인 XSpider 7.7의 데모 버전을 사용했습니다.

스캐너는 열려 있는 포트를 표시하고 실행 중인 서비스 유형을 확인하려고 시도하며 성공할 경우 해당 취약점을 확인합니다. 보시다시피 올바르게 구성된 시스템은 매우 안전하지만 키를 깔개 아래에 두어서는 안 됩니다. 라우터에 열려 있는 포트 1723(VPN) 및 3389(RDP, 터미널 서버로 전달)가 있다는 것은 비밀번호 정책에 대해 생각해볼 이유가 충분합니다.

SSH 보안에 대해서도 이야기해야 하는데, 이 서비스는 일반적으로 관리자가 원격 서버 관리를 위해 사용하며 공격자가 큰 관심을 갖고 있습니다. SSH 설정은 파일에 저장됩니다. /etc/ssh/sshd_config, 아래에 설명된 모든 변경 사항이 적용됩니다. 우선 루트 사용자의 인증을 비활성화해야 합니다. 이렇게 하려면 다음 옵션을 추가하세요.

PermitRoot로그인 없음

이제 공격자는 비밀번호뿐만 아니라 로그인 정보도 추측해야 하며 여전히 슈퍼유저 비밀번호를 알 수 없습니다(귀하의 비밀번호와 일치하지 않기를 바랍니다). 외부에서 연결할 때 모든 관리 작업은 아래에서 수행해야 합니다. sudo권한이 없는 사용자로 로그인합니다.

허용된 사용자 목록을 명시적으로 지정하는 것이 좋습니다. 다음과 같은 항목을 사용할 수 있습니다. 사용자@호스트, 지정된 사용자가 지정된 호스트에서만 연결할 수 있도록 허용합니다. 예를 들어, 사용자 ivanov가 집(IP 1.2.3.4)에서 연결하도록 허용하려면 다음 항목을 추가해야 합니다.

허용사용자 [이메일 보호됨]

또한 오래되고 덜 안전한 SSH1 프로토콜의 사용을 비활성화하여 프로토콜의 두 번째 버전만 허용합니다. 이렇게 하려면 다음 줄을 형식으로 변경합니다.

프로토콜 2

모든 조치를 취했음에도 불구하고 여전히 SSH 및 기타 공용 서비스에 연결하려는 시도가 있을 것입니다. 비밀번호 추측을 방지하려면 유틸리티를 사용하세요. 실패2금지, 여러 번의 로그인 시도 실패 후 사용자를 자동으로 차단할 수 있습니다. 다음 명령을 사용하여 설치할 수 있습니다.

Sudo apt-get 설치 실패2반

이 유틸리티는 설치 후 즉시 작동할 준비가 되어 있지만 일부 매개변수를 즉시 변경하는 것이 좋습니다. 이렇게 하려면 파일을 변경하십시오. /etc/fail2ban/jail.conf. 기본적으로 SSH에 대한 액세스만 제어되며 금지 시간은 10분(600초)입니다. 다음 옵션을 변경하여 이를 늘릴 가치가 있다고 생각합니다.

반타임 = 6000

그런 다음 파일을 스크롤하고 해당 섹션 이름 뒤에 매개변수를 설정하여 시스템에서 실행 중인 서비스에 대한 섹션을 활성화합니다. 활성화됨상태에서 진실, 예를 들어 서비스의 경우 proftpd다음과 같이 보일 것입니다:


활성화 = 사실

또 다른 중요한 매개변수 최대 재시도, 최대 연결 시도 횟수를 담당합니다. 설정을 변경한 후 서비스를 다시 시작하는 것을 잊지 마세요.

Sudo /etc/init.d/fail2ban 재시작

다음에서 유틸리티 로그를 볼 수 있습니다. /var/log/fail2ban.log.

2015년 연례 LinuxCon 컨퍼런스에서 GNU/Linux 커널 창시자인 Linus Torvalds는 시스템 보안에 대한 자신의 견해를 공유했습니다. 그는 유능한 보호 기능을 통해 특정 버그의 영향을 완화하여 하나의 구성 요소가 오작동할 경우 다음 계층에서 문제를 다룰 필요성을 강조했습니다.

이 자료에서는 실용적인 관점에서 이 주제를 다루려고 합니다.

7. 방화벽 설치

최근 Linux를 실행하는 서버에 DDoS 공격을 허용하는 새로운 취약점이 발견되었습니다. 2012년 말 버전 3.6에서 시스템 코어의 버그가 나타났습니다. 이 취약점으로 인해 해커는 다운로드 파일, 웹 페이지 및 열려 있는 Tor 연결에 바이러스를 주입할 수 있으며 해킹에는 많은 노력이 필요하지 않습니다. IP 스푸핑 방법이 작동합니다.

암호화된 HTTPS 또는 SSH 연결의 최대 피해는 연결 중단이지만 공격자는 맬웨어를 포함한 새로운 콘텐츠를 보호되지 않은 트래픽에 삽입할 수 있습니다. 방화벽은 이러한 공격으로부터 보호하는 데 적합합니다.

방화벽을 사용하여 액세스 차단

방화벽은 원치 않는 수신 트래픽을 차단하는 가장 중요한 도구 중 하나입니다. 꼭 필요한 트래픽만 허용하고 다른 모든 트래픽은 완전히 차단하는 것이 좋습니다.

패킷 필터링을 위해 대부분의 Linux 배포판에는 iptables 컨트롤러가 있습니다. 일반적으로 고급 사용자가 사용하며 간단한 설정을 위해 Debian/Ubuntu의 UFW 유틸리티 또는 Fedora의 FirewallD를 사용할 수 있습니다.

8. 불필요한 서비스 비활성화

버지니아 대학의 전문가들은 사용하지 않는 모든 서비스를 비활성화할 것을 권장합니다. 일부 백그라운드 프로세스는 자동 시작으로 설정되어 시스템이 종료될 때까지 실행됩니다. 이러한 프로그램을 구성하려면 초기화 스크립트를 확인해야 합니다. 서비스는 inetd 또는 xinetd를 통해 시작될 수 있습니다.

시스템이 inetd를 통해 구성된 경우 /etc/inetd.conf 파일에서 백그라운드 "데몬" 프로그램 목록을 편집할 수 있습니다. 서비스 로드를 비활성화하려면 행 시작 부분에 "#" 기호를 넣으면 됩니다. 실행 파일에서 주석으로 전환합니다.

시스템이 xinetd를 사용하는 경우 해당 구성은 /etc/xinetd.d 디렉토리에 있습니다. 각 디렉터리 파일은 다음 예와 같이 비활성화 = yes를 지정하여 비활성화할 수 있는 서비스를 정의합니다.

서비스 핑거(socket_type = 스트림 대기 = 사용자 없음 = 없음 서버 = /usr/sbin/in.fingerd 비활성화 = 예)
inetd나 xinetd에 의해 관리되지 않는 지속적인 프로세스를 확인하는 것도 가치가 있습니다. /etc/init.d 또는 /etc/inittab 디렉토리에서 시작 스크립트를 구성할 수 있습니다. 변경이 완료되면 루트 계정으로 명령을 실행합니다.

/etc/rc.d/init.d/inet 재시작

9. 서버를 물리적으로 보호

서버에 물리적으로 접근하는 공격자의 공격으로부터 완벽하게 보호하는 것은 불가능합니다. 따라서 시스템이 위치한 공간을 확보하는 것이 필요합니다. 데이터 센터는 보안을 엄격하게 모니터링하고, 서버에 대한 액세스를 제한하고, 보안 카메라를 설치하고, 영구 보안을 할당합니다.

데이터 센터에 입장하려면 모든 방문자는 특정 인증 단계를 거쳐야 합니다. 또한 센터의 모든 영역에서 모션 센서를 사용하는 것이 좋습니다.

10. 무단 접근으로부터 서버를 보호하세요

무단 액세스 시스템 또는 IDS는 시스템 구성 및 파일 데이터를 수집하고 이 데이터를 새로운 변경 사항과 추가로 비교하여 시스템에 유해한지 여부를 결정합니다.

예를 들어 Tripwire 및 Aide 도구는 시스템 파일 데이터베이스를 수집하고 키 세트를 사용하여 이를 보호합니다. Psad는 방화벽 보고서를 사용하여 의심스러운 활동을 모니터링하는 데 사용됩니다.

Bro는 네트워크를 모니터링하고, 의심스러운 활동 패턴을 추적하고, 통계를 수집하고, 시스템 명령을 실행하고, 경고를 생성하도록 설계되었습니다. RKHunter는 바이러스(주로 루트킷)로부터 보호하는 데 사용할 수 있습니다. 이 유틸리티는 알려진 취약점 데이터베이스와 비교하여 시스템을 검사하고 응용 프로그램의 안전하지 않은 설정을 식별할 수 있습니다.

결론

위에 나열된 도구와 설정은 시스템을 부분적으로 보호하는 데 도움이 되지만 보안은 사용자의 행동과 상황에 대한 이해에 따라 달라집니다. 주의,주의 및 지속적인 자기 교육이 없으면 모든 보호 조치가 효과가 없을 수 있습니다.

cvedetails.com에 따르면 1999년 이후 Linux 커널에서 1,305개의 취약점이 발견되었으며, 그 중 68개가 2015년에 발견되었습니다. 대부분은 특별한 문제를 일으키지 않으며 로컬 및 낮음으로 표시되며 일부는 특정 응용 프로그램이나 OS 설정에 연결되어야만 호출할 수 있습니다. 원칙적으로 숫자는 작지만 커널이 전체 OS는 아닙니다. 취약점은 GNU Coreutils, Binutils, glibs는 물론 사용자 애플리케이션에서도 발견됩니다. 가장 흥미로운 것들을 살펴 보겠습니다.

리눅스 커널의 취약점

운영체제:리눅스
수준:중간, 낮음
벡터:원격
CVE: CVE-2015-3331, CVE-2015-4001, CVE-2015-4002, CVE-2015-4003
악용하다:개념, https://lkml.org/lkml/2015/5/13/740, https://lkml.org/lkml/2015/5/13/744

6월에 3.19.3 이전 Linux 커널의 Arch/x86/crypto/aesni-intel_glue.c에 있는 __driver_rfc4106_decrypt 함수에서 발견된 취약점은 AES 명령어 세트 확장 AES-NI(제안됨)를 지원하는 x86 프로세서용 RFC4106 구현으로 인해 발생합니다. Intel, Intel Advanced Encryption Standard Instructions)에서는 경우에 따라 버퍼 주소를 올바르게 계산하지 않습니다. IPsec 터널이 이 모드(AES 알고리즘 - CONFIG_CRYPTO_AES_NI_INTEL)를 사용하도록 구성된 경우 취약점으로 인해 메모리 손상, 충돌 및 원격 CryptoAPI 코드 실행이 발생할 수 있습니다. 더욱이 가장 흥미로운 점은 문제가 외부 개입 없이 완전히 합법적인 트래픽에서 자체적으로 발생할 수 있다는 것입니다. 게시 당시 문제가 해결되었습니다.

실험적 상태인 Linux 4.0.5 ozwpan 드라이버에서 5가지 취약점이 확인되었으며, 그 중 4개는 특별히 설계된 패킷을 보내 커널을 충돌시켜 DoS 공격을 구성할 수 있습니다. 문제는 부호 있는 정수의 잘못된 처리로 인한 버퍼 오버플로와 관련이 있습니다. 이 경우 memcpy의 필수 크기와 오프셋 사이의 계산이 음수를 반환하여 결과적으로 데이터가 힙에 복사됩니다.

drivers/staging/ozwpan/ozhcd.c의 oz_hcd_get_desc_cnf 함수와 drivers/staging/ozwpan/ozusbsvc1.c 파일의 oz_usb_rx 및 oz_usb_handle_ep_data 함수에서 발견됩니다. 다른 취약점에는 0으로 나누기, 시스템 루핑 또는 할당된 버퍼 범위 외부 영역에서 읽는 기능이 포함되어 있습니다.

Linux에 새로 추가된 ozwpan 드라이버는 기존 Ozmo 장치(Wi-Fi Direct) 호환 무선 장치와 페어링할 수 있습니다. USB 호스트 컨트롤러의 구현을 제공하지만 물리적 연결 대신 주변 장치가 Wi-Fi를 통해 통신한다는 점이 트릭입니다. 드라이버는 유형(ethertype) 0x892e의 네트워크 패킷을 받아들인 다음 이를 구문 분석하고 이를 다양한 USB 기능으로 변환합니다. 현재로서는 드문 경우에 사용되므로 ozwpan.ko 모듈을 언로드하여 비활성화할 수 있습니다.

리눅스 우분투

운영체제: Linux Ubuntu 12.04–15.04(커널은 2015년 6월 15일까지)
수준:비판적인
벡터:현지의
CVE: CVE-2015-1328
악용하다: https://www.exploit-db.com/exploits/37292/

OverlayFS 파일 시스템의 심각한 취약점으로 인해 권한이 없는 사용자가 OverlayFS 파티션을 마운트할 수 있는 Ubuntu 시스템의 루트 액세스가 허용됩니다. 취약점을 악용하는 데 필요한 기본 설정은 Ubuntu 12.04~15.04의 모든 분기에서 사용됩니다. OverlayFS 자체는 비교적 최근에 Linux 커널에 등장했습니다. 3.18-rc2(2014)부터 시작하여 UnionFS 및 AUFS를 대체하기 위한 SUSE 개발입니다. OverlayFS를 사용하면 다른 파일 시스템의 여러 부분을 결합하는 가상 다중 계층 파일 시스템을 만들 수 있습니다.

파일 시스템은 하위 계층과 상위 계층에서 생성되며 각각은 별도의 디렉터리에 연결됩니다. 맨 아래 계층은 네트워크 계층을 포함하여 Linux에서 지원되는 모든 파일 시스템의 디렉터리에서만 읽는 데 사용됩니다. 상단 레이어는 일반적으로 쓰기 가능하며 파일이 복제되면 하단 레이어의 데이터를 재정의합니다. 라이브 배포, 컨테이너 가상화 시스템 및 일부 데스크톱 애플리케이션의 컨테이너 운영 구성에 수요가 있습니다. 사용자 네임스페이스를 사용하면 컨테이너에 고유한 사용자 및 그룹 ID 집합을 만들 수 있습니다. 이 취약점은 기본 파일 시스템의 디렉터리에 새 파일을 생성할 때 액세스 권한을 잘못 확인하여 발생합니다.

커널이 CONFIG_USER_NS=y(사용자 네임스페이스 활성화)로 빌드되고 마운트 시 FS_USERNS_MOUNT 플래그가 지정되면 일반 사용자가 루트 작업을 허용하는 네임스페이스를 포함하여 다른 네임스페이스에 OverlayFS를 마운트할 수 있습니다. 이 경우 해당 네임스페이스에서 수행되는 루트 권한이 있는 파일 작업은 기본 파일 시스템으로 작업을 수행할 때 동일한 권한을 받습니다. 따라서 모든 FS 파티션을 마운트하고 파일이나 디렉터리를 보거나 수정할 수 있습니다.

출판 당시 Ubuntu의 고정 OverlayFS 모듈이 포함된 커널 업데이트가 이미 사용 가능했습니다. 그리고 시스템이 업데이트되면 문제가 없을 것입니다. 같은 경우에도 업데이트가 불가능할 경우 임시조치로 overlayfs.ko 모듈을 제거하여 OverlayFS 사용을 중단하셔야 합니다.

주요 애플리케이션의 취약점

운영체제:리눅스
수준:비판적인
벡터:로컬, 원격
CVE: CVE-2015-0235
악용하다: https://www.qualys.com/research/security-advisories/exim_ghost_bof.rb

Linux OS의 핵심 부분인 GNU glibc 표준 라이브러리와 Oracle Communications Application 및 Oracle Pillar Axiom의 일부 버전에서 Qualys 해커의 코드 감사 중에 발견된 위험한 취약점입니다. 코드명 GHOST를 받았습니다. 이는 gethostbyname() 및 gethostbyname2()와 같은 glibc 함수에서 호스트 이름(따라서 GetHOST라는 이름)을 가져오는 데 사용되는 __nss_hostname_digits_dots() 함수 내부의 버퍼 오버플로입니다. 취약점을 악용하려면 DNS를 통해 이름 확인을 수행하는 애플리케이션에 잘못된 호스트 이름 인수를 사용하여 버퍼 오버플로를 발생시켜야 합니다. 즉, 이론적으로 이 취약점은 어느 정도 네트워크를 사용하는 모든 애플리케이션에 적용될 수 있습니다. 로컬 및 원격으로 호출하여 임의의 코드를 실행할 수 있습니다.

가장 흥미로운 점은 2013년 5월에 오류가 수정되었고 glibc 2.17과 2.18 릴리스 사이에 패치가 제시되었지만 문제가 보안 ​​패치로 분류되지 않아 아무런 관심도 받지 못했다는 것입니다. 결과적으로 많은 배포판이 취약한 것으로 나타났습니다. 최초의 취약한 버전은 2000년 11월 10일자 2.2인 것으로 당초 보고되었으나, 2.0까지 나타날 가능성이 있다. 그 중에서도 RHEL/CentOS 5.x–7.x, Debian 7 및 Ubuntu 12.04 LTS 배포판이 영향을 받았습니다. 현재 핫픽스를 사용할 수 있습니다. 해커들은 취약점의 본질을 설명하고 시스템을 점검할 수 있는 유틸리티를 제안했습니다. Ubuntu 12.04.4 LTS에서는 모든 것이 정상입니다.

$ wget https : //goo.gl/RuunlE

$gcc gistfile1. c - o CVE - 2015 - 0235

$. / CVE - 2015 - 0235

취약하지 않음

GHOST에서 시스템 확인하기

거의 즉시 Exim 메일 서버가 실행 중인 x86 및 x86_64 Linux에서 원격 코드 실행을 허용하는 모듈이 출시되었습니다(helo_try_verify_hosts 또는 helo_verify_hosts 매개 변수가 활성화됨). 나중에 WordPress에서 블로그를 확인하기 위한 Metasploit 모듈과 같은 다른 구현이 나타났습니다.

조금 뒤인 2015년에는 원격 사용자가 DoS 공격을 수행하거나 스택 경계 외부의 메모리 셀을 덮어쓸 수 있도록 허용하는 GNU glibc에서 세 가지 취약점이 더 발견되었습니다: CVE-2015-1472, CVE-2015-1473, CVE-2015- 1781.

운영체제:리눅스(GNU Coreutils)
수준:낮은
벡터:로컬, 원격
CVE: CVE-2014-9471
악용하다:아니요

GNU Coreutils는 거의 모든 기본 유틸리티(cat, ls, rm, date...)를 포함하는 주요 *nix 패키지 중 하나입니다. 문제는 날짜에서 발견되었습니다. parse_datetime 함수의 결함으로 인해 시스템에 계정이 없는 원격 공격자가 서비스 거부를 유발하고 시간대를 사용하여 특별히 제작된 날짜 문자열을 통해 임의 코드를 실행할 수 있습니다. 취약점은 다음과 같습니다.

$ touch '-- 날짜 = TZ = "123"345"@1'

세그멘테이션 오류

$ 날짜 - d 'TZ = "유럽 / 모스크바" "00 : 00 + 1시간"'

세그멘테이션 오류

$ 날짜 '-- 날짜 = TZ = "123"345"@1'

* * * `date' 오류: free(): 잘못된 포인터: 0xbfc11414 * * *

GNU Coreutils의 취약점

취약점이 없으면 잘못된 날짜 형식에 대한 메시지를 받게 됩니다. 거의 모든 Linux 배포판 개발자가 취약점의 존재를 보고했습니다. 현재 업데이트를 사용할 수 있습니다.


패치된 GNU Coreutils의 일반 출력

운영체제:리눅스(grep 2.19–2.21)
수준:낮은
벡터:현지의
CVE: CVE-2015-1345
악용하다:아니요

패턴을 사용하여 텍스트를 검색하는 데 사용되는 grep 유틸리티에서는 취약점이 거의 발견되지 않습니다. 그러나이 유틸리티는 시스템 프로그램을 포함한 다른 프로그램에서 호출되는 경우가 많으므로 취약점의 존재는 언뜻 보이는 것보다 훨씬 더 문제가 됩니다. kwset.c에 있는 bmexec_trans 함수의 버그로 인해 할당된 버퍼 외부 영역에서 초기화되지 않은 데이터를 읽거나 애플리케이션이 중단될 수 있습니다. 해커는 grep -F를 사용하여 애플리케이션 입력에 제공되는 특수 데이터 세트를 생성하여 이를 활용할 수 있습니다. 현재 업데이트를 사용할 수 있습니다. Metasploit의 취약점이나 모듈을 사용하는 익스플로잇은 없습니다.

FREEBSD의 취약점

운영체제: FreeBSD
수준:낮은
벡터:로컬, 원격
CVE: CVE-2014-0998, CVE-2014-8612, CVE-2014-8613
악용하다: https://www.exploit-db.com/exploits/35938/

2015년 CVE 데이터베이스에는 취약점이 많지 않습니다. 더 정확하게 말하면 6개뿐입니다. Core Exploit Writers Team의 연구원들은 2015년 1월 말 FreeBSD 8.4-10.x에서 세 가지 취약점을 발견했습니다. CVE-2014-0998은 /boot/loader.conf의 kern.vty=vt 매개변수로 활성화되는 여러 가상 터미널을 제공하는 VT 콘솔 드라이버(Newcons)의 구현과 관련되어 있습니다.
CVE-2014-8612는 SCTP 프로토콜을 사용할 때 발생하며 SCTP 소켓(로컬 포트 ​​4444)을 구현하는 SCTP 스트림 ID 확인 코드의 오류로 인해 발생합니다. 본질은 sctp_setopt() 함수(sys/netinet/sctp_userreq.c)의 메모리 부족 오류입니다. 이를 통해 권한이 없는 로컬 사용자는 16비트 커널 메모리 데이터를 쓰거나 읽을 수 있고 시스템에 대한 권한을 승격하거나 중요한 데이터를 공개하거나 시스템을 충돌시킬 수 있습니다.

CVE-2014-8613은 SCTP_SS_VALUE SCTP 소켓 옵션이 설정된 경우 외부에서 수신된 SCTP 패킷을 처리할 때 NULL 포인터 역참조가 트리거되도록 허용합니다. 이전 버전과 달리 CVE-2014-8613은 특별히 제작된 패킷을 전송하여 원격으로 커널 충돌을 일으키는 데 사용될 수 있습니다. FreeBSD 10.1에서는 net.inet.sctp.reconfig_enable 변수를 0으로 설정하여 RE_CONFIG 블록 처리를 비활성화함으로써 자신을 보호할 수 있습니다. 또는 단순히 애플리케이션(브라우저, 이메일 클라이언트 등)이 SCTP 연결을 사용하지 못하도록 금지하세요. 출판 당시 개발자는 이미 업데이트를 출시했습니다.


FreeBSD 취약점 통계

OpenSL의 취약점

운영체제: OpenSSL
수준:원격
벡터:현지의
CVE: CVE-2015-1793
악용하다:아니요

2014년에는 SSL/TLS 작업에 널리 사용되는 암호화 패키지인 OpenSSL에서 심각한 Heartbleed 취약점이 발견되었습니다. 이 사건은 한때 코드 품질에 대한 엄청난 비판을 불러일으켰고, 한편으로는 이로 인해 LibreSSL과 같은 대안이 등장했고, 다른 한편으로는 개발자 스스로가 마침내 사업에 착수했습니다.

취약점별 상위 공급업체

심각한 취약점은 Google의 Adam Langley와 BoringSSL의 David Benjamin이 발견했습니다. OpenSSL 버전 1.0.1n 및 1.0.2b의 변경 사항으로 인해 OpenSSL은 첫 번째 신뢰 체인 구축 시도가 실패한 경우 대체 인증서 확인 체인을 찾으려고 시도했습니다. 이를 통해 인증서 확인 절차를 우회하고 가짜 인증서를 사용하여 확인된 연결을 구성할 수 있습니다. 즉, 사용자를 가짜 사이트나 이메일 서버로 조용히 유인하거나 인증서가 사용되는 MITM 공격을 수행할 수 있습니다.

취약점이 발견된 후 개발자들은 이 문제를 해결한 릴리스 1.0.1p 및 1.0.2d를 7월 9일 출시했습니다. 버전 0.9.8 또는 1.0.0에는 이 취약점이 없습니다.

리눅스.인코더

가을의 끝은 Linux.Encoder.0, Linux.Encoder.1 및 Linux.Encoder.2의 수정 사항과 같은 다수의 암호화 바이러스가 출현하여 2,500개 이상의 사이트를 감염시킨 것으로 나타났습니다. 바이러스 백신 회사에 따르면 WordPress, Magento CMS, Joomla 등 다양한 CMS를 사용하여 웹사이트를 실행하는 Linux 및 FreeBSD 서버가 공격을 받고 있습니다. 해커들은 확인되지 않은 취약점을 악용하고 있습니다. 다음으로, 브라우저를 통해 추가 작업을 수행하는 데 도움이 되는 쉘 스크립트(error.php 파일)가 배치되었습니다. 특히 리눅스 인코더 트로이 목마가 출시됐다.

OS 아키텍처를 결정하고 랜섬웨어를 실행한 인코더. 인코더는 CMS 파일 및 구성 요소가 저장된 디렉터리의 파일을 암호화하는 데 충분한 웹 서버 권한(Ubuntu - www-data)으로 실행되었습니다. 암호화된 파일은 새로운 확장자.encrypted를 받습니다.

랜섬웨어는 또한 다른 OS 디렉터리를 우회하려고 시도하며, 권한이 잘못 구성되면 쉽게 웹 사이트 경계를 넘어갈 수 있습니다. 다음으로 파일 암호 해독 지침과 해커의 요구 사항이 포함된 README_FOR_DECRYPT.txt 파일이 디렉터리에 저장되었습니다. 현재 바이러스 백신 회사에서는 디렉터리의 암호를 해독할 수 있는 유틸리티를 도입했습니다. 예를 들어 Bitdefender의 세트입니다. 그러나 파일을 해독하도록 설계된 모든 유틸리티는 쉘코드를 제거하지 않으며 모든 일이 다시 발생할 수 있다는 점을 기억해야 합니다.

웹사이트 개발이나 실험에 참여하는 많은 사용자들이 집에 있는 컴퓨터에 웹 서버를 설치하는 경우가 많다는 점을 고려하면 외부 접근 차단, 소프트웨어 업데이트, VM에서 실험 수행 등 보안에 대해 걱정해야 합니다. 그리고 이 아이디어 자체는 미래에 홈 시스템을 공격하는 데 사용될 수도 있습니다.

결론

오류가 없는 복잡한 소프트웨어는 물리적으로 존재하지 않기 때문에 취약점이 끊임없이 발견된다는 사실을 받아들여야 합니다. 그러나 그들 모두가 실제로 문제가 될 수는 없습니다. 사용하지 않는 소프트웨어를 제거하고, 새로운 취약점을 모니터링하고, 보안 업데이트를 설치하고, 방화벽을 구성하고, 바이러스 백신을 설치하는 등의 간단한 조치를 취하여 자신을 보호할 수 있습니다. 그리고 데몬이나 사용자 애플리케이션을 손상시킬 수 있는 SELinux와 같은 특수 기술을 잊지 마십시오.

관리 도구 설치 및 구성, 네트워크 구성

최소한의 배포판에서 기본 운영체제인 ubuntu14.04를 설치한 후, 가장 먼저 고민해야 할 것은 어떻게 하면 편하게 관리할 수 있느냐 하는 것입니다. 기본적으로 ssh/telnet은 *nix 기반 서버를 구성하고 관리하는 데 사용되지만 최근에는 이를 위해 매우 적합한 웹 인터페이스 기반 도구도 등장했습니다. 무료 솔루션을 사용합니다 웹민그리고 아젠티. 이 두 패널 모두 주목할 만하며 모든 것을 개별적으로 수행할 수 있다는 사실에도 불구하고 각 패널이 어떤 작업에는 더 적합하므로 둘 다 갖는 것이 더 좋습니다. 전투 프로덕션 서버에서는 이러한 솔루션이 보안을 기반으로 설치되지 않는다는 점에 유의해야 합니다. 하지만 제어 시스템이 많을수록 그 시스템에서 취약점을 발견할 가능성도 커집니다. 따라서 보안 요구 사항이 "편집증" 수준에 있는 경우 SSH(콘솔을 통해)를 통해서만 서버 작업을 해야 한다는 사실을 받아들이십시오.

우분투 14.04에서 네트워크 설정하기

네트워크를 통해 당사 서버와 통신하려면 먼저 서버를 구성해야 합니다. 기본적으로 설치 중에 네트워크가 자동으로 구성되었으며 설치 프로그램이 네트워크에서 DHCP 서버를 감지한 경우 필요에 따라 모든 것이 이미 구성되었을 가능성이 높습니다. 네트워크에 DHCP 서버가 없는 경우에도 설치 프로그램은 네트워크 카드가 연결된 라우터 폴링을 기반으로 모든 것을 구성했습니다. 현재 네트워크가 어떻게 구성되어 있는지 확인하려면 터미널에 다음을 입력하세요.

여기서 우리는 무엇을 볼 수 있습니까?

두 개의 네트워크 인터페이스 eth0과 lo가 있습니다. 여기서 lo는 "루프백 인터페이스"이고 eth0은 네트워크 카드의 이름입니다. lo가 변경되지 않은 네트워크 인터페이스인 경우 다른 모든 인터페이스의 이름은 다를 수 있습니다. 두 개의 네트워크 카드가 시스템 장치에 설치된 경우 해당 인터페이스는 eth0 및 eth1 등과 유사할 가능성이 높습니다. 인터페이스 이름 유형은 네트워크 카드 유형에 따라 다릅니다. 예를 들어, 네트워크 카드가 WiFi 프로토콜을 통해 작동하는 경우 해당 이름은 wlan0이 될 가능성이 높습니다.

네트워크를 구성하려면 다음 파일을 편집해 보겠습니다.

sudo nano /etc/network/인터페이스

다음과 같은 형식으로 만들어 보겠습니다.

iface eth0 inet 정적
주소 192.168.0.184
넷마스크 255.255.255.0
게이트웨이 192.168.0.1
자동 eth0
DNS 이름 서버 8.8.8.8 8.8.4.4

어디: iface eth0 inet 정적— 인터페이스(iface eth0)가 고정 IP(정적)를 사용하는 IPv4(inet) 주소 범위에 있음을 나타냅니다.
주소 192.168.0.184— 네트워크 카드의 IP 주소가 192.168.0.184임을 나타냅니다.
넷마스크 255.255.255.0— 서브넷 마스크(넷마스크)가 255.255.255.0임을 나타냅니다.
게이트웨이 192.168.0.1— 기본 게이트웨이 주소 192.168.0.254;
자동 eth0— 위의 매개변수를 사용하여 시스템을 부팅할 때 eth0 인터페이스가 자동으로 활성화되어야 함을 시스템에 나타냅니다.
eth0— 연결할 인터페이스의 이름입니다. 인터페이스 목록은 ifconfig를 입력하여 볼 수 있습니다.
DNS-네임서버— DNS 서버는 공백으로 구분하여 작성됩니다.

제 경우는 보시다시피 고정IP를 192.168.0.184로 설정하기로 했습니다.

다음 명령으로 서버를 재부팅하십시오

우리는 네트워크에서 서버를 핑하고 그것이 보이는지 확인합니다. 이제 SSH를 통해 연결을 설정할 차례입니다. 이를 위해 실제로 SSH 서버를 설치하겠습니다.

sudo apt-get 설치 SSH

이제 Putty 프로그램을 통해 SSH를 통해 서버에 연결할 수 있습니다. 예를 들어 수동으로 명령을 입력하는 것이 아니라 필요한 줄을 복사하여 SSH 클라이언트에 붙여넣을 수 있습니다. 왜냐하면 앞으로 이렇게 하면 설정이 놀라울 정도로 쉬워질 것이기 때문입니다. , 곧 직접 확인하게 되실 것입니다.

이 줄 아래의 모든 명령은 슈퍼유저로 입력됩니다., 슈퍼유저 모드로 들어가려면 다음을 입력해야 합니다.

webmin 설치

echo "deb https://download.webmin.com/download/repository sarge contrib" >> /etc/apt/sources.list echo "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib" >> /etc/apt/sources.list wget https://www.webmin.com/jcameron-key.asc apt-key 추가 jcameron-key.asc apt-get 업데이트 apt-get install -y webmin

에코 "deb https://download.webmin.com/download/repository sarge 기여">>

에코 "deb https://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib">> /etc/apt/sources. 목록

wget https : //www.webmin.com/jcameron-key.asc

apt - 키 추가 jcameron - 키. 오름차순

apt - 업데이트 받기

apt - 설치 - y webmin

모두! 6개의 명령어를 순차적으로 입력하면 webmin이 설치 및 구성됩니다. 이제 다음 주소에서 브라우저에 로그인할 수 있습니다.

https://192.168.0.184:10000

기본적으로 webmin은 미니멀해 보이고 기본 인터페이스는 영어로 표시되지만 모든 것이 사용자 정의 가능합니다!

우리는 다음과 같이 합니다:

다음과 같이 밝혀졌습니다.