**사용자의 패스워드 관리
- 일반 패스워드 정책 : passwd(/etc/passwd) 파일 내 계정 정보와 함께 저장
- shadow 패스워드 정책 : shadow(/etc/shadow) 파일에 패스워드 별도 저장
- 최근엔 shadow 패스워드 정책을 사용하고 root만이 접근할 수 있도록 보안 강화
*passwd 파일
root:x:0:0::root:/root:/bin/bash
1. 사용자 계정명 (root 계정은 원격 접속을 금지하는 것이 보안상 안전. su 명령어로 전환하는 게 안전)
2. 패스워드 영역. x의 의미 : shadow 패스워드 정책
3. 사용자 ID(UID. UID가 0이면 root를 의미하는데, root가 아닐때 0이라면 root권한 탈취 행위로 의심)
4. 사용자 기본 그룹 (GROUP ID, GID 관리자 그룹이 0인데 관리자가 아닐때 0인지 점검필요)
5. 설명
6. 홈 디렉토리 경로 (일반 사용자는 /hom 디렉터리 하위에 위치)
7. 로그인 쉘 (로그인이 불필요한 계정은 로그인을 금지하는 것이 보안상 안전 /sbin/nologin 또는 /bin/false)
짤막지식 (나중에 자세히 공부하게 됨)
pam 모듈
- pam_securetty 모듈을 이용해서 root 계정에 대한 원격접속을 제어할 수 있다
- pam_wheel 모듈을 root 계정으로 su 명령어를 제어해줄 수 있다
(wheel 그룹을 만들어 root 계정으로 su 명령어를 허용해줄 아이디를 넣는다)
실습
root 계정으로 /etc/passwd 파일을 vi로 수정하여 다른유저 로그인 쉘을 /sbin/nologin으로 바꿔보고
로그인이 되는지 확인
*shadow 파일
[user_account]:[encrypted_password]:[last_change]:[minlife]:[maxlife]:[warn]:[inactive]:[expires]
1. user_account 계정명
2. encrypted_password 암호화된 패스워드 (세부적으로 3가지 필드이고 $로 나뉨)
3. last_change 마지막으로 패스워드를 변경한 날 (일수)
4. minlife 패스워드 최소 사용기간 (너무 자주 변경하면, 최근 암호 기억을 무력화하여 익숙한 패스워드를 재사용할 문제점이 있음)
5. maxlife 패스워드 변경 전 최대 사용기간 (=만료일수. 패스워드 유출시 지속적인 접근을 막기위함. 90일(12주) 권장)
6. warn 만료 이전 경고 일수
7. inactive 로그인 접속 차단 일 수 (리눅스는 만료이후 비활성기간동안 패스워드를 변경하지 않으면 계정이 잠김. 유닉스는 마지막 로그인 이후 비활성화 기간동안 로그인을 하지 않으면 계정이 잠긴다)
8. expires 사용 금지 일수 (월일년도)
3~8번은 패스워드 에이징aging(시간의 흐름에 따른 패스워드 관리 정책)과 관련이 있다.
예시
root:암호화된패스워드:1666:0:99999:7:::
-> minlife와 maxlife가 부적절하게 설정됨
*encrypted_password 필드 구성
$ID$Salt$encrypted_password 형식
ex $1$1Tyc0bAE$CGxLH0klyFWnzMvAHFLFZ
- ID: 해시 알고리즘을 식별하기 위한 ID. SHA-256 이상이 권장
- Salt : 패스워드 암호화 강도를 높이기 위한 랜덤값. 패스워드마다 각각 다른 랜덤값을 사용한다. 레인보우 테이블 공격에 효과적으로 대응 가능(해시값을 통한 패스워드 추측을 어렵게함)
- encrypted_password : 암호화된 패스워드 (빈값: 패스워드 미설정(아무나 로그인 가능하므로 반드시 변경), 기호* 또는 기호!!: 잠긴 상태로 로그인 불가능)
왜 레인보우 테이블 공격에 대응이 가능한가?
원래 패스워드 : qwer
솔트 : 1234
해커가 해시값으로 알아낸 패스워드 : qwer1234 (원래 패스워드가 아닌, 솔트값이 첨가된 평문패스워드)
qwer1234를 패스워드로 입력하면, 시스템에서 솔트값 1234를 또 추가로 사용함
결국 shadow 파일에 저장된 패스워드와는 다른 결과값이 나와 로그인 인증이 불가능.
-- 10 End
패스워드 잠금lock 설정 : passwd -l username
패스워드 잠금unlock 해제 : passwd -u username
잠금전
root:$1$1Tyc0bAE$CGxLH0klyFWnzMvAHFLFZ:1766 ~
잠금후
root:!!$1$1Tyc0bAE$CGxLH0klyFWnzMvAHFLFZ:1766 ~
유닉스의 경우
NP : 로그인이 불가능한 계정 (root 등)
*NK* : Lock 잠긴 상태
빈값 : 미설정. 로그인시 패스워드 설정과정 진행됨.
chage 명령 사용법
- 리눅스 패스워드 정책 설정 파일 : /etc/login.defs (PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_MIN_LEN, PASS_WARN_AGE)
주요옵션
-d : lastday, 패스워드를 마지막으로 변경한 날을 수정 'YYYY-MM-DD' 또는 숫자(일수)
-E : expiredate, 계정만료일 설정
-m : mindays, 최소 사용일수
-M : masdays,최대 사용일수
-w : warmdays, 만료전 경고일수
-I : inactive, 만료후 비활성화 일수
-l : 에이징 정책 정보 출력
ex chage -m 1 username
ex chage -M 90 username
chage -l username (에이징 정보 출력)
패스워드 저장 정책 변경 (conversion)
pwconv : shadow 패스워드 정책으로 변경
pwunconv : 일반 패스워드 정책으로 변경 (/etc/shadow 파일이 삭제됨)
실습
pwunconv 실행
-> ls -l /etc/shadow 실행
-> ls: cannot access /etc/shadow: 그런 파일이나 디렉터리가 없습니다
-> chage -l root 실행
-> chage: 셰도우 암호 파일이 없습니다
-> pwconv 실행
-> 에러가 나던 ls -l 명령어와 chage 명령어 결과가 잘 나오는 것을 확인 할 수 있었다.
-- 11 End
1. Process 관련 식별 ID
- pid, ppid, pgid, sid
2. Process의 자원 접근 권한을 판단하기 위한 ID
- RUID(Real User ID) : 실행파일을 실행시킨 사용자의 ID
- RGID(Real Group ID) : 실행파일을 실행시킨 사용자의 Group ID
- EUID(Effective User ID) : 프로세스가 자원에 접근할 때 접근권한을 판단하기 위한 User ID
- EGID(Effective Group ID) : 프로세스가 자원에 접근할 때 접근권한을 판단하기 위한 Group ID
** 프로세스 실행권한 SUID, SGID (출제비율 높음)
사용자 UID: A_ID, GID: A_GID
실행파일 소유자:root, 소유그룹: root
1. SUID와 SGID가 미설정되었을때
- RUID: A_ID, RGID: A_GID
EUID: A_ID, EGID: A_GID
2. SUID와 SGID가 설정되었을때
- RUID: A_ID, RGID: A_GID
EUID: root, EGID: root
-> 사용자는 A_ID인데, root의 권한으로 실행됨(물론 실행시에 others의 x실행권한이 있어야 실행되겠지). 권한상승(Privilege Escalation)
우려해야 하는 보안 취약점 상황
: setuid 또는 setgid가 root로 설정된 파일인데 일반사용자 others의 x실행권한이 있을때
실습
1. /etc/shadow 파일은 root만이 read 할 수 있는 파일이다.
2. 실행파일 test.sh(/etc/shadow 파일을 인자값으로 주어 읽게하는)에 setuid root, setgid root를 설정하고, others 일반사용자 x 권한을 설정한다
3. root가 아닌 일반사용자 user1로 로그인한다. test.sh를 통해 /etc/shadow 파일을 읽어올 수 있다.
-> 권한상승을 통한 보안 취약점 공격 가능
setuid setgid 설정
ex chmod 6755 a.out = chmod ug+s a.out
ex chmod -s a.out (동시에 s권한 다 빼기)
find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -al {} \;
=> 취약점 분석을 위해 권한상승 가능한 파일들을 주기적으로 검사해야 한다
공유 디렉토리는 보통 777권한을 주는데,
문제점은 A사용자가 만든 파일을 B사용자가 멋대로 수정할 수 있다는 것이다.
이때문에 디렉터리 접근권한 sticky-bit를 사용한다
디렉터리 접근권한 sticky-bit
- 자유롭게 파일을 생성하되, 파일 삭제나 파일명 변경은 소유자(또는 root)만이 가능하도록 하는 특수권한비트.
(단 파일 생성자뿐만 아니라, 디렉터리 생성자도 권한이 있다. others의 권한이 없어도 u나 g의 권한이 있어서.)
ex chmod 1777 tmp = chmod o+t tmp (단 SunOs 유닉스는 u+t로 지정)
-- 12 End
보안쉘 SSH
- 암호 통신을 이용하여 네트워크상의 다른 컴퓨터에 접속해 원격으로 명령을 실행하거나 파일을 조작하는 응용프로그램 또는 프로토콜
- 암호화된 원격 터미널 서비스, 암호화된 파일 송수신 서비스
- 기존 평문 송수신 서비스의 취약점을 대체하기 위해 설계. 22/tcp 포트
rsh, rlogin : IP Spoofing에 취약
평문송수신 (rsh, rlogin, ftp, telnet 등)
스니핑Sniffing을 통해 정보탈취 및 재전송공격Replay attack에 취약
참고 : ssh를 통해 사용하는 sftp 있음
서버 프로그램?
- 다수의 클라이언트가 원격으로 접속. 동시요청 발생.
- Concurrent server 다중접속서버 1) fork 기반의 multi-tasking 서버
2) 스레드 thread 기반의 multi-thread 서버
3) Select, poll 기반의 multiplexing I/O 서버
연결요청처리(http d) 80/tcp
1. 소켓 생성
2. bind
3. 소켓을 listen 소켓으로 만듦
4. accept 대기
5. 연결요청 처리
6. 새로운 연결소켓 생성
(Listening/Server Process) -> 즉 연결요청을 받아 서비스 프로세스를 띄우는 역할
7. fork로 서비스 프로세스 만들고 프로세스에 소켓 전달
(서비스 프로세스1) ... 유저의 요청 처리
8. 또다시 연결요청이 들어오면, 1~6번을 거쳐 소켓전달
(서비스 프로세스2) ... 유저의 요청 처리
서버를 구동시키는 방식
1. Stand-alone 방식
□ 21/tcp - ftp -> ftp 서비스
□ 23/tcp - telnet -> telnet ~ 서비스
□ 80/tcp - http ... -> http ~ 서비스
다양한 서비스들
-> 개별 서비스 프로세스를 각각 계속 생성하는 방식.
장점 : 서비스 처리 속도가 빠르다
단점 : 서버 리소스를 많이 차지
2. 슈퍼 서버inetd 데몬 방식 (xinetd)
┌┐-> ftp 서비스
││-> telnet ~ 서비스
└┘-> http ~ 서비스
프로세스 연결요청처리를 한번에 범용적으로 처리하고
각각 개별 서비스 프로세스를 생성하는 방식. 커널의 도움이 필요함
공통적인 부분을 처리하는 슈퍼데몬 (데몬의 데몬 프로세스라는 의미)
최초 실행시 /etc/inetd.conf 설정파일 정보를 참조한다 (ftp, telnet, http ...)
Tcpwrapper 서비스와 연동해 서비스별 호스트 접근 제어를 수행할수있다 (요새는 Secure OS를 많이 씀)
장점 : 서버 리소스를 적게 차지
단점 : 서비스 처리 속도가 느리다
서버 프로세스들의 공통점
- 클라이언트의 접속 요청이 있을 때까지 대기하다가,
요청이 들어오면 요청을 처리할 서비스 프로세스(자식)을 실행하는 형태
Secure OS
- 서비스별 접근제어
- 명령어 제한
- su 명령 제어 등등 ...
리눅스 서버 확인
service httpd restart (서버 셋팅해놨을때만 가능)
ps -ef | grep httpd (프로세스 리스트 확인 가능)
netstat -antp | grep : 80 (LISTEN 중인 host넘버가 현재 사용자인지 확인)
-- 13 End
** inetd.conf 파일의 구조
ex ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l -a
1. 서비스명 : /etc/services 파일에 등록된 포트번호를 참조하여 서비스할 프로세스의 포트 결정
2. 소켓타입 : TCP기반은 stream을 사용하고 UDP 기반은 dgram(datagram)
3. 프로토콜 : /etc/protocols 파일에 주어진 프로토콜 중 사용가능한 프로토콜 설정
4. 플래그 : 즉시 다음 서비스 요청처리 (nowait 보통 TCP), 완료될때까지 대기 후에 요청 처리 (wait 보통 UDP)
5. 사용할 사용자 계정 : 실행시킬 사용자 설정
6. 실행 경로명 : 서비스를 실행하는 모듈의 절대 경로
7. 실행 인수 : 프로그램에 인수가 필요할 경우 설정해줌
소켓의 전송타입
1. 스트림방식 : 수신자가 받아주면 연결되어 양방향 전송. TCP ex 전화
2. 데이터그램 방식 : 데이터를 일정 단위로 묶어 한 번 보내고 종료. UDP ex 편지, 택배
TCP는 연결하여 동시에 여러 프로세스를 처리하므로 nowait
UDP는 연결을 맺지 않으므로 wait
짤막지식
well-known port(0-1023) : 잘 알려진 포트 (root, 관리자 권한 필요)
registered port(1024-49151) : 등록된 포트
dynamic port(49152-65535) : 동적 포트
불필요하고 보안상 취약한 서비스들은 비활성화
-Dos 공격에 취약한 simple TCP 서비스 : echo(7/tcp), discard(9/tcp), daytime(13/tcp), chargen(19/tcp) 등. #주석처리 또는 삭제 후 inetd 데몬 재시작
-r계열 서비스 : rlogin, rsb, rexec 등. 인증 없이 관리자의 원격접속을 가능하게 하는 명령어들.
-불필요한 rpc 서비스 : 분산환경에서 서버 응용프로그램에 접근하여 작업 호출을 할 수 있는 서비스. 버퍼 오버플로우 등 취약점.
netstat -antp | grep inetd -> 열려있는 포트 리스트
nmap -sS -p 7-19 192.168.~ ip주소 -> nmap 실무에서도 자주 써서 포트확인
/etc/inetd.conf 파일을 직접 열어보고 싶었지만,
시간이 오래 지나서일까 centos7에는 해당 파일이 없었다.
xinetd를 쓴다던데 이것도 없어서 일단 스킵.
** Tcpwrapper 서비스별 접근 제어(서비스명: tcpd)
-외부 클라이언트에 대해 접근통제
-접근허용 및 차단에 대한 판단 : /etc/hosts.allow와 /etc/hosts.deny 파일 기준 (1순위 allow 2순위 deny 3순위 두파일에 다 없으면 default허용)
-Tcpwrapper를 사용하려면 inetd.conf 파일에 실행경로를 /usr/sbin/tcpd 로 변경
hosts.allow와 hosts.deny의 설정 방법
1. ALL:192.168.1.1 - 192.168.1.1 주소는 모든 서비스 이용 가능
2. in.telnetd:192.168.1.1 - 192.168.1.1주소는 telnet과 ftp 서비스 이용 가능
in.ftpd:192.168.1.1
3. ALL:192.168.1.0/255.255.255.0 - 192.168.1.0(~192.168.1.255) 네트워크에 속한 모든 호스트 모든 서비스 이용 가능
4. ALL:LOCAL - 같은 네트워크에 있는 모든 호스트 허용
5. ALL EXCEPT in.telentd : ALL - 모든 호스트는 telnet을 제외한 모든 서비스 허용
6. in.telentd : 192.168.1. - 192.168.1로 시작하는 IP주소를 갖는 모든 호스트 telnet 서비스 허용
7. in.telentd : .abc.com EXCEPT www.abc.com - www.abc.com를 를 제외한 abc.com 도메인의 모든 호스트는 telcet 허용
LOCAL EXCEPT ALL 등 예약어는 전부 대문자.
shell_command
접근통제 리스트 ACL에 일치하는 것이 있으면 실행하는 명령.
보통 hosts.deny 파일에 이를 설정하여 차단된 호스트에게 경고메시지를 보내는 용도
twist 또는 spawn으로 사용
ex in.telnetd : 192.168.0.0 : twist /bin/echo "접근 거부"
-- 14 END
'(실기) 정보보안기사&산업기사' 카테고리의 다른 글
UNIX/Linux 기본 학습 21~25 (0) | 2024.03.14 |
---|---|
UNIX/Linux 기본 학습 16~20 (0) | 2024.03.13 |
UNIX/Linux 기본 학습 5~9 (0) | 2024.03.11 |
UNIX/Linux 기본 학습 2~4 (0) | 2024.03.08 |
UNIX/Linux 기본 학습 1 (0) | 2024.03.07 |