새초롬한 일지

Docker 놀이터

새침데기 재열이 — Wed, 31 Jan 2024 12:31:23 +0900

https://labs.play-with-docker.com/

Play with Docker

Play with Docker A simple, interactive and fun playground to learn Docker Login

labs.play-with-docker.com

Docker는 Unix 기반이라 Linux와 명령어 체계가 몹시 비슷하다. 쉽게 말해 포트를 열 수 있는 놀이터 개념이다.

간단하게 웹 페이지 하나 띄워보자.

CLI 안에서,

Ctrl + Insert = Copy

Shift + Insert = Paste

[node1] (local) root@192.168.0.13 ~
$ docker run -itd --name=myweb -p 8000:80 nginx:1.25.1-alpine
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0821defd3706 nginx:1.25.1-alpine "/docker-entrypoint.…" 14 seconds ago Up 13 seconds 0.0.0.0:8000->80/tcp myweb
[node1] (local) [root@192.168.0.13](mailto:root@192.168.0.13) ~
$ vi index.html
[node1] (local) [root@192.168.0.13](mailto:root@192.168.0.13) ~
$ docker cp index.html myweb:/usr/share/nginx/html
Successfully copied 2.05kB to myweb:/usr/share/nginx/html

$ docker stop myweb
dmyweb
[node1] (local) root@192.168.0.13 ~
$ docker rm myweb
myweb

Day 05.

새침데기 재열이 — Wed, 24 Jan 2024 23:59:23 +0900

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

* * * * *

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

ex2) 매주 토요일 오후 1시 1분마다 /etc/init.d/rsyslog restart 하는 작업을 스케줄링 하시오. (※ 요일은 0~7로 설정가능하며 일요일이 0, 7 사용) → 01 13 * * 6 /etc/init.d/syslog restart ex3) 1월~10월까지 2개월마다 1일 12시에 'It's system check time.' 출력.

→ 0 12 1 1-10/2 * /usr/bin/echo 'It’s system check time.’ ex4) 매월 월,수,금 12시 마다 /var/log/ 모든 파일 지워라. → 0 12 1 1-10/2 * /usr/bin/echo 'It’s system check time.’ ex5) 매일 오후 2시 20분에 시간 동기화를 수행한 후 곧바로 OS reboot 해라!! → 0 12 * * 1,3,5 /usr/bin/rm -r /var/log/*

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

SSH를 통해 우리가 작성하고 있는데, 다른 서버에 왔다 갔다 하면 host 파일이 생긴다. 이것을 ssh-keygen을 통해 RSA, DSA(암호 복구 알고리즘)을 던지면, 물어보기 시작한다.

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

디스크 같은 것들이 정상 작동하는지 하드웨어를 검사한다. 이후 부팅 장치를 선택하고 MBR이 로드된다. 그 다음이 부트 로더가 로딩된다. 부트 로더가 로딩되기 전에를 시스템 부팅이라고 한다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

프로젝트에서는 당연히 인증이 필요하다. 우리가 실제로 회원 가입을 하기 위해 구글 인증, 카카오 인증, 네이버 인증 등등을 한다. 이것이 다 API 인 것이다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

John the Ripper는 가장 인기있는 패스워드 크래킹 도구 중 하나이다. 이 도구는 원래 유닉스 운영체제에서 암호를 해독하는 데 사용되었지만, 이제는 윈도우, 리눅스, macOS 등 다양한 플랫폼에서 사용할 수 있다. John the Ripper는 다양한 비밀번호 형식과 암호화 해시를 지원하며, 빠르고 효율적인 해시 알고리즘을 사용하여 암호를 해독한다. 이 도구는 개인 사용자와 전문가 모두에게 유용하며, 시스템 보안 강화와 취약점 평가에 사용된다.

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

작업 예약

=스케줄링=업무 자동화

특정한 시간에 작업 수행 예약 = 업무 자동화

at = 정해진 시간에 한 번만 수행

cron = 주기적으로 수행

우리가 크론탭이라고 불렀던 것이 바로 이 crontab 이다. 요 녀석은 관리하는 데 있어서 편의성을 제공한다.

기본 값은 애스터리스크 다섯 개.

→ 분 시 일 월 요일 이다.

crontab [-u 사용자 ID] [옵션] [파일 이름]

특정 작업을 수행할 수 있는 수행 내역을 작성한다.

일정이 없으면 *로 놔두면 된다.

예시를 들어보면,

30 23 1 * * /usr/bin/ls -l ~user1 > ~user1/cron.out

=매월 1일 23시30분에 해당 작업을 수행한다.

find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

4000 = setUID

2000 = setGID

최상위 디렉터리에서 찾아라. 단, 파일의 권한이 4000 또는 2000 권한이 있어야 한다.

매일 오전 6시마다 SUID/SGID 권한을 갖는 파일들을 확인하고 관리자에게 mail을 보내는 명령어

0 6 * * * /usr/bin/find / -type f $ -perm -04000 -o -perm -02000 $ -exec ls -l {} \; | /bin/mail -s "SUID/SGID LIST" root

crontab 사용 예시

crontab 명령어를 사용하여 예약 명령어를 사용하고 9시 24분에 정확히 이루어졌는지 확인 후 mail 또한 확인한다.

[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:01:23 server1 crond[1170]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 6% if used.)
Jan 22 09:01:24 server1 crond[1170]: (CRON) INFO (running with inotify support)
Jan 22 09:10:01 server1 CROND[2849]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:01 server1 CROND[2942]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:20:28 server1 crontab[2954]: (root) BEGIN EDIT (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) REPLACE (root)
Jan 22 09:23:15 server1 crontab[2954]: (root) END EDIT (root)
Jan 22 09:23:21 server1 crontab[2973]: (root) BEGIN EDIT (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
**Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)**
^C
[root@server1 ~]# **vi /var/spool/mail/root**
You have mail in /var/spool/mail/root

…

From [root@server1.cloud.com](<mailto:root@server1.cloud.com>)  Mon Jan 22 09:24:12 2024
Return-Path: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
X-Original-To: root
Delivered-To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Received: by [server1.cloud.com](<http://server1.cloud.com/>) (Postfix, from userid 0)
id 7D0379BC2; Mon, 22 Jan 2024 09:24:12 +0900 (KST)
Date: Mon, 22 Jan 2024 09:24:12 +0900
To: [root@server1.cloud.com](<mailto:root@server1.cloud.com>)
Subject: SUID/SGID LIST
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: [20240122002412.7D0379BC2@server1.cloud.com](<mailto:20240122002412.7d0379bc2@server1.cloud.com>)
From: [root@server1.cloud.com](<mailto:root@server1.cloud.com>) (root)
</mailto:root@server1.cloud.com></mailto:20240122002412.7d0379bc2@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com></mailto:root@server1.cloud.com>

제대로 잘 왔음을 확인할 수 있다.

crontab 사용 예시 2

[root@server1 ~]# **crontab -l**
24 09 * * * find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root
[root@server1 ~]# **crontab -e**
crontab: installing new crontab
[root@server1 ~]# **tail -f /var/log/cron**
Jan 22 09:23:29 server1 crontab[2973]: (root) REPLACE (root)
Jan 22 09:23:29 server1 crontab[2973]: (root) END EDIT (root)
Jan 22 09:24:01 server1 CROND[2990]: (root) CMD (find / -type f \\( -perm -04000 -o -perm -02000 \\) -exec ls -l {} \\; | /bin/mail -s "SUID/SGID LIST" root)
Jan 22 09:29:52 server1 crontab[3379]: (root) BEGIN EDIT (root)
Jan 22 09:30:01 server1 CROND[3392]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Jan 22 09:31:45 server1 crontab[3379]: (root) END EDIT (root)
Jan 22 09:31:49 server1 crontab[3500]: (root) LIST (root)
Jan 22 09:32:03 server1 crontab[3513]: (root) BEGIN EDIT (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) REPLACE (root)
Jan 22 09:34:04 server1 crontab[3513]: (root) END EDIT (root)
Jan 22 09:35:01 server1 crond[1170]: (root) RELOAD (/var/spool/cron/root)
Jan 22 09:35:01 server1 CROND[3689]: (root) CMD (/bin/bash /root/bin/srvmon.sh)
^C
You have new mail in /var/spool/mail/root
[root@server1 ~]# **ps -ef | grep srvmon**
root      3810  2733  0 09:36 pts/0    00:00:00 grep --color=auto srvmon

cron 연습문제(쉽다!)

20 14 * * * /usr/sbin/clock -w 20 14 * * * /usr/sbin/shutdown -r now

ex6) 3일에서 5일까지 5시,6시,7시에 매 5분마다 time.sh 를 실행 → /05 5,6,7 3-5 * * /bin/bash /root/LABs/time.sh

ex7) 매주 금요일 오전 7시 15분에 time.sh 를 실행

→ 15 7 * * 5 /bin/bash /root/LABs/time.sh

cron 사용 예시 3

매일 12시 정각에 /root/bin/log_backup.sh 실행하여 “년-월-일-backup”으로 압축하여 /BACKUP에 저장한다.

#! /bin/bash 필수!

shell 파일 만들고 바로 권한 준다.

scp파일을 만드는데

keygen을 통해 RSA키가 만들어진다.

[작업 순서]

SSH-Key 생성
backup script 생성
crontab 작성
결과 확인
- /var/log/cron 을 통해 log_backup.sh 수행 확인
- 1분 후 2번 서버에 백업 압축 파일 생성 확인
- 1번 서버에 백업 압축 파일 삭제 확인

자, 따라해보자. 작업 순서를 정하는 것은 중요하다.

SSH-Key 생성

[root@server1 ~]# cd .ssh/
[root@server1 .ssh]# /usr/bin/ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:yekaXWPWHv6O0R4AY4Sk8VL9nqHQI+KHSwIvBVxbqEU [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[RSA 2048]----+
| . oE.o.oo.      |
|  o oo =...     	|
|   +. o ..+.     |
|  o . .oo+o+o    |
|   + . oSo=++o   |
|  . o +o.+.+o+   |
|   . o.oo   + o  |
|      .o     = . |
|      .     ..+  |
+----[SHA256]-----+
[root@server1 .ssh]#

[root@server1 .ssh]# /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): ★엔터★
Enter passphrase (empty for no passphrase): ★엔터★
Enter same passphrase again: ★엔터★
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
SHA256:dcayTVgLkm2/Wvf9c8gbkToCYdnSHz19SY2guclXntI [root@server1.kpc.com](<mailto:root@server1.kpc.com>)
The key's randomart image is:
+---[DSA 1024]------+
|        .o. o. o.  |
|        .=oB oo.o	|
|        =.O.B +.o	|
|       . = @.= +.	|
|        S = =.E  	|
|         . .oo.. 	|
|          .ooo.o.  |
|          .. .oo+	|
|              ..=	|
+----[SHA256]-------+

[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_rsa.pub >> authorized_keys
The authenticity of host 'server1 (192.168.56.101)' can't be established.
ECDSA key fingerprint is SHA256:9rhqPNtu7ePM/+OBI9IQJrOILo6jOZDH32XZFmHbcys.
ECDSA key fingerprint is MD5:53:42:f3:a0:bb:35:eb:ea:75:b5:a4:c2:f6:e7:aa:18.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server1,192.168.56.101' (ECDSA) to the list of known hosts.
root@server1's password:
[root@server1 .ssh]#
[root@server1 .ssh]# ssh server1 cat /root/.ssh/id_dsa.pub >> authorized_keys
[root@server1 .ssh]#

----- server 2----------------------------------------------------------------
[root@server2 ~]# /usr/bin/ssh-keygen -t rsa
[root@server2 ~]# /usr/bin/ssh-keygen -t dsa
[root@server2 ~]# ssh server2 cat /root/.ssh/id_rsa.pub >> authorized_keys
[root@server2 ~]# ssh server2 cat /root/.ssh/id_dsa.pub >> authorized_keys

- 확인 --
[root@server1 .ssh]# scp authorized_keys server2:/root/.ssh/
root@server2's password:
authorized_keys 100% 1012 1.1MB/s 00:00

- 암호 입력 없이 원격 복사 가능 --
[root@server1 LABs]# scp sxid-4.20130802.tar.gz server2:/BACKUP
sxid-4.20130802.tar.gz 100% 115KB 16.4MB/s 00:00
[root@server1 LABs]# ssh root@server2

backup script 생성

[root@server1 bin]# vi log_backup.sh
[root@server1 bin]# chmod 700 log_backup.sh 
[root@server1 ~]# log_backup.sh
…
/var/log/wtmp 
/var/log/cron-20220905
…
[root@server1 bin]# cd /BACKUP/ 
[root@server1 BACKUP]# ls -l
2023-May-05-backup.tar.gz

[root@server1 bin]# crontab -e

[참고] [root@server1 ~]# date Mon Sep 05 09:33:46 KST 2022 $1 $2 $3 $4 $5 $6 (한국표준시)

crontab 작성

[root@server1 ~]# ssh server2
Last login: Mon Sep 05 09:52:31 2022 from server1
[root@server2 ~]#
[root@server1 ~]# crontab –e

/var/log/cron 을 통해 log_backup.sh 수행 확인
1분 후 2번 서버에 백업 압축 파일 생성 확인
1번 서버에 백업 압축 파일 삭제 확인

시스템 Booting & Shutdown

시스템을 올리고 내릴 때 뭐가 먼저 올라가고 뭐가 먼저 내려갈까?

별 거 아닐 수 있지만, 내부의 흐름을 이해하는 취지로 다가가자.

일반적으로 랩탑, 데스크탑 둘 다 메인보드가 있다.

메인보드에 전기가 공급되면 메인보드 배터리에 전기가 들어가면서 BIOS가 켜진다.

그 과정에서 시스템 자체가 부팅되면서 가장 먼저 하는 것이 부트 로더.(부팅을 이끌어낸다.)

부트 로더는 커널을 불러낸다. 우리가 쓰고 있는 부트 로더는 GRUB.

GRUB가 안 되면 커널이 로딩되지 않는다.

부트 로더에서 사용하는 레코드 값을 MBR 이라고 한다. 1번 블록에 저장되어 있으며, 이것이 깨지면 얄짤 없다.

어쨌든, 부트 로더가 돌아가면 커널이 들어오고, 커널이 초기화된다. 시작하기 좋게 만드는 것이다.

여기서 기억해야 할 것은, PID = 1은 systemd 이다.

systemd에 시스템들이 붙게 되고, 로그인 프롬프트가 출력된다.

부팅 시 출력되는 메시지가 있는데, 이것은 dmesg로 확인할 수 있다.

dmesg | more

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

DOCKER

H/W

부팅 절차 Detail Ver.

커널 버전 확인

[root@server1 ~]# **uname -r**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **getconf LONG_BIT**
64
[root@server1 ~]# **sysctl -n kernel.osrelease**
3.10.0-1160.el7.x86_64
[root@server1 ~]# **cat /proc/version**
Linux version 3.10.0-1160.el7.x86_64 ([mockbuild@kbuilder.bsys.centos.org](<mailto:mockbuild@kbuilder.bsys.centos.org>)) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Oct 19 16:18:59 UTC 2020

proc

proc 명령어는 프로세스를 확인할 때 사용한다.

[root@server1 ~]# **cd /proc/**
[root@server1 proc]# ls
1      18    2298  2431  2591  308   48   607   685        crypto       mounts
10     1828  23    2434  2609  309   49   609   689        devices      mtrr
10086  1887  2309  2435  2666  31    535  611   7          diskstats    net
10346  1897  2313  2438  2669  310   536  613   702        dma          pagetypeinfo
10529  1899  2319  2439  2676  311   537  614   719        driver       partitions
10574  19    2323  2442  268   312   538  616   723        execdomains  sched_debug
10595  1964  2328  2446  269   313   539  62    7345       fb           schedstat
11     2     2333  2453  27    314   540  638   7726       filesystems  scsi
1148   20    2337  2455  270   315   541  639   7764       fs           self
1149   2044  2341  2483  271   316   542  64    78         interrupts   slabinfo
1153   2054  2351  2485  2725  32    543  641   789        iomem        softirqs
1154   2080  2362  25    2729  33    544  642   8          ioports      stat
1158   2092  2364  2510  **2733**  3396  545  6422  8862       irq          swaps
116    2093  2374  2515  274   34    546  644   9          kallsyms     sys
1167   2124  2379  2518  275   35    547  645   919        kcore        sysrq-trigger
1168   2128  2387  254   2756  36    548  650   9202       keys         sysvipc
1170   2133  2388  2540  278   37    550  655   9227       key-users    timer_list
12     22    2390  2542  279   38    552  656   9610       kmsg         timer_stats
13     2213  2394  2544  29    39    568  665   9830       kpagecount   tty
14     2227  2398  2552  296   4     569  666   acpi       kpageflags   uptime
1445   2232  24    2560  30    40    57   676   buddyinfo  loadavg      version
1453   2235  2403  2563  304   402   570  677   bus        locks        vmallocinfo
1599   2265  2406  2572  305   433   571  678   cgroups    mdstat       vmstat
16     2288  2410  2576  306   438   59   679   cmdline    meminfo      zoneinfo
1600   2292  2415  2580  3065  46    6    681   consoles   misc
1751   2294  2417  2588  307   47    60   684   cpuinfo    modules
[root@server1 proc]# ps -ef | grep httpd
root     ****10641 **** **2733**  0 11:28 pts/0    00:00:00 grep --color=auto httpd

저 수많은 숫자들이 다 PID 이다.

결국, /proc/ 안에 저 프로세스들이 PID의 이름으로 폴더를 생성하여 프로세스의 기능을 수행하고 있는 것이다.

cd 2733 입력 후 exec(x)를 확인해보면, PID 2733의 프로세스는 /usr/bin/bash 프로세스라는 것을 확인할 수 있다.

init 프로세스와 런레벨

리눅스의 init 런레벨. 1= root 모드(안전모드). root 비밀번호 까먹으면 재설치 얄짤없다.

우리가 흔히 사용하는 GUI는 런레벨 5 = graphical.target

물론 이것은 리소스를 어느 정도 잡아 먹기 때문에 오래 사용하지 않는다면 GUI를 터미널 모드(런레벨 3)로 바꿀 수 있다.

리눅스 시스템 종료 247365

247365란 24시간 일주일 365일 동안을 의미한다. = HA(고가용성) 유지!

전원을 끈다 → 최후의 수단(무조건 계획된 정비 시)

-shutdown -h now

-halt

-poweroff

-init 0

-init 6 #reboot

서버는 5년마다 교체를 해준다. 하드웨어, 교체에 관한 부담을 줄이려고 클라우드를 사용한다.

실무에서 우리가 쓸 일은 거의 없어야 한다.

가장 정상적으로 종료하는 방법 (프로세스가 꺼지고, 커널이 문 닫는)

greceful shutdown

사용자 계정 및 그룹 관리

system, DB, App, cloud, …

이것들은 전부 인증 절차를 요구한다.

=AuthN(인증) + AuthZ(인가, 권한)

시스템에 사용자가 들어온다는 건 시스템에 접근이 허가됐다는 것.

인증이 됐다는 것이다. 정확한 ID와 PW를 가지고.

유저가 일 하러 들어왔으면, 모든 사용자가 스쿱이 다르기 때문에, 거기에 적합한 권한 부여가 동반되어야 한다. 이전에 했던 접근 제어와 비슷하다.

여기서는 그런 것들을 관리해주는 Cognito 라는 것이 있다.

클라우드 상에서 외부에서 들어오는 유저의 관리를 해준다.

리눅스에서 사용자 계정과 관련된 디렉터리

/etc/passwd한 줄 단위로 패턴이 정해져 있는 구조
1. 로그인 ID: 사용자 계정 이름
2. x: 초기 유닉스 시스템에서 사용자 암호 저장 항목
3. UID: User ID 번호. 시스템이 사용자를 구별하기 위해 사용하는 번호
4. 로그인 ID가 다르더라도 UID가 같으면 Linux 시스템은 같은 사용자로 판단, 따라서 UID가 중복되지 않았는지 주의해야 한다.
5. GID: 그룹 ID, 시스템에 등록된 그룹에 대한 정보는 /etc/group 파일에 저장한다.
6. 설명: 사용자의 실명이나 부서 명, 연락처 등 사용자에 대한 일반적인 정보가 기록된다.
  1. chfn 명령어로 설명을 추가
```
[root@server1 ~]# chfn awsuser1
Changing finger information for awsuser1.
Name []: cjw
Office []: cloudteam
Office Phone []: 01012345678
Home Phone []: 01012345677
```
```
Finger information changed.
[root@server1 ~]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001:**cjw,cloudteam,01012345678,01012345677**:/home/awsuser1:/bin/bash
```
7. 홈 디렉터리: 사용자 계정에 할당된 홈 디렉터리의 절대 경로
8. 로그인 셸: 사용자의 로그인 셸을 보여준다.
9. 페도라에서는 보통 배시 셸(/bin/bash)가 default.
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
계정의 인증 역할
사용자 계정 정보가 저장된 기본 파일
/etc/shadow사용자 암호에 관한 정보를 별도로 관리하는 파일휴가, 정직, 휴직 등등의 상황에서 유저 계정을 Lock 걸 수 있다.여기서 /awsuser1로 찾아서 해당 줄을 주석 처리# 해버리면 된다. 그럼 access denied.(근데 이건 꼼수다.)denied, ACCESS DENIED!
```
[root@server1 ~]# usermod -L awsuser1
[root@server1 ~]# grep awsuser1 /etc/shadow
awsuser1:!$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
```
유저 계정 잠금을 해제하는 명령어!가 없음을 확인하자.
```
[root@server1 ~]# grep awsuser /etc/shadow
awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
awsuser2:!!:19740:0:99999:7:::
```
$6 → 암호화 알고리즘 → sha512 → hash 알고리즘
- $1 : $1=MD5 , $5=SHA256 , $6=SHA512 , $2=blowfish , $2a=eksblowfish
- $LtpUrLcm : Salt 값
- $6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN. : $6$SwczSk0y가 해쉬된 결과 값
암호화 방식 변경 SHA512 → MD5현재 SHA512로 구성 중. 이것을 바꿔봄.원복하는 과정은 sha512와 md5만 바꾸면 된다. 확인도 해줄 것<aside> MD5는 현재의 보안 표준에 적합하지 않으므로, 가능하다면 더 안전한 알고리즘(예: SHA-256 또는 SHA-512)을 사용하는 것이 좋다.
</aside>
[root@server1 ~]# authconfig --passalgo=sha512 --update
[root@server1 ~]# tail /etc/login.defs the permission mask will be initialized to 022. UMASK 077 This enables userdel to remove user groups if no members exist. USERGROUPS_ENAB yes **Use SHA512 to encrypt password.** ENCRYPT_METHOD SHA512 [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is sha512 [root@server1 ~]# [root@server1 ~]# authconfig --passalgo=md5 --update [root@server1 ~]# authconfig --test | grep hashing password hashing algorithm is md5 [root@server1 ~]#
사용자가 로그인 할 때 살펴보는 기본 값
암호화 알고리즘의 실체
[root@server1 ~]# usermod -U awsuser1 [root@server1 ~]# grep awsuser1 /etc/shadow awsuser1:$6$SwczSk0y$2adWe5sLLW6qGyKpzwlSQqp2LJmApN.qSIUbBQZGhKgf8qEIe0q7.4K8rirvsPGmaTClbE3DzcmQstipTyJom1:19740:0:99999:7:::
유저 계정을 잠가버리는 명령어
[root@server1 ~]# grep awsuser1 /etc/passwd awsuser1:x:1001:1001:cjw,cloudteam,01012345678,01012345677:/home/awsuser1:/bin/bash [root@server1 ~]# vi /etc/passwd
의심스러운 접근 또는 동작이 잦은 계정,
암호 인증 역할
/etc/group→ DevOps, DevSecOps, FinOps, MLOps그룹에 대한 파일 정보가 저장 되어있다.
1. 그룹 이름: 그룹 이름
2. x: 그룹의 암호 저장
3. GID: 그룹 식별 번호
4. 그룹 멤버: 그룹에 속한 멤버들의 사용자 계정 이름. 쉼표(,)로 사용자 구별(사용자의 2차 그룹)
/etc/passwd 파일의 GID 항목에 지정된 그룹이 기본 그룹이며, 사용자가 속한 2차 그룹은 /etc/group 파일에 지정된다.
모든 유저는 그룹의 소속이다. (회사에서 그룹 = 부서 또는 팀)
dev1, dev2, ops1, ops2, sec1, fin, …
/etc/login.defs 사용자 계정의 설정과 관련된 기본 값을 정의한다.
[root@server1 ~]# cat /etc/login.defs (생략) # Password aging controls: # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 ▪ 다시 xterm 설치 PASS_MIN_LEN 5 PASS_WARN_AGE 7 # Min/max values for automatic uid selection in useradd # UID_MIN 1000 UID_MAX 60000 (생략) # # Min/max values for automatic gid selection in groupadd # GID_MIN 1000 GID_MAX 60000 (생략) UMASK 077 (생략) ENCRYPT_METHOD SHA512 [root@server1 ~]#
/etc/default/useradd사용자 계정 생성을 담당하는 곳.계정을 만들면, 반드시 암호를 주자!
UID의 중복이 허용될 수 있다. -o 옵션. 좋지는 않은 방법이다.
useradd [옵션] 로그인ID
/etc/skel사용자 계정의 홈 디렉터리에 공통으로 들어가야 할 파일이 들어 있다.다양한 옵션에 의해 유저를 커스터마이징 하는 것도 가능하다.기본 로그인 셸을 본 셸로 지정하고GID=1000
```
[root@server1 ~]# useradd -s /bin/sh -d /home/user3 -u 2000 -g 1000 -G 3 user3
[root@server1 ~]# grep user3 /etc/passwd 
user3:x:2000:1000::/home/user3:/bin/sh 
[root@server1 ~]# grep user3 /etc/group
sys:x:3:user3
[root@server1 ~]# grep user3 /etc/shadow 
[root@server1 ~]# passwd user3
[root@server1 ~]# grep user3 /etc/shadow
```
리눅스를 처음 하는 입장에선 root를 사용하지만, 일반적으로는 일반 계정으로 작업할 것이다.
SSH 원격 접근 제어 구성 - 정보보안 감사
1. SSH(원격 접근)에 root 접근을 허용하지 말 것 + root 계정 사용 금지
2. root의 접속을 막아보자.
```
[root@server101 ~]# vi /etc/ssh/sshd_config
38 #PermitRootLogin yes
39 PermitRootLogin no
[root@server101 ~]# systemctl restart sshd
```
ssh나 http 같은 포트를 건드리면 항상 시스템(데몬)을 다시 시작해주는 것을 고려하자.막았다.
1. 일반 사용자의 su - root의 접근을 허용하지 말 것
2. [root@server101 ~]# vi /etc/pam.d/su 6 #auth required pam_wheel.so use_uid >> # 제거 # 추가한 관리자 계정의 su – 접근 개별 허용 설정 [root@server101 ~]# usermod -G wheel adminuser >>> usergroup (wheel) 포함
3. 관리자 계정을 별도로 생성하여 “root 화” 고려
<aside> 위 기능은 그냥 하지 말 것! 몹시 좋지 않음
```
[root@server101 ~]# usermod -u 0 -o adminuser
```
</aside>
서버에 원격 접속 도구를 통해 root로 접근하는 것은 감사에 다 걸리게 된다.
2차 그룹은 3으로 지정
UID=2000
옵션을 지정해서 유저 커스터마이징
계정을 새로 만들면 이 항목에서 파일들이 복사되어, 신규 계정으로 붙여넣기 된다.
skel만 다섯 항목 중 유일하게 디렉터리이다.

사용자 계정 삭제

현재 접속된 상황에서는 해당 유저 삭제가 불가능하다.

그룹 관리 명령

새 그룹 생성하기

[root@server1 ~]# groupadd -g 30000 devteam
[root@server1 ~]# groupadd -g 20000 opsteam
[root@server1 ~]# useradd -g 30000 -u 30001 dev1
[root@server1 ~]# useradd -g 30000 -u 30002 dev2
[root@server1 ~]# useradd -g 20000 -u 20001 ops1
[root@server1 ~]# useradd -g 20000 -u 20002 ops2
[root@server1 ~]# useradd -g 30000 -G 20000 -u 30003 dev3
[root@server1 ~]# useradd -g 20000 -G 30000 -u 20003 ops3
[root@server1 ~]# grep devteam /etc/group
devteam:x:30000:ops3
[root@server1 ~]# grep opsteam /etc/group
opsteam:x:20000:dev3
[root@server1 ~]# grep 30000 /etc/passwd
dev1:x:30001:30000::/home/dev1:/bin/bash
dev2:x:30002:30000::/home/dev2:/bin/bash
dev3:x:30003:30000::/home/dev3:/bin/bash
[root@server1 ~]# grep 20000 /etc/passwd
ops1:x:20001:20000::/home/ops1:/bin/bash
ops2:x:20002:20000::/home/ops2:/bin/bash
ops3:x:20003:20000::/home/ops3:/bin/bash
[root@server1 ~]#

네트워크의 흐름(동영상)

https://www.youtube.com/watch?v=XwphKCS_Kgw

John the Ripper

Day 04.

새침데기 재열이 — Sat, 20 Jan 2024 22:54:13 +0900

리눅스를 배우는 목적 자체가 클라우드 환경 서버를 잘 다루기 위해서 리눅스를 배우는 것이다.

MSA의 핵심 서비스가 컨테이너 이므로, 이 컨테이너의 OS인 리눅스(CentOS, Ubuntu, debian, fedora, … alpine)를 잘 다뤄야 한다.

기업은 말이 좋아 DevOps지, 멀티 유저를 원하는 게 현실이다.

이 용어가 계속해서 발전하고 있어서 FinOps→ MLOps가 되고 있다. 이 단어가 트렌드가 되면서 직업 역군이 될 것이다.

과정이 어렵지, 장착만 하면 게임은 몹시 쉬워질 것이다.

시행착오를 두려워하지 말 것. 리눅스를 10번 재설치하는 한이 있더라도, 그 결과는 가져갈 것.

리눅스를 사용할 때 필요한 명령어

리눅스는 컨테이너를 위해 배우고, 컨테이너는 클라우드를 위해 배운다.

리눅스는 모든 파일을 효과적으로 관리하기 위해 디렉터리를 사용한다.

file 원하는 파일 : 원하는 파일의 정체를 알려준다.

디렉터리(Directory).

컴퓨터에 있는 모든 것들은 전부 파일. 디렉터리 또한 파일임.

파일에 따라 데이터를 저장하는 데 주로 사용된다. 파일의 목적은 데이터 저장이다.

파일은 디스크에 저장된다. 디스크는 최초 사용 시 포맷 후 사용한다. 디스크는 블록(block) 단위로 I/O 하기 때문에, 파일은 물리적으로는 블록(4KB) 안에 저장된다.

모든 블록은 주소를 가진다. 그것은 inode 이다.

파일은 데이터를 가지고 있고, 디렉터리는 저장된 파일을 저장한 파일. 주소를 저장한 파일이다.

/u01/app/oracle/product/12.2.0/db_1/test.txt

모든 파일은 디렉터리 구조로 저장된다. 모든 파일들은 블록 단위로 저장되니까, 주소(inode)가 필요할 것이다.

위 구조는 7개의 주소를 거치고 8번째에 test.txt.가 있는 구조이다. (’/’를 봐야 한다. 최상위 /에도 주소는 존재한다.)

리눅스 파일의 종류와 특징

home: 사용자 홈 디렉터리. 디폴트 값이고 변경 가능.

root: root 계정의 홈 디렉터리. (’/’디렉터리와 다른 것임)

sys: Linux 커널 관련 파일이 있는 디렉터리.

usr: 기본 실행 파일, 라이브러리, 헤더 등 많은 파일이 있다. (not user, Unix System Resource)

boot: 부팅에 필요한 커널(뇌) 파일을 가지고 있다.

etc: Linux 설정에 필요한 각종 파일들

proc: process. 프로세스 정보, 커널 관련 정보를 가지고 있다.

tmp: 시스템 사용 중 발생하는 임시 데이터 저장 디렉터리. 버퍼와 캐시랑 비슷하다고 보면 됨. 재부팅 시 모두 삭제.

var: 시스템 운영 중 발생하는 데이터, 로그 등이 저장되는 디렉터리.

경로명

상대 경로: 현재 내 위치 아래로 갈 때만 쓴다.

절대 경로: 항상 루트(/)부터 시작한다. 특정 위치를 가리키는 절대 경로명은 항상 동일하다.

도움말

명령어 —help

man 명령어 사용

ls (lists)

디렉터리 내용 출력

패턴: ls [옵션] [파일 또는 디렉터리명]

-a 숨김 파일 포함 모두 출력

-d 지정한 디렉터리 자체 정보 출력

-i 첫 번째 행에 inode(주소) 정보 출력

-l 파일의 상세 정보 출력

-A .(마침표)와 ..(두 개) 제외 모든 파일 목록

-F 파일 종류 표시

-L symbolic link의 경우 원본 파일 정보까지 출력

-R 하위 디렉터리 목록까지 출력

-h (human). K, M, G 단위를 사용하여 파일 크기를 사람이 보기 좋게 표시

디렉터리 만들기

mkdir [옵션] 디렉터리명

디렉터리 삭제

rmdir [옵션] 디렉터리명

파일 내용 연속 출력

cat [옵션] 파일명

Curl

URL로 데이터를 전송해 서버에 데이터를 보내거나 가져올 때 사용

내부(local)은 돌라가는 것 확인. 외부는 어떨까?

어떤 IP가 나에게 접속했는지에 대한 로그와 이것을 정렬하는 방법

소셜커머스의 마케팅 방식을 떠올려보자.

특정 IP가 얼마나 접속하는지에 따라서 최다 접속 IP에게 쿠폰을 뿌리는 등의 마케팅 전략을 짜야 할 것이다. IT 없는 마케팅 솔루션은 없다.

그렇다면, 가장 많이 접속한 IP를 찾기 위해선 어떻게 해야 할까?

또한 특정 시간대를 잡아서 하는 방법은 없을까?

명령어로 로그를 봄으로써 나에게 접속한 모든 IP의 시간을 확인한다.
1. 여기서 우리는 awk 명령어를 사용할 것이다.
필터링을 통해 이것을 확인한다.

1.[root@server1 ~]# vi /var/log/httpd/access_log

awk 명령어는 공백(space) 기준 $1, $2, $3, $4 …으로 나뉜다.

127.0.0.1 - - [17/Jan/2024:16:05:04 +0900] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; …생략)

127.0.0.1 = $1

첫 번째 ‘-’ = $2

두 번째 ‘-’ = $3

[17/Jan/2024:16:05:04 +0900] = $4

$4의 데이터를 이용해야 시간을 필터링할 수 있을 것이다.

access_log를 통해 본 시간 로그의 처음부터 끝까지 갈무리해보자.

127.0.0.1 - - [17/Jan/2024:16:04:58 +0900] "GET / HTTP/1.1" 200 400

…

192.168.56.1 - - [19/Jan/2024:10:57:27 +0900] "GET / HTTP/1.1

이다.

다음 명령어를 통해 특정 시간대 기록 상 모든 IP의 접속 횟수를 볼 수 있다. (해당 명령어 콤보는 추가 공부 필요)

192.168.0.56이 537회 접속했다. 단골 IP가 얘구나

사실 이 방법은 고전적인 마케팅 IT 방법이다.

파일 뒷부분 출력

tail [옵션] 파일명 …

default는 10줄이다. = tail -10 파일명

파일 앞부분 출력

head [옵션] 파일명 …

tail과 같다.

파일 또는 디렉터리 복사

cp [옵션] 파일명1/디렉터리명1 파일명2/디렉터리명2

파일 이동 또는 이름 변경

mv [옵션] 파일명1/디렉터리명1 파일명2/디렉터리명2

파일 삭제(취급 유의)

rm [옵션] 파일명/디렉터리명 …

파일 링크

파일 링크는 기존 파일에 새 파일명 붙이는 것

하드(hard)링크: 기존 파일에 새로운 파일명 추가 생성

심벌릭(symbolic) 링크: 원본 파일을 가리키는 새로운 파일 생성(말 그대로 바로가기 파일)

sfile을 다시 만들면 sfile_l이라는 심벌릭 링크가 재활성화될까? inode(주소)가 다른데?

재활성화 됐다. 주소가 아니라 이름으로 따라가는 것을 알 수 있다.

링크 파일을 수정하면 원본도 수정된다.

파일 내용 검색

grep [옵션] 패턴 [파일명]

grep은 패턴조회. 앞이던 중간에 쓰던 대상의 특정 패턴을 조회할 때 사용한다.

파일 찾기(즐겨 씀)

find 경로 검색 조건 [동작]

#응용

뭐가 많이 나올텐데, / or ?를 사용하여 SUI까지만 입력해 찾아보자.

어느 경로에 있어도 특정 경로의 파일 실행(파일 절대경로 지정)

bin/ or 디렉터리 등록

절대경로를 bin/이 아닌 원하는 경로로 지정(LABs/)

절대경로 지정 #2

$PATH에 등록된 경로의 실행파일은 어느 위치에서 든 실행이 가능하게 된다.

파일의 접근 권한(permission)

파일의 접근 제어를 수행한다.

접근 권한에는 rwx(읽기4 쓰기2 실행1) 권한이 있다. 도합 7.

UGO를 생각할 수 있다.(User, Group, Others)

디렉터리와 파일을 구분해야 한다.

파일은 말 그대로 이고, 디렉터리는

읽기: ls명령으로 디렉터리 목록 출력

쓰기: 파일 생성 및 삭제

실행: cd 명령 사용 가능, 파일 이동 및 복사 가능

파일의 default 접근 권한은 644이다.(rw- r — r —)

접근 권한을 변경하고 싶다면 chmod.

UGO 전부 모든 권한을 부여하려면 777이다.

ex) chmod 777 user = user에게 UGO rwx 권한 전부 부여

진수(2, 8, 10, 16)

알던 대로 하자.

연습)

CA(16)

10101100(2)

137(10)

273(8) → 010111011(2) → 187(10)

권한의 사용

시스템에서 사용자가 명령 실행 시 명령어를 찾는 경로와 절차

$PATH에서 명령어 찾음
명령어 파일에 SETUID 설정 확인
명령어를 소유자 권한으로 명령 실행
접근 제어(사용자 단위 접근 제어)
ACL을 통해 접근 가능한 사용자를 구별할 수 있다. = 구체적인 권한 제어ACL을 사용하게 되면 UGO를 건드리지 않고 특정 사용자에게만 권한을 부여한다.
chmod는 UGO라는 한정 영역 안에서 권한을 부여하지만 ACL을 사용하게 되면 UGO를 건드리지 않고 특정 사용자에게만 권한을 부여한다.

예시) setfacl -m u:jeff:rx /BACKUP 사용자 **jeff**에게 /BACKUP 디렉토리에 대한 읽기와 실행 권한을 부여한다.

#실습

ACLdir이라는 디렉터리를 만들어 빈 파일 aclfile을 생성한다.

권한을 확인해준 후
[root@server1 ~]# mkdir /ACLdir
[root@server1 ~]# touch /ACLdir/aclfile
[root@server1 ~]# ls -ld /ACLdir/aclfile
-rw-r--r--. 1 root root 0 Jan 19 15:21 /ACLdir/aclfile
[root@server1 ~]# cd /ACLdir/
[root@server1 ACLdir]# chmod 700 aclfile
[root@server1 ACLdir]# ls -l
total 0
-rwx------. 1 root root 0 Jan 19 15:21 aclfile
[root@server1 ACLdir]# su - jae10
Last login: Wed Jan 17 15:08:59 KST 2024 on :0
[jae10@server1 ~]$ cd /ACLdir/
[jae10@server1 ACLdir]$ ls
aclfile
[jae10@server1 ACLdir]$ cat aclfile
cat: aclfile: Permission denied
[jae10@server1 ACLdir]$ exit
logout
[root@server1 ACLdir]# su - awsuser1
Last login: Thu Jan 18 17:51:05 KST 2024 from 192.168.56.1 on pts/2
[awsuser1@server1 ~]$ cd /ACLdir/
[awsuser1@server1 ACLdir]$ ls
aclfile
[awsuser1@server1 ACLdir]$ cat aclfile
cat: aclfile: Permission denied
[awsuser1@server1 ACLdir]$ setfacl -m u:awsuser1:rw aclfile
setfacl: aclfile: Operation not permitted
[awsuser1@server1 ACLdir]$ exit
logout
[root@server1 ACLdir]# setfacl -m u:awsuser1:rw aclfile
[root@server1 ACLdir]# ls -l
total 0
-rwxrw----+ 1 root root 0 Jan 19 15:21 aclfile
[root@server1 ACLdir]# getfacl aclfile

file: aclfile

owner: root

group: root

user::rwx
user:awsuser1:rw-
group::---
mask::rw-
other::---

[root@server1 ACLdir]# su - jae10
Last login: Fri Jan 19 15:22:20 KST 2024 on pts/1
[jae10@server1 ~]$ cd /ACLdir/
[jae10@server1 ACLdir]$ ls
aclfile
[jae10@server1 ACLdir]$ cat aclfile
cat: aclfile: Permission denied
[jae10@server1 ACLdir]$ exit
logout
[root@server1 ACLdir]# su - awsuser1
Last login: Fri Jan 19 15:23:39 KST 2024 on pts/1
[awsuser1@server1 ~]$ cd /ACLdir/
[awsuser1@server1 ACLdir]$ cat aclfile
[awsuser1@server1 ACLdir]$ exit
logout
[root@server1 ACLdir]# setfacl -m u:awsuser1:rw aclfile
[root@server1 ACLdir]# ls -l
total 0
-rwxrw----+ 1 root root 0 Jan 19 15:21 aclfile
[root@server1 ACLdir]# getfacl aclfile

file: aclfile

owner: root

group: root

user::rwx
user:awsuser1:rw-
group::---
mask::rw-
other::---
#ACL 삭제

[root@server1 ACLdir]# setfacl -x u:awsuser1 aclfile
[root@server1 ACLdir]# ls -l
total 0
-rwx------+ 1 root root 0 Jan 19 15:21 aclfile
[root@server1 ACLdir]#

프로세스(Process)

프로세스는 항상 부모-자식 간의 관계를 갖는다. 각 프로세스는 고유 번호를 가지고 있다 = PID

프로세스의 종류

-데몬 프로세스

특정 서비스 제공을 위해 존재(httpd)

-고아(orphan) 프로세스

자식 프로세스는 살아있지만 부모가 먼저 죽은 경우

1번 프로세스가 대신 부모가 되어 고아 프로세스의 종료를 지원한다.

-좀비 프로세스

자식 프로세스가 실행을 종료했는데도 남아있는 경우.

너무 많으면 Process Table을 낭비하게 되어 일반 프로세스가 실행되지 않을 수 있다.

프로세스의 상세 정보 출력

grep

로그 파일이나, 텍스트 파일에서 특정 문자열을 찾을 때 사용.

파이프( | )로 연결하여 특정 정보를 검색할 때 사용할 수 있다.

자주 보게 될 명령어이다. 꼭 익숙해지도록 하자.

[root@server1 ~]# **ps -ef | grep serviced**
root 29981 3020 0 18:28 pts/1 00:00:00 grep --color=auto serviced
[root@server1 ~]#

pstree -p | grep httpd

PID 3869가 부모 프로세스 이다. 그 밑으로 7개가 눈에 보인다.

Kill

Kill 이라고 해서 무조건 죽이는 건 아니다.

시그널을 보내는 것이다. 그것들 중 프로세스를 죽여버리는 시그널이 있다.

kill [signal] PID …

[signal]:

-2: 인터럽트 시그널(Ctrl+C)

-9: 프로세스 강제 종료

-15: 관련 파일 정리 후 강제 종료

#man을 실행시킨 프로세스를 찾아서 종료시키기

[root@server1 ~]# **ps -f $(pgrep -x man)**
UID        PID  PPID  C STIME TTY          TIME CMD
root      3020  3012  0 09:13 pts/1    00:00:02 -bash
root     31043  3020  0 18:46 pts/1    00:00:00 ps -f
[root@server1 ~]# kill -9 3020

───────────────────────────────────────────────────────────────────────────

Session stopped
- Press <Return> to exit tab
- Press R to restart session
- Press S to save terminal output to file

PID 3020짜리 프로세스를 종료시켰더니, 세션이 끊겼다.

단순히 kill 명령으로 종료되지 않는다면 9번을 보낸다.

killall service

service를 한 번에 없앤다.

손실을 방지하기 위해선 systemctl start service를 해 주는 것이 좋다.

(kill은 비정상 종료이기 때문에)

프로세스 모니터링

예전에는 징후 감지 였는데, 이젠 예방으로 목적이 바뀌었다.

수집데이터 → 징후 감지 → 시각화 → 문제 확보 → 해결책 제시 → 예방

—> 저장 → 분석 → 예측 가능성 확보 → observability(관찰 가능성)

프로세스 관리 도구

top

현재 실행 중인 모든 프로세스에 대한 정보를 주기적으로 출력

iotop

top I/O(입출력) 버전.

Total DISK READ (총 디스크 읽기): 모든 디스크에서 읽은 바이트 수를 표시한다.
Total DISK WRITE (총 디스크 쓰기): 모든 디스크에 기록된 바이트 수를 표시한다.
Actual DISK READ (실제 디스크 읽기): 현재 측정된 디스크 읽기 속도를 표시한다.
Actual DISK WRITE (실제 디스크 쓰기): 현재 측정된 디스크 쓰기 속도를 표시한다.
SWAPIN (스왑 인): 스왑 공간으로의 데이터 전송 양을 표시합니다.
Total DISK IO (총 디스크 I/O): 디스크에서 수행된 총 I/O 작업 수를 표시한다.
DISK COMMANDS (디스크 명령어): 현재 I/O를 수행 중인 프로세스 및 해당 I/O 작업을 표시한다.

시스템 리소스 모니터링을 위한 shell scripts

시스템 리소스 모니터링을 위한 shell scripts #2

[root@server1 ~]# vi srvmon.sh
[root@server1 ~]# chmod 744 srvmon.sh
[root@server1 ~]# ./srvmon.sh         or    ./srvmon.sh > output.txt
Memory          Disk            CPU
95.61%          74%             0.04%
95.66%          74%             0.03%
95.66%          74%             0.03%
…

- terminal 1 열기
[root@server1 ~]# **./srvmon.sh >> srvlog.txt**
-- terminal 하나 더 열기
[root@server1 ~]# **htop**
-- terminal 하나 하나 더 열기
[root@server1 ~]# **yum install -y epel-release**
[root@server1 ~]# **yum install -y stress**
또는,
[root@server1 ~]# **rpm -Uvh stress-1.0.2-1.el5.rf.i386.rpm**
[root@server1 ~]# **stress --cpu 4 --vm 3 --vm-bytes 512m --hdd 2 --hdd-bytes 1024m --timeout 3600s**

이렇게 할 수 있다고 한다...

Day 03.

새침데기 재열이 — Thu, 18 Jan 2024 19:30:57 +0900

오늘은 리눅스 서버 내에서 효율적인 운영 및 사용을 위해 할 수 있는 기본적인 항목을 다루었다.

[root@server1 /]#

하나씩 분해해보면,

root: 현재 접속자 (\u)

@server2 : 접속 서버명 (\h)

~ : 현재 경로(홈) (\W)

]# : 사용자 타입(#, $)

Open Source

누구든지 자유롭게 사용 가능!

메모리, 버퍼, 캐시의 차이

메모리: 주기억장치

버퍼: 느린 장치의 속도를 보호

캐시: 빠른 장치의 속도를 보조

버퍼와 캐시는 둘 다 프로그램을 다른 곳으로 보내기 위해 일시적으로 데이터를 보관하는 데 있어서 그 역할이 같다. 또한 느린 장치와 빠른 장치 간 속도 차이를 지원하는 데에도 같다고 볼 수 있다.
캐시는 작업 속도의 증진만을 위해 사용된다.
버퍼는 속도 차이의 보조 뿐 아니라 개별 작업 간의 콜라보레이션을 도모하기 위해 사용된다.

커널

사람으로 따지면 뇌와 같다.

프로세스 관리, 파일 시스템 관리, 메모리 관리 ...

커널은 실질적으로 하드웨어를 이용하여 사용자의 요구를 처리한다.

프로세스와 쓰레드

프로세스

독립적인 메모리 공간을 가진다. 서로 다른 프로세스는 메모리(자원)를 공유하지 않는다.
자원을 공유하지 않는다는 점에서 독립적으로 실행된다는 것은 안정성이 높다는 것과 같다.
웹 브라우저, 미디어 플레이어 등 독립적으로 실행되는 애플리케이션
크롬 웹 브라우저

쓰레드

동일한 프로세스 내의 쓰레드들은 코드, 데이터, 힙 영역을 공유한다. 허나 자신만의 스택과 레지스터를 가지고 있다.
생성과 종료가 프로세스보다 가볍다.
하나의 쓰레드가 문제가 생기면 같은 프로세스 내의 다른 쓰레드도 영향을 미친다: 프로세스 전체가 종료될 위험이 있다.
웹 브라우저의 탭, 게임에서의 캐릭터 이동, 사운드 처리 등

웹 브라우저의 탭

Vi 편집기

vi의 동작 모드는 vi /경로/파일명
set nu: vi 편집기 line number
[[ or ]] = vi 편집기에서 페이지 home 또는 end
:100 = 100줄로 바로 이동
port range = 0~ 65536번

:w file = file로 전체 다른이름 저장
:1, 10 w file = 1~10줄까지만 file로 다른이름 저장
:10000, $ w file = file 이름으로 10000줄부터 끝까지 다른 이름 저장
:% w file = 전체 부분 다 file 이름으로 다른 이름 저장

u = undo

*Alt+드래그 = 부분 복사. (상당히 편리하다!)
/,? = 검색
g = global. 전부 다 바꾼다. g 없이는 해당 라인의 첫 번째 글자만 바꾼다. g를 넣는 습관을 들이자.

Vi 편집기에서 잠깐만 밖으로 나오고 싶다면

:sh + exit

:! + enter

어제 했던 부분 이어서…

192.168.00.00처럼 주소를 적어서 다른 환경에 접속하는 방법이 흔하지만, 이 주소에 해당하는 hostname으로 접속하고 싶을 때는?

(물론, 서로 trusted server이다. 서로 간 왕래가 잦은 것을 의미하며, 이것의 예시는 Cluster Type(분산 시스템) 이다.)

vi 편집기를 이용한다.

vi /etc/hosts

아까도 말했지만, /etc에는 설정 파일들이 대거 들어 있다. 취급 유의.

그 파일들 중 host에 들어가서 IP, 호스트네임, 도메인 3개 전부로 들어갈 수 있게끔 해줄 것이다.

ip주소/호스트이름/도메인

위 패턴으로 작성한다. 클러스터링(분산 시스템)에 쓰일 서버를 입력하고 저장한다.(꼭 :wq)

그리고 잘 되었는지 IP에 해당하는 호스트이름으로 접속해보고, 도메인으로도 접속해보자.(잘 됨!)

접속 기록을 확인하는 것 까지 마무리 잘 해보자.

cat ~/.ssh/known_hosts

server2.cloud.com으로 접속한 기록이 남아 있다. 위 두 개는 전부 IP로 접속한 기록이다.

셸(Shell)

명령어 해석, 프로그래밍, 사용자 환경 설정

system은 전역 변수(모든 유저)

User는 내 환경

Session은 임시 설정(껐다 키면 사라지는)

특정 유저가 사용하는 셸의 종류를 바꾸고 싶다면

[root@server1 LABs]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001::/home/awsuser1:/bin/sh
[root@server1 LABs]# chsh awsuser1
Changing shell for awsuser1.
New shell [/bin/sh]: /bin/bash
Shell changed.
[root@server1 LABs]# grep awsuser1 /etc/passwd
awsuser1:x:1001:1001::/home/awsuser1:/bin/bash
[root@server1 LABs]#

출력 리다이렉션(중요!)

>은 삭제

>>은 새로 넣어서 뒤에 이어서 쓰기

sar(System Activity Reporting, 시스템 상태 출력)

[root@server1 LABs]# sar 2 5 (시스템 상태를 2초 간격으로 다섯 번 출력)
Linux 3.10.0-1160.el7.x86_64 (server1.cloud.com)        01/17/2024 x86_64 (4 CPU)

08:15:48 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:15:50 PM     all      0.00      0.00      0.25      0.00      0.00     99.75
08:15:52 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:15:54 PM     all      0.00      0.00      0.13      0.13      0.00     99.75
08:15:56 PM     all      0.13      0.00      0.38      0.00      0.00     99.49
08:15:58 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
Average:        all      0.03      0.00      0.18      0.03      0.00     99.77

08:15:48 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:15:50 PM     all      0.00      0.00      0.25      0.00      0.00     99.75
08:15:52 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:15:54 PM     all      0.00      0.00      0.13      0.13      0.00     99.75
08:15:56 PM     all      0.13      0.00      0.38      0.00      0.00     99.49
08:15:58 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
Average:        all      0.03      0.00      0.18      0.03      0.00     99.77

날짜를 텍스트파일에 바로 입력시키기

[root@server1 LABs]# date >> cloud1
[root@server1 LABs]# cat cloud1
Wed Jan 17 20:13:41 KST 2024
[root@server1 LABs]# while true; do date >> cloud; sleep 3; done
^C
[root@server1 LABs]# cat cloud
Wed Jan 17 20:14:30 KST 2024
Wed Jan 17 20:14:33 KST 2024
Wed Jan 17 20:14:36 KST 2024
Wed Jan 17 20:14:39 KST 2024
Wed Jan 17 20:14:42 KST 2024

각각 리소스 모니터링한 파일을 reporting

각각의 리소스를 모니터링한 파일을 로그로 저장하여 볼 수 있게끔 한다.

[root@server1 LABs]# sar 2 10 > server1_$(date '+%Y-%m-%d').log
[root@server1 LABs]# ls
aws    cloud1     server1_2024-01-17.log  svc-file02  svc-file04
cloud  myservice  services                svc-file03  svc-file1
[root@server1 LABs]# cat server1_2024-01-17.log
Linux 3.10.0-1160.el7.x86_64 (server1.cloud.com)        01/17/2024      x86_64

08:20:40 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:20:42 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:20:44 PM     all      0.00      0.00      0.25      0.00      0.00     99.75
08:20:46 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:20:48 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
08:20:50 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:20:52 PM     all      0.00      0.00      0.00      0.12      0.00     99.88
08:20:54 PM     all      0.00      0.00      0.25      0.00      0.00     99.75
08:20:56 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:20:58 PM     all      0.13      0.00      0.38      0.13      0.00     99.37
08:21:00 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
Average:        all      0.01      0.00      0.11      0.03      0.00     99.85
[root@server1 LABs]#

[root@server1 LABs]# iostat 2 10 > server1_iostat_$(date '+%Y-%m-%d').log
[root@server1 LABs]# sar 2 10 > server1_sar_$(date '+%Y-%m-%d').log
[root@server1 LABs]# vmstat 2 10 > server1_vmstat_$(date '+%Y-%m-%d').log

시간 동기화 서버에서 시간 맞추기

[root@server2 ~]# date
Wed Jan 17 20:27:21 KST 2024 (안 맞는다)
[root@server2 ~]# yum -y install ntp
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile

base: mirror.kakao.com
extras: mirror.kakao.com
updates: mirror.kakao.com Package ntp-4.2.6p5-29.el7.centos.2.x86_64 already installed and latest version Nothing to do (이미 설치했다는 뜻)

[root@server2 ~]# systemctl start ntpd (데몬 실행)
[root@server2 ~]# systemctl enable ntpd (부팅 시 자동으로 실행)
Created symlink from /etc/systemd/system/multi-user.target.wants/ntpd.service to /usr/lib/systemd/system/ntpd.service.
[root@server2 ~]# ntpq -p (상태 확인!)
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp-seoul.gomba .STEP. 16 u 1653 64 0 0.000 0.000 0.000
132.226.17.96 .STEP. 16 u - 64 0 0.000 0.000 0.000
*193.123.243.2 125.185.190.74 2 u 1 64 1 5.571 -0.237 104.359
121.174.142.81 220.73.142.66 3 u 3 64 1 14.529 -1.121 138.745
[root@server2 ~]# date
Thu Jan 18 11:39:07 KST 2024 (correct!)
[root@server2 ~]#

Scenario #1

3대 리소스(메모리, 디스크, CPU)의 모니터링 로그를 수집하여 로그 서버(/BACKUP/LOG_SERVER)에 저장하기

1. server1에서 해당 로그를 만든다.

[root@server1 LABs]# cd /BACKUP/
[root@server1 BACKUP]# mkdir LOG_SERVER
[root@server1 BACKUP]# cd LOG_SERVER/
[root@server1 LOG_SERVER]# pwd
/BACKUP/LOG_SERVER
[root@server1 LOG_SERVER]# vi resource-mon.sh
[root@server1 LOG_SERVER]# ls
resource-mon.sh
[root@server1 LOG_SERVER]# chmod 700 resource-mon.sh
[root@server1 LOG_SERVER]# ls
resource-mon.sh
[root@server1 LOG_SERVER]# ./resource-mon.sh
[root@server1 LOG_SERVER]# scp server1_resource_2024-01-17.log root@server2:/BACKUP/LOG_SERVER
root@server2's password:
server1_resource_2024-01-17.log                     100% 4671    73.4KB/s   00:00
[root@server1 LOG_SERVER]#

2. scp를 이용하여 server2의 LOG_SERVER로 보낸 후 확인한다.

[root@server2 ~]# cd /BACKUP
[root@server2 BACKUP]# mkdir LOG_SERVER
[root@server2 BACKUP]# cd LOG_SERVER/
[root@server2 LOG_SERVER]# pwd
/BACKUP/LOG_SERVER
[root@server2 LOG_SERVER]# ls
server1_resource_2024-01-17.log (잘 들어와 있다)
[root@server2 LOG_SERVER]# cat server1_resource_2024-01-17.log
Linux 3.10.0-1160.el7.x86_64 ([server1.cloud.com](http://server1.cloud.com/))        01/17/2024      *x86_64*        (4 CPU)

08:40:04 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:40:06 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
08:40:08 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:40:10 PM     all      0.00      0.00      0.25      0.25      0.00     99.50
08:40:12 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:40:14 PM     all      0.00      0.00      0.13      0.13      0.00     99.75
08:40:16 PM     all      0.00      0.00      0.13      0.25      0.00     99.62
08:40:18 PM     all      0.00      0.00      0.00      0.00      0.00    100.00
08:40:20 PM     all      0.00      0.00      0.12      0.00      0.00     99.88
08:40:22 PM     all      0.00      0.00      0.00      0.25      0.00     99.75
08:40:24 PM     all      0.00      0.00      0.13      0.00      0.00     99.87
Average:        all      0.00      0.00      0.09      0.09      0.00     99.82
Linux 3.10.0-1160.el7.x86_64 ([server1.cloud.com](http://server1.cloud.com/))        01/17/2024      *x86_64*        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.05    0.00    0.18    0.04    0.00   99.73

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               2.33       105.71         5.75     740375      40254

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.13    0.00   99.87

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.25    0.13    0.00   99.62

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.00         0.00         5.97          0         12

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.13    0.00   99.87

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.13    0.25    0.00   99.62

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               4.00         0.00        28.25          0         56

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.13    0.00    0.00   99.87

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               7.00         0.00        52.00          0        104

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.00    0.25    0.00   99.75

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               1.50         0.00        12.00          0         24

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
0.00    0.00    0.13    0.00    0.00   99.87

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0      0 2364932   1280 735380    0    0    27     1   13   17  0  0 100  0  0
0  0      0 2364848   1280 735380    0    0     0     0   27   34  0  0 100  0  0
1  0      0 2364848   1288 735372    0    0     0     6   19   30  0  0 100  0  0
0  0      0 2364848   1288 735372    0    0     0     0   24   30  0  0 100  0  0
0  0      0 2364848   1288 735384    0    0     0     0   16   26  0  0 100  0  0
0  0      0 2364848   1296 735376    0    0     0     6   20   27  0  0 100  0  0
0  0      0 2364848   1296 735384    0    0     0     0   28   33  0  0 100  0  0
0  0      0 2364848   1296 735384    0    0     0     0   14   20  0  0 100  0  0
0  0      0 2364972   1304 735376    0    0     0     6   29   46  0  0 100  0  0
0  0      0 2365096   1304 735384    0    0     0     0  124  105  0  1 99  0  0
[root@server2 LOG_SERVER]#

명령어 단축키 만들기(alias)

너무 긴 명령어를 자주 사용해야 할 것 같은 경우, 명령어 단축키를 만들 수 있다.

바로 alias를 통해서. 고정적인 환경을 변수 처리하여 가볍게 한다.

시나리오: dir5로 바로 이동하고 싶어서 dir5라는 명령어를 만든다.

[root@server1 LABs]# mkdir -p dir1/dir2/dir3/dir4/dir5

[root@server1 LABs]# tree

.
├── aws
├── cloud
├── cloud1
├── dir1
│   └── dir2
│       └── dir3
│           └── dir4
│               └── dir5 (여기로 바로 가고 싶은데…)

[root@server1 LABs]# alias dir5='cd dir1/dir2/dir3/dir4/dir5'
[root@server1 LABs]# dir5
[root@server1 dir5]# (!!)

시나리오: sshchk라는 명령어를 만들어보자. 내용은 ssh 상태 체크이다.

[root@server1 dir5]# alias sshchk='ps -ef | grep ssh'
[root@server1 dir5]# sshchk
root      1147     1  0 18:43 ?        00:00:00 /usr/sbin/sshd -D
root      2239  2108  0 18:45 ?        00:00:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic"
root      2725  1147  0 18:45 ?        00:00:07 sshd: root@pts/0
root      2741  1147  0 18:45 ?        00:00:00 sshd: root@notty
root      2791  2741  0 18:45 ?        00:00:00 /usr/libexec/openssh/sftp-server
root      4677  2743  0 21:24 pts/0    00:00:00 grep --color=auto ssh

가변함수를 통해서 ssh로 정했던 항목을 잠시 $proc으로 바꿀 수 있다.

[root@server1 dir5]# alias sshchk='ps -ef | grep $proc'
[root@server1 dir5]# sshchk ssh
root      1147     1  0 18:43 ?        00:00:00 /usr/sbin/sshd -D
root      2239  2108  0 18:45 ?        00:00:00 /usr/bin/ssh-agent /bin/sh -c exec -l /bin/bash -c "env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic"
root      2725  1147  0 18:45 ?        00:00:07 sshd: root@pts/0
root      2741  1147  0 18:45 ?        00:00:00 sshd: root@notty
root      2791  2741  0 18:45 ?        00:00:00 /usr/libexec/openssh/sftp-server
root      4687  2743  0 21:25 pts/0    00:00:00 grep --color=auto ssh
[root@server1 dir5]# sshchk syslog
root       719     1  0 18:43 ?        00:00:00 /usr/sbin/mcelog --ignorenodev --daemon --syslog
root      1152     1  0 18:43 ?        00:00:04 /usr/sbin/rsyslogd -n
root      4689  2743  0 21:25 pts/0    00:00:00 grep --color=auto syslog
[root@server1 dir5]# alias (alias 자체를 통해서 내가 무엇을 만들었는지 알 수 있다.)
alias cp='cp -i'
alias dir5='cd dir1/dir2/dir3/dir4/dir5'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'
alias l.='ls -d .* --color=auto'
alias ll='ls -l --color=auto'
alias ls='ls --color=auto'
alias mv='mv -i'
alias rm='rm -i'
alias sshchk='ps -ef | grep $proc'
alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
[root@server1 dir5]#

alias는 반영을 시켜줘야 한다. 이것을 보고 환경 설정 파일이라고 한다.

alias를 입력한 디렉터리에 보면 환경설정 파일이 하나 생겼을 것이다.

-rw-r--r--.  1 root root  176 Dec 29  2013 .bashrc

.bashrc 이 녀석에다가 저장해야 하는데,

[root@server1 ~]# vi .bashrc #확인

[root@server1 ~]# source .bashrc

[root@server1 ~]# . .bashrc

이런 과정을 따른다.

방화벽 열고 닫기 - 특정 포트

방화벽이 있다.

어제 index.html을 통해 루프백 주소를 입력하면 윈도우 브라우저에서 접속 가능하게 해 놓은 것이 있는데, 이것은 방화벽을 내려서 가능한 것이었다. (어제자 코드는 방화벽을 아예 내리는 것이었다.)

이번에는 특정 포트만 내려보자. 해당 포트에 해당하는 서비스를 사용할 것이다.

방화벽이 우리에게 대하는 태도는 all deny, 항상 거절이다.

우리가 필요한 부분이 있으면 open(allow)하여 열어야 한다. http의 서비스 중 port 80을 열 것이다.

(이 서비스는 AWS SG에 해당함)

[root@server1 ~]# firewall-cmd --list-all (방화벽이 켜져 있으면 아래처럼 뜰 것임)
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: dhcpv6-client ssh
ports:  
protocols: 
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

공란인 부분을 보면 ports, protocol 등등… 다 아무 것도 없다.

이제 방화벽을 일부 내려 port 80만 열어 보자.

[root@server1 ~]# firewall-cmd --add-service=http --permanent
success


[root@server1 ~]# firewall-cmd --add-port=80/tcp --permanent --zone=public
success
[root@server1 ~]# firewall-cmd --reload
success
[root@server1 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: dhcpv6-client http ssh
ports: 80/tcp (이제 떴다)
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

loopback 주소를 입력하니까, 어제 했던 실습html 페이지가 나왔다.

이제 닫는 것도 해보자. add를 remove로 바꾸면 된다.

[root@server1 ~]# firewall-cmd --remove-port=80/tcp --permanent --zone=public
success
[root@server1 ~]# firewall-cmd --reload
success
[root@server1 ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: dhcpv6-client http ssh
ports: (다시 사라졌다)
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

방화벽 열고 닫는 Shell 만들기

1. fw(firewall)_enable.sh를 만들어 거기에 방화벽을 여는 코드를 저장 및 실행

2. 1을 복사하여 disable.sh라는 이름으로 vi를 이용, 방화벽을 닫는 코드를 저장 및 실행

3. server2로 1과 2를 전송(scp)

[root@server1 ~]# vi fw_enable.sh
[root@server1 ~]# chmod 700 fw_enable.sh

[root@server1 ~]# cp fw_enable.sh fw_disable.sh
[root@server1 ~]# vi fw_disable.sh
[root@server1 ~]# ls -l
total 28
-rw-------. 1 root root 1787 Jan 17 11:40 anaconda-ks.cfg
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Desktop
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Documents
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Downloads
-rwx------. 1 root root  283 Jan 18 15:19 fw_disable.sh
-rwx------. 1 root root  280 Jan 18 15:14 fw_enable.sh
drwxr-xr-x. 2 root root    6 Jan 17 15:21 hello
-rw-r--r--. 1 root root 1818 Jan 17 11:48 initial-setup-ks.cfg
drwxr-xr-x. 3 root root 4096 Jan 17 21:19 LABs
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Music
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Pictures
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Public
drwxr-xr-x. 2 root root    6 Jan 17 15:21 root@192.168.56.102
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Templates
drwxr-xr-x. 2 root root   24 Jan 17 15:54 test
-rw-r--r--. 1 root root 7092 Jan 17 15:28 test.jpg
drwxr-xr-x. 2 root root    6 Jan 17 15:30 Videos
[root@server1 ~]# scp fw_* root@server2:/root
root@server2's password:
fw_disable.sh                                       100%  283    24.6KB/s   00:00
fw_enable.sh                                        100%  280    12.9KB/s   00:00
[root@server1 ~]#

server2를 확인해보자.

[root@server2 ~]# ls
anaconda-ks.cfg  Downloads      hello                 Pictures   Videos
Desktop          fw_disable.sh  initial-setup-ks.cfg  Public
Documents        fw_enable.sh   Music                 Templates
[root@server2 ~]#

잘 도착했다.

히스토리

1000개 한정 어제서부터 썼던 명령어들을 출력해준다.

!를 콤보 키로 사용하여 !숫자를 치면 숫자에 해당하는 명령어가 실행된다.

[root@server1 ~]# history
1 ssh 192.168.0.219

2 exit

3 mkdir hello

4 scp -r hello root@192.168.56.102

5 ssh 192.168.56.102

6 scp -r hello root@192.168.56.102:/root/

7 ssh 192.168.56.102

8 ls

9 test.jpg

10 cat test.jpg

11 ls

12 systemctl stop firewalld.service

13 systemctl start httpd

14 cd /var/

...

프롬프트 설정

프롬프트 설정 변수 = PS1

여러 개의 서버를 식별하는 수단이다.

[root@server1 /]# su - awsuser1
Last login: Thu Jan 18 16:17:47 KST 2024 on pts/0
[awsuser1@server1 ~]$ PS1='(\h:\t)\$'
(server1:16:19:48)$
(server1:16:19:53)$
(server1:16:19:55)$

CPU time scheduling

새침데기 재열이 — Thu, 18 Jan 2024 09:05:41 +0900

https://zzsza.github.io/development/2018/07/29/cpu-scheduling-and-process/

Day 02.

새침데기 재열이 — Thu, 18 Jan 2024 00:24:21 +0900

기본적인 서버 설치 및 운영에 대해 실습하는 시간이었다.

-Network Time Protocol을 위한 사용 시간대 설정

-Server with GUI setting

-Disk partition

-Network setting

...

위 작업 후에 리모트 컨트롤을 위해 PuTTY, MOBAterm을 사용하였다.

세팅 잘 해주고. moba도 마찬가지.

PuTTY 진짜 오랜만이다

MOBA는 처음 사용해보는건데, 얘가 좀 더 우수하긴 하다. 우클릭 만으로 Paste 기능이 되는 것은 PuTTY와의 확연한 차이점이다.

WinSCP를 사용하여 사용자 컴퓨터에서 가상머신으로 SCP(Secure CoPy) 파일 전송을 해 보았다. 이것 또한 예전에 해본 것들이다.

이후 웹서버를 구축하였다. 이게 생각보다 오래 지체되었는데, 이것도 역시 해본 것이지만... 오랜만에 하니 잔실수가 있었다. 이것저것 세팅 하고...

Keep Calm and Carry On - thisisjaewonchoi

나의 가상머신 IP를 윈도우 브라우저에 입력하여 들어가면, 위와 같은 문구를 가진 웹 페이지를 드러내게 할 수 있다.

이것까지가 끝. 실습이 전부였다. 기초 중 기초라고 하는데, 잘 이해하고 있어야겠다.

클라우드 공부 리소스(!!)

새침데기 재열이 — Wed, 17 Jan 2024 12:26:47 +0900

https://gasidaseo.notion.site/gasidaseo/CloudNet-Blog-c9dfa44a27ff431dafdd2edacc8a1863

Day 01.

새침데기 재열이 — Tue, 16 Jan 2024 23:48:24 +0900

OT 및 자기소개, 커리큘럼 소개 등 교육을 진행하기 앞서 기본적인 것들을 했다.

노션의 사용법을 좀 더 공부할 필요가 있어 보인다. 나중에 필기할 때 많이 유용해보인다.

(https://mirror.elice.io/centos/7.9.2009/isos/x86_64/)

4.7GB좀 되는 애랑 우분투 설치. 예~전에 했던 것들이라 추억이 새록새록

자격증 필요 리스트들을 노션으로 작성했는데, 고민이 생겼다.

수업 때는 노션에 작성 후 여기에 추가적으로 옮길지, 아니면 그냥 한 번에 여기에 정리해버릴지.

노션과 티스토리를 연결하는 쉬운 방법은 없나?...

또한 따야 할 자격증 리스트들을 나열해주셨는데,

-AWS Certified Solutions Architect - Associate(SAA)

-리마 2급

-CKA

등등이 있었다.

SAA가 가장 중요하다. 이것만 보고 나아가고, 이것을 무조건 취득해야 잡 페어의 기회가 주어진다. 무조건 따야 한다!

또한 리눅스를 잘 다뤄야 한다고 하셨다. 일단 이 3개에 주목해보자.

나머지는 동기 분들을 알아가는 시간이었다. 경쟁 의식도 필요하지만, 동기 의식이 더욱 중요하다. 같이 해 나가보자. :)

AWS 학습 자료집

새침데기 재열이 — Mon, 15 Jan 2024 21:19:11 +0900

https://gist.github.com/serithemage/9993400aa483c95ade954a1e36b1004b

환영합니다!

새침데기 재열이 — Mon, 15 Jan 2024 21:11:03 +0900

라고는 하는데, 뭘 써야 할지 모르겠다. 그래서 이 곳에 나의 일기와 관련된 컨텐츠들을 적어볼까 한다.

공부, 묵상, 음악, 독서 등등...

근사하진 못하겠지만 그럴싸하게 해볼 수는 있겠다.

새초롬한 일지

Docker 놀이터

Day 05.

작업 예약

작업 예약

crontab 사용 예시

crontab 사용 예시 2

cron 연습문제(쉽다!)

cron 사용 예시 3

시스템 Booting & Shutdown

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

부팅 절차 Detail Ver.

커널 버전 확인

proc

init 프로세스와 런레벨

리눅스 시스템 종료 247365

사용자 계정 및 그룹 관리

리눅스에서 사용자 계정과 관련된 디렉터리

SSH 원격 접근 제어 구성 - 정보보안 감사

사용자 계정 삭제

그룹 관리 명령

네트워크의 흐름(동영상)

John the Ripper

작업 예약

crontab 사용 예시

crontab 사용 예시 2

cron 연습문제(쉽다!)

cron 사용 예시 3

시스템 Booting & Shutdown

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

부팅 절차 Detail Ver.

커널 버전 확인

proc

init 프로세스와 런레벨

리눅스 시스템 종료 247365

사용자 계정 및 그룹 관리

리눅스에서 사용자 계정과 관련된 디렉터리

SSH 원격 접근 제어 구성 - 정보보안 감사

사용자 계정 삭제

그룹 관리 명령

네트워크의 흐름(동영상)

John the Ripper

작업 예약

crontab 사용 예시

crontab 사용 예시 2

cron 연습문제(쉽다!)

cron 사용 예시 3

시스템 Booting & Shutdown

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

부팅 절차 Detail Ver.

커널 버전 확인

proc

init 프로세스와 런레벨

리눅스 시스템 종료 247365

사용자 계정 및 그룹 관리

리눅스에서 사용자 계정과 관련된 디렉터리

SSH 원격 접근 제어 구성 - 정보보안 감사

사용자 계정 삭제

그룹 관리 명령

네트워크의 흐름(동영상)

John the Ripper

crontab 사용 예시

crontab 사용 예시 2

cron 연습문제(쉽다!)

cron 사용 예시 3

시스템 Booting & Shutdown

PaaS, IaaS 를 Docker와 OS, H/W로 엮어서 설명

부팅 절차 Detail Ver.

커널 버전 확인

proc

init 프로세스와 런레벨

리눅스 시스템 종료 247365

사용자 계정 및 그룹 관리

리눅스에서 사용자 계정과 관련된 디렉터리

SSH 원격 접근 제어 구성 - 정보보안 감사

사용자 계정 삭제

그룹 관리 명령

네트워크의 흐름(동영상)

John the Ripper

작업 예약