6. Security in Linux Environment
1. 소개
- 리눅스 사용자의 증가
- 리눅스를 서버로 사용하는 관리자의 증가
- 주 운영체계로의 리눅스의 부각
- 유닉스 계열에서 발견되는 많은 보안상 허점(Security holes)
- 해킹과 크래킹의 기술적 향상
2. 목차
- TCP Wrapper의 개념과 그 활용
- Flooding의 종류와 개념
- Denial of Sevice의 개념과 심각성
- 보안셸(SSH)의 이용 방법
- Buffer Overflow의 개념과 대응
- 리눅스 시스템 관리시 주의 사항
3. What is TCP Wrapper
- Network Services(telnet, finger, ftp, rsh, rlogin etc.) 요청에 대해 로그를 남김.
- 서비스 요청에 대한 보안성 여부 검사.
- 다른 설정(configuration)을 변경하지 않고 손쉽게 설치, 이용 가능.
- C/S 사이에 부하를 주지 않음.
4. The concepts of TCP Wrapper
- C/S 기반의 TCP/IP 환경
* Client telnet(port 23) requests to Server (in.telnetd)
* inet에 의해서 in.telnetd 구동.
- in.telnetd가 telnet에 대한 구체적인 로그인을 남기지 않음.
* 누가 접속해서 무슨 일을 했는가
- tcpd를 통한 1차적 접속
(1) Client requests to server
(2) inetd running tcpd and tcpd logs Client
(3) Check Client requests
(4) tcpd go away!
(5) Real services daemon running.
- Support programs using TCP.
5. TCP Wrapper의 기능 측면
- /etc/hosts.deny와 /etc/hosts.allow에 의한 access control
* ex) In /etc/hosts.allow
in.telnetd: .ajou.ac.kr
in.ftpd: .kr, UNKNOWN: winnuke %h
* ex) In /etc/hosts.deny
in.telnetd,in.ftpd: ALL EXCEPT 202.30.13
6. Setup of TCP Wrapper
- 대부분의 요즘 리눅스에는 기본 설치.
*따로 설치할 필요 없음.
- TCP Wrapper의 최신 버전
*ftp://cert.org/pub/tools/tcp_wrappers
- TCP Wrapper의 설치 여부 확인
*/etc/inetd.conf에서 다음과 같은 부분 확인
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
7. Flooding의 개념
- DoS(Denial of Service)의 일종
- 직접적으로 시스템을 크래킹하지 않음.
- 종류
*SYN flooding
*ICMP flooding (same as Ping bombing)
- UDP storm, ping flooding과는 달리 패킷의 양이 적어도 됨.
8. SYN flooding attack의 방법
- 연결하고자 하는 서버의 backlog queue를 가득 차게 함.
- TCP의 3-way handshaking의 약점을 이용.
- ISP에 치명적
* 특정 포트(23, 80)에 attack하여 성공할 경우, 서비스 제공에 차질.
9. SYN Flooding 확인 요령
- netstat -a -f inet
* state가 보통 LISTEN이나, SYN_RECEIVED가 많다면, 현재 공격당하고 있는 것으로 볼 수 있음.
10. SYN Flooding 방지 요령
- 리눅스 커널 세팅에서 SYN Cookies와 RST Cookies 지원 하게 함(or both)
* SYN Flooding 공격을 받고 있다 하더라도 cookies를 통해 합법적 사용자와의 연결이 지속적으로 이루어지게 해줌.
- Connection time-out을 짧게 잡아줌.
* 커널 수정 필요.
- Queue의 길이 크게 잡음(리눅스는 5).
11. Ping bombing
- ICMP
* Connectionless protocol, IP 보완을 위해 gateway 와 host간의 에러 정보 교환 프로토콜
- ping을 통해 ICMP에 크기가 큰 패킷을 보냄. 궁극적으로 네트워크 마비를 꾀함.
- 윈도의 ping은 약 65KB정도의 패킷을 보낼 수 있음(호스트 마비 초래).
12. Ping bombing 방지 요령
- 방지할 수 있는 툴은 없음.
* 관리자의 지속적 감시와 대응 필요.
- 실례
* ICMP 메시지를 모니터링하다가 ICMP메시지 송신측에 winnuke를 동작시켜 버리는 사례도 있음(이에는 이, 눈에는 눈).
13. Denial of Sevice의 개념
- 다중 사용자용 운영체계에서는 언제든지 있을 수 있는 공격법
- 일반 유저도 얼마든지 사용 가능
- 고의적이지 않아도 발생 가능
- 시스템에 치명적인 문제는 없음
- 내부와 외부의 양면적 공격
14. DoS의 예
- Disk full(root filesystem full)
* 매우 치명적. /tmp or /var/tmp에 임의의 파일 작성. Quota로 어느 정도 해결 가능.
ex) ifd=open("/var/tmp/attack", O_WRONLYO_CREAT, 0777);
unlink("/var/tmp/attack");
- 메모리 고갈
* 매우 쉬운 방법
---
while(1)
c=malloc(MAX);
---
- 프로세스 테이블 고갈
* 예제 프로그램
void main()
{ vfork();main();}
* kill, ps도 사용 불가. 시스템 재시동 필요.
* 일반 유저도 가능.
* 프로세스 수 제한으로 방지.
- Mail storm
* 가장 손쉽게 사용하는 방법
* mail queue에 메일을 가득차게 함.
하이텔에서도 이러한 Mail storm attack 받음.
* BSD sendmail은 이럴 경우, 메일 수신 중단
리눅스는 이러한 면에서 비교적 안전.
* 특별한 해결 방안은 없음.
- Java applet
* Client에 자바 애플릿이 전송되어 실행되는 것을 이용.
* 메모리 리소스 고갈이나 그 밖의 적대적 애플릿을 만들어 놓았을 때 문제시 됨.
* 일종의 덫이라 할 수 있음.
* 웹 브라우저에서 자바 애플릿을 실행하지 않는 방법 이외에는 해결 방안 없음.
15. DoS의 결론
- 리눅스를 비롯한 다른 OS에서도 DoS 공격을 막기는 힘듬.
- 관리자의 지속적인 감시가 요구됨.
16. SSH의 개념과 활용
- Secure Shell (replacement of rsh)
- r-유틸리티 통신의 암호화
- FTP에서의 데이터 통신 암호화
- X에서의 데이터 통신 암호화
- 데이터를 암호화하여 송신
- 사용 암호 알고리듬
- IDEA, DES, RC4-128등
17. SSH의 개념
- 암호화를 위한 키는 RSA이용
* 이 때문에 SSH는 미국에서 수출 규제
- ssh와 sshd와의 상호 연결이 필수적.
* 혼자서 ssh를 쓴다고 해결되지 않음.
* 중요 서버와의 교신 시에 매우 효과적.
18. SSH의 효과
- IP spoofing 방지
* 암호화를 통한 인증으로 spoofing 원천적 불가
- sniffing을 통해 알아낸 데이터의 무용지물
- X 윈도 시스템 인증에서의 보안성 강화
19. SSH의 설치
- http://www.cs.hut.fi/ssh
*최신 ssh 제공
- 리눅스용 ssh 패키지
* non-US site에 있음. 국내에서는
ftp://ftp.kreonet.re.kr/Linux/{debian-nonUS,redhat-security}에 있음.
20. SSH의 한계
- 전송 속도의 현저한 저하
* DES 암호화 기준
안할 때 : 5.8
RC4-128 : 2.9
TSS : 3.5
DES : 1.0
IDEA : 1.3
3DES : 0.2
출처 : PLUS 저, "Security+ for UNIX"
- 초기 키에 대한 보안 문제
* apache-ssl, ssltelnet에서와 마찬가지로 초기 암호키의 전송 방법이 문제
- 상호 모두 SSH를 사용해야 함.
* SSH를 쓰는 상용 유닉스 호스트는 없음.
미국의 암호화 수출 규제에 따름.
- 그러나 Trusted hosts간에는 매우 효율적.
21. Buffer Overflow의 개념
- 지정된 메모리의 크기보다 더 많은 크기의 데이터를 메모리에 넣을 때 발생.
- 문제점 제기는 오래되었지만, 근래에 들어 새롭게 부각.
- 메모리 구조를 이용한 프로세스의 흐름 조정
- root의 권한을 획득하기 쉬움
- 어셈블리어에 대한 지식이 있어야 함.
- C와 유닉스의 퍼미션 특징의 조합으로 발생
- buffer와 array에 연계되어 발생(dynamic array)
- 일반적인 부분에서 시작되는 문제
* 실제 C프로그래밍에서 자주 일어나는 부분
- Buffer Overflow를 내는 중요한 문제점
* Bounds checking을 하지 않는다.(대부분)
- 예제 소스
void function(char *str) {
char buffer[16];
strcpy(buffer, str);
}
void main() {
char large_string[256];
int I;
for ( I = 0; I < 255; I++)
large_string[I] = 'A';
function(large_string);
}
- 이 프로그램은 segmentation fault를 낸다.
- sfp, ret, *str을 overwrite하게 됨.
- 이 때에 원하는 셸 코드를 고의로 Overflow하게 하여 overwrite하게 되면 루트 셸을 획득하게 될 수 있음.
- 해결책
* 소스 코드 수정
* 커널 수정(리턴하기 전에 스택의 무결성 검사)
* 스택에서 프로그램 실행을 금지시킴.
* 스택에 쓰기 권한을 제한.
* Boundary checking을 하는 함수를 사용.
strcat()보다는 strncat(), strcpy()보다는 strncpy()
* 컴파일러와 링커가 Boundary checking하는지의 여부를 알아보고 하는 것으로 사용.
GCC 2.7.2.x대 버전 사용 요망
22. 리눅스 시스템 관리 지침
- Shadow passwd와 secure-su이용
*대부분 배포본에서 지원.
- su는 group wheel(or root)에게만 허용
* /etc/suauth나 /etc/login.defs에서 group root에게만 제한적으로 허용
- remote에서의 root접속 불허
* /etc/securetty에 root접속 허용 터미널 지정
- path에 . 넣지 않음.
* 트로이 목마의 위험.
- .rhosts의 제거
* .rhosts를 제거하거나, /etc/inetd.conf에서 rlogin의 서비스를 중단
- Network접속시 ssltelnet이나 ssh를 이용하여 접속
* ssltelnet은 ssltelnetd가 반드시 있어야 함.
- 불필요한 setuid, setgid 설정 피함
* 일반 계정이 audio device를 이용할 수 없게 함.
- umask 설정 확인
* 002 설정시 큰 타격 입음. (022나 077이 되도록 조정)
- cfingerd로의 대치
* identd를 통한 유저 인증
- /etc/ld.so.cache 보관 유의
* 리눅스는 statically linked된 프로그램이 거의 없음.
* 기본 셸도 dynamically linked 됨.
* /etc/ld.so.cache를 특정인이 root 권한 획득 후 고의로 삭제하면 시스템은 돌이킬 수 없는 지경에 이름.
* 시스템의 보안에 문제가 간다면 statically linked되도록 re-complie 요망
- /var/log/ 디렉터리 내의 로그 파일 보는 것을 게을리 하지 마라.
* 로그 파일은 시스템 보안의 중요한 단서
* 로그 파일 보는 것을 게을리 하면 시스템 관리자로서의 자격이 의심스러워진다.
* /etc/syslog.conf의 조정을 통한 로그 파일의 세분화 -> 찾기 편함, 보기 편함.
- core 파일의 생성 제한
* 프로그램 디버깅에 유용하나, 크래커에게 빌미를 제공할 수 있음.
* core 파일의 생성 퍼미션 확인(600모드)
- 컴파일러 사용의 제한
* trusted users에게만 허용
* 컴파일러의 사용은 DoS를 야기할 수 있음.
- 퍼미션 관리의 일관성
* 일반적 실행 파일은 755, 그 외 파일은 644모드로 통일. setuid, setgid파일을 파악.
* setuid 걸린 파일 찾기
find / -type f -a \(-perm -2000 -o -perm -4000\) -print
* 소유자 없는 파일 찾기
find / -nouser -print
23. 결론
- 보안에는 왕도가 없다.
* 어떠한 운영체계든 보안적 문제에 강한 운영체계는 없다.
- 보안은 관리자 스스로가 알아서 지켜야 한다.
* 게으른 관리자는 운영체계에 크래쉬되면 다시 설치하면 된다고 이야기한다.
- 리눅스는 보안허점도 많고, 보안에도 강하다.
댓글 없음:
댓글 쓰기