10장 사용자 관리
디스크 사용량(쿼터) 설정은 넘어간다.
사용자 계정을 통해 사용자는 시스템에 접근할 수 있고, 관리자는 사용자 계정의 권한을 제어해서 사용자들을 통제
- /etc/passwd : 사용자 계정 정보가 저장되어 있다.
1. 로그인 ID : 사용자 계정의 이름. 기본 제한은 32자를 넘을 수 없다.
2. x : 초기 유닉스 시스템에서 사용자 암호를 저장하던 필드. 이제는 /etc/shadow 파일에 별도 보관
3. UID : 사용자 ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
-> 0~999번과 65534번은 시스템 사용자를 위한 예약된 UID(0은 root, 1은 bin, 2는 daemon, 3은 adm 등)
-> 일반 사용자는 UID 1000부터 할당
-> 리눅스 시스템은 로그인 ID가 달라도 UID가 같으면 같은 사용자로 판단한다. 중복에 주의할 것.
4. GID : 그룹 ID. 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장된다.
5. 설명 : 사용자의 실명/부서명/연락처 등 사용자에 대한 일반적인 정보 기록
6. 홈 디렉터리 : 사용자 계정에 할당된 홈 디렉터리의 절대 경로
7. 로그인 쉘 : 사용자의 로그인 쉘
각 필드를 위치 변수($n)에 넣을 수 있다. $1 ~ $7
awk 명령어로 특정 필드를 잘라서 조회할 수 있는데,
cat /etc/passwd | awk -F: '{printf"\n" $1}'
이런 식으로 특정 필드만 뽑아낼 수 있다.
/etc/shadow 파일 : 사용자 암호에 대한 정보를 별도로 관리하는 파일. root 계정으로만 볼 수 있다.
패스워드 필드는
$HashID $Salt $Hash값
3개의 필드로 이루어져 있다(!! 로 표시된 것은 아직 설정되지 않은 것). 해시 알고리즘과 salt값에 의해 평문 패스워드가 변환된 것이 해시값이다.
해시 ID(해시 알고리즘) : 1(표준화된 MD5), 2a(Blowfish), md5(썬 회사의 MD5), 5(SHA-256), 6(SHA-512)
오른쪽으로 갈수록 강직도 높아짐.
같은 값에 같은 해시값이 나오므로, 같은 알고리즘에 같은 해시값이 나올때까지 무작위로 값을 넣어서 뚫릴 수 있다.
그래서 쓰는 것이 salt값. 계속 바뀌는 값을 같이 써서 더 강력한 암호 생성. 하지만 다 털리면 소용없으니 shadow 파일의 보안에 신경을 써야 한다.
pwunconv 명령어로 shadow, passwd 두 파일을 합칠 수 있고(shadow 파일이 없는 것으로 나온다)
pwconv 명령어로 다시 쪼갤 수 있다.
그룹의 경우네는 grpunconv, grpconv
(쓸 일은 없을 것)
/etc/login.defs : 사용자 계정의 설정과 관련된 기본 값을 정의
리눅스에서 사용하는 그룹에는 1차 그룹과 2차 그룹이 있다.
1차 그룹은 해당 사용자가 생성될 때 소속되어 있는 그룹, 2차 그룹은 권한 제어를 위해 나중에 부여하는 그룹
/etc/group : 그룹에 대한 정보가 저장되어 있다.
④ 그룹 멤버 필드는 2차 그룹으로 소속되어 있는 멤버를 나열
그룹 암호 : 그룹 가입 시 특정 비밀번호를 입력해야 하는 것. /etc/gshadow 파일에 분리되어 있다.
user1 사용자 생성 -> user1 그룹 생성됨 -> user1의 1차 그룹은 user1 그룹
user2 사용자 생성 -> user2 그룹 생성됨 -> user2의 1차 그룹은 user2 그룹
user2 사용자를 user1 그룹에 가입시킬 수 있다. -> user2의 2차 그룹은 user1 그룹
사실 그룹에 암호 거는 일은 별로 없다.
사용자 계정 생성하기
useradd [옵션] [로그인 ID]
보통 옵션 여러개 붙일 경우에는 -uog 이런 식으로 붙였었는데, 여기서는 뒤에 붙이는 값이 있다보니 다 따로 쓴다.
-D 명령어로 불러오는 것은 /etc/default/useraddd의 내용이다.
기본 설치 파일은 /etc/skel에 있다. 여기 있는 파일을 복사에 홈 디렉터리로 가져가는 것.
원래는 /etc/skel에서 받아오는 파일을 바꾸려면 -k 명령어를 쓰는 것.
Windows에서 쓰던 adduser 명령어는 리눅스에서는 useradd에 대한 심벌릭 링크로 처리되어 있다. 사용 가능.
시스템 설정 변경 관련 명령어는 /usr/sbin/ 디렉터리에 있다.
useradd user2로 사용자를 추가하면
/etc/passwd 파일에 기본 UID와 GID가 설정되어 있다.
/etc/shadow 파일에 암호가 !!로 되어있다.
passwd user2로 user2의 암호를 설정한다.
옵션을 이용해서 만들어보자.
useradd -s /bin/sh -d /home/usertest3 -u 2000 -G 1000 user3
-> GID를 따로 설정 안했더니 UID와 같게 2000으로 설정됨.
-> 로그인 쉘, 홈 디렉터리, UID, 2차 GID, 사용자명을 설정으로 입력했다.
옵션을 이용해서 만들어보자2
useradd -e 2021-12-30 -f 5 -c "user4 test" user4
-> 계정 만료 날짜 설정, 암호 만료일이 지나도 유예 5일, 사용자 설명
사용자 계정 정보 수정
usermod [옵션] [로그인 ID]
디렉터리, 그룹 변경 등은 미리 만들어놓고 옮기는 과정이 선행되어야 한다.
패스워드 에이징 관련 명령 : 패스워드 기간 관련 설정 관리
chage 명령만 알아두면 된다. 명령 뒤에 날짜를 붙이면 된다.
예시 : chage -m 2 -M 100 -W 5 -I 10 -E 2022-05-05 user44
사용자 계정 삭제
-r 옵션은 반드시 붙일 것. 남기면 어차피 쓰레기다.
-> /etc/passwd에 기록된 홈 디렉터리를 삭제하는 것이다. 다른 곳에 있는 해당 사용자 소유의 파일은 남아있다.
-> find / -user UID -exec rm -rf {} \;
새 그룹 생성, 수정, 삭제는 대충 하고 넘어감
newgrp [그룹명] : 소속 그룹 변경(1차)
* UID와 EUID
UID = Real UID
-> 사용자가 로그인할 때 사용한 계정의 UID
EUID = Effective UID
-> 현재 명령을 수행하는 주체의 UID
실행 파일에 SetUID가 설정되어 있다면
-> 해당 파일을 실행한 프로세스의 UID는 사용자 계정의 UID가 아니라 실행 파일 소유자의 UID
-> 이때 파일 소유자의 UID가 EUID
-> su 명령어로 다른 사용자로 전환하면 EUID가 새로운 사용자로 바뀐다.
/etc/shadow 파일은 root 사용자만 볼 수 있다.
-> root 사용자가 su로 다른 사용자로 전환하면 /etc/shadow 파일을 볼 수 없다.
-> 프롬프트 맨 앞에 EUID가 표시된다.
[root@master: ~]#
[user4@master ~]$
who [옵션] : 현재 시스템을 사용하는 사용자의 정보 출력
w [사용자명] : 현재 시스템을 사용하는 사용자의 정보와 작업 정보 출력
last : 사용자 이름, 로그인한 시간, 로그아웃한 시간, 터미널 번호, IP 주소 출력
UID 확인 : who am i 또는 who -m(실습에서는 작동을 안해서 logname으로 확인)
EUID 확인 : whoami 또는 id
소속 그룹 확인 : group [계정명]
sudo [명령어] : root의 권한으로 명령어 실행
개나소나 sudo를 남발하면 시스템이 개판난다.
명령어가 root 사용자 권한이 필요한 것이라면(sudo 명령어를 실행했다면), 실행 계정이 /etc/sudoers 파일에 있는지 확인하는 과정을 거친다.
이 파일을 직접적으로 수정할 수는 없다. 읽기 전용 파일. 수정하려면 /sbin/visudo 명령 필요(이 명령에는 SetUID가 없다).
사용자계정 호스트=(선택가능계정) 명령어
root ALL=(ALL) ALL
abc ALL=(ALL) ALL
-> abc 계정은 어디에서나 접근 가능하며, 누구의 권한도 빌릴 수 있고, 모든 명령어를 사용할 수 있다.
%그룹 호스트=(선택가능계정) 명령어
-> 특정 그룹에 소속된 사용자들은 특정 호스트(대역)에서 접근 가능하며, 선택가능계정의 권한을 빌려 명령어를 사용 가능
대충 SetUID와 비슷하지만, SetUID가 설정되지 않은 파일에서도 실행 가능하게 해주는 것.
sudo 실행 시 사용자 비밀번호도 입력하기 싫다면 명령어 필드 앞에 NOPASSWD: 입력
AWS EC2 인스턴스에는 ec2-user라는 계정만 활성화되어 있는데, 이 계정이 sudo를 사용하려면 이 과정을 거쳐야 한다.
지금이야 실습하려고 root 계정으로 하지만, 일반적으로는 사용자 계정으로 작업하게 될 것이다.
sudo는 뒤따르는 명령어를 일회성으로 root 권한으로 실행하는거고, su는 아예 특정 사용자 계정으로 전환
su user1 : 이전 사용자 환경 정보를(작업 디렉토리, 프롬프트 등) 그대로 가져간다. 권한은 바뀐다.
su - user1 : user1의 작업 환경으로 넘어간다. 작업 디렉터리도, 프롬프트도 바뀐다.
(root로 넘어가려면 암호 입력 필요)
su로 사용자 왔다갔다 할 때 RUID와 EUID를 잘 알아둘 것.
su도 남발하면 시스템이 개판날 우려가 있으니 특정 사용자만 사용 가능하게 설정하면 좋다.
CentOS 8에서 보안 단계들
외부 -> 방화벽 -> PAM -> App 설정 -> App 이용 가능
특정 사용자만/특정 그룹의 사용자만 su를 사용할 수 있게 하기
1. su 명령어 사용자 제한
- 무식한 방법
chmod 4750 /usr/bin/su
su 명령어 실행 파일에 걸려있는 기존 권한인 4755 권한을 통째로 막아버린다(일반 사용자의 권한 삭제 - 4750).
- 정상적 방법
/etc/pam.d/su 파일을 수정
auth required pam_wheel.so use_uid -> 이 행의 주석을 해제. wheel 그룹에 있는 사용자만 su를 사용 가능하다.
2차 그룹의 구성원 조회 : /etc/group 파일에 있다.
usermod -G [wheel 그룹의 GID] [로그인 ID] 실행해서 수정하면, 입력한 로그인 ID만 su를 사용 가능.
passwd -l user1 해보면 shadow 파일에 user1의 암호가 !!로 되어있다. 잠김.
암호 필드에 !!와 빈칸은 다르다. 전자는 잠긴거고, 후자는 암호 없이도 로그인이 가능한 상태.
*** 파일 및 디렉터리의 소유자/소유 그룹 변경하기
chown, chgrp 명령
chown 사용자ID:그룹ID [파일명/디렉터리명] -> 그룹도 변경
그냥 :그룹ID <- 이렇게 하면 그룹만 변경
-R은 서브 디렉터리의 파일까지 한 번에 변경
이제 지급했던 리눅스 교재 사용. 2장 리눅스 보안-SELinux부터.
방화벽을 거쳐 PAM을 통과할 때 , SELinux를 설정해야 한다. 보통 PAM은 기본값으로 두고 SELinux를 설정한다고 한다.
리눅스에서 제공하는 강력한 보안 기능.
* 보안 레이블(보안 등급) = 컨텍스트(Context)
일반 사용자들에게는 제한된 권한을 부여했으나, root 사용자는 지나치게 강력한 권한이 있어 보안상 취약했다. root가 실수하면 무수한 문제가 발생할 위험이 있었다.
그래서 사용자별 접근통제 및 제어를 통해 시스템을 보호하는데, 이것이 SELinux를 통해 구현된 것이다.
리눅스 시스템에서 접근 제어란 사용자/프로세스가 특정 파일이나 포트와 같은 시스템 자원에 대한 접근을 제어하는 것.
예시) 데몬 프로세스가 요청받는대로 다 보여줘버리면 보안 사고가 발생할 수 있으니까.
리눅스는 일반적으로 DAC(Discretionary Access Control) 접근 제어 모델을 사용
-> 사용자의 권한을 기반으로 파일/자원에 대한 접근 여부를 결정
-> 단점 : 특정 SW에 취약점이 존재했을 때 그 취약점을 통해 보안 사고 발생이 쉽다
SELinux는 MAC(Mandatory Access Control) 모델을 사용.
-> 객체의 보안 레벨과 사용자의 보안 취급인가를 비교해 접근 여부를 결정
-> 각 사용자나 프로세스, 파일에 대한 보안 레이블을 지정하고 사용자나 프로세스에 지정된 보안 레이블과 파일에 지정된 보안 레이블이 연관성이 없으면 접근이 차단된다.
-> 강력하긴 한데 유연성이 떨어진다.
대충 주체가 객체에 접근하기 위해 전자는 권한이 필요하고, 후자는 권한, 보안 레이블, 정책 허용 스위치(Boolean)라는 3가지가 필요하다는 것.
====
주체(Subject) : 객체나 객체 내의 데이터에 대한 접근을 요청하는 능동적 개체(행위자). 사용자, 프로세스가 될 수 있으며, 작업 수행을 위해 객체에 접근.
객체(Object) : 접근 대상이 될 수동적인 개체 혹은 행위가 일어날 아이템(제공자). 컴퓨터, DB, 파일, 프로그램, 디렉터리 등
접근(Access) : 주체와 객체 사이의 정보 흐름. CRUD 행위를 하는 주체의 활동
====
아무튼 주체-객체 간의 연관성이 없으면 연관성 있게 변경해줘야 한다. 이를 가능하게 하는 것이 SELinux Boolean.
-> 프로세스와 파일 간의 컨텍스트가 연관성은 없지만 서로 접근할 필요가 있을 때, 접근을 허용하는 스위치와 같은 기능을 한다. 스위치처럼 온/오프 할 수 있고, 시스템이 운영 중인 상태에서도 정책의 동작을 변경할 수 있음.
SELinux 모드 설정
getenforce : SELinux 작동 여부를 알 수 있다.
-> enforcing : 재부팅하더라도 강제적으로 적용되어 있음.
-> permissive : 임시로 SELinux 해제. 재부팅하면 다시 enforcing
-> disabled : 재부팅되어도 SELinux 사용하지 않음.
setenforce [옵션]
1 or Enforcing : enforcing
0 or Permissive : permissive
설정 파일 /etc/sysconfig/selinux(CentOS 7 이전까지), 지금은 /etc/selinux/config
-> 부팅 시 이 파일을 읽어들이니 에러나지 않게 철자 주의.
-> 파일을 보면 SELINUX=enforcing라고 되어있다.
-> 마지막 줄에 SELINUXTYPE=targeted은 정책 유형을 정의한다. targeted(특정 대상의 프로세스만 보호됨), minimum(최소한의 프로세스만 보호됨), mls(Multi Level Security. 다중 단계 보안)
보호되는 프로세스 목록은 /etc/selinux/targeted/active/modules/ 디렉터리에 있는 파일에서 볼 수 있다. 100, 400에는 접근 제어되는 프로세스가, disabled에는 접근이 제어되지 않는 프로세스들이 존재. 허용이 우선
SELinux Context : 모든 프로세스와 파일에 컨텍스트가 부여된다.
컨텍 확인
프로세스 : ps -Z
파일 : ls -Z
레이블은 4개 필드가 있다.
사용자 : 역할 : 컨텍 유형 : 레벨
사용자는 리눅스 사용자가 아니라 SELinux 사용자를 의미.
역할 : 하나 이상의 유형과 연결되어 SELinux 사용자의 접근을 허용할 것인지 결정하는데 사용
컨텍유형 : 주체가 객체에 접근할 때 서로의 유형이 연관성이 있나 확인
레벨 : mls에서 쓴다. 강제 접근 통제보다 더 강력한 보안에 사용
뭔가 차단되었다는 메시지를 보고, 객체와 주체의 유형을 비교해 맞추는 것이 요점.
객체를 주체에 맞추는 것이 좋다.
홈 디렉터리에서 index.html을 만들었다.
1. 복사해서 /var/www/html에 넣었다.
-> 홈에 있는 파일과 해당 디렉터리의 컨텍은 달랐다.
-> ls -dZ 명령어로 해당 디렉터리와 거기 있는 파일의 컨텍스트를 보니 같았다.
-> 당연히 접속도 되었다.
2. mv로 옮겼다.
-> 달랐던 컨텍 그대로 옮겨졌다.
-> 이제 그 안에 있는 파일과 디렉터리의 컨텍이 다르다.
-> 접속이 안된다. index.html의 내용이 아니라 기본 문서가 나온다.
-> tail /var/log/messages로 로그를 보니, httpd 프로세스가 index.html 파일에 접근하지 못하게 막았다는 메시지가 보인다.
-> For complete SELinux messages run: 에서 메시지를 더 자세히 볼 수 있는 명령어를 알려준다.
-> 실행시켜 보면, 소스 문맥과 대상 컨텍이 다름을 볼 수 있다. 이제 이 컨텍을 설정해야 한다.
chcon [옵션] [파일] : 지정된 파일의 컨텍을 일시적으로 변경
-> chcon -t [컨텍 파일명]
-> 컨텍(보안 레이블)을 지정해야 한다.
-> 수동으로 그 객체의 컨텍을 변경할 수 있다.
restorecon [옵션] [파일] : 지정된 파일의 컨텍을 디렉터리의 컨텍으로 자동 변경
-> restorecon -v 파일명
-> 컨텍을 지정하지 않아도 된다.
-> 수동으로 객체의 컨텍을 변경할 수 없다.
문제가 발생하면, 먼저 tail /var/log/messages에서 "SELinux is preventing~ 머시기"를 찾아야 한다.
-> 여기서 제시되는 명령어를 실행하면 웬만하면 해결된다.
-> 거기에 sealert 명령이 제시되어 있으니, 이것을 실행하면 더 자세하게 볼 수 있다.
시스템에 등록된 컨텍 정책 확인
semanage fcontext -l
-> 여기에 "| grep"으로 뽑아서 보면 된다.
파일을 만들고 컨텍이 부여되고 그 아래에 파일을 생성하면, 그 컨텍이 상속되지 않는다.
상속시키려면 semanage fcontext -a -t [context] ['디렉터리 경로'] 로 추가를 해놔야 새로 만드는 파일/디렉터리에 컨텍이 상속된다.
-> 안그러면 파일 만들고 매번 ls -dZ로 컨텍 확인하고, chcon -t로 컨텍 추가해줘야 한다.
-> 디렉터리 경로 작성 시 '경로(/.*)?'로 작성해서 생성되는 모든 파일에 대해 적용
SELinux Boolean : 주체와 객체의 컨텍 유형이 맞지 않을 경우 접근이 가능하게 변경
위처럼 바꿀 수도 있지만, 같은 파일에 대해 다른 주체가 접근하면 까다로워진다. 그다지 좋은 방법이 아님.
정책의 동작 범위를 바꾸는 것
getsebool [-a | 부울 이름] : 부울 확인
setbool -P boole-name { on | off }
semanage boolean -m { -0 | -1 } boolean-name 명령으로도 설정 가능
0은 off, 1은 on
포트 레이블 : 서비스들이 사용하는 포트에도 보안 레이블이 부여된다. 해당 서비스가 기본적으로 사용하는 포트 외의 포트를 사용하려면 해당 포트에 포트 레이블을 부여해야 한다.
semanage port -l 명령어로 포트 레이블들을 볼 수 있다.
http 기본 포트는 80인데, 8080으로 바꾼다고 되는게 아니다. 해당 포트 레이블인 http_port_t를 지정해야 서비스가 정상적으로 제공된다.
SELinux 문제 해결
1. Permissive 모드 전환(setenforce 0)
2. 파일의 보안 레이블 확인(ls -Z)
3. 포트 레이블 확인(semanage port -l)
4. 부울 확인(getsebool -L)
교재 p.53~86(2장)
1장(티밍)은 쓸 일 없다. 클라우드 환경에서는 알아서 해주기 때문. 그냥 시간 나면 한번 훑자.
1교시 후반 해시(무결성) 알고리즘
3교시 중반 사용자 삭제
7교시
월요일 오전에는 firewalld 설정과 웹 서버
'교육' 카테고리의 다른 글
| [29일 차] 21.08.30 : Linux Server 8 (0) | 2021.08.30 |
|---|---|
| [메모] 21.08.29 : 할 일 (0) | 2021.08.29 |
| [27일 차] 21.08.26 : Linux Server 6 (0) | 2021.08.26 |
| [26일 차] 21.08.25 : Linux Server 5 (0) | 2021.08.25 |
| [25일 차] 21.08.24 : Linux Server 4 (0) | 2021.08.24 |
댓글