* swap이 많이 사용된 경우 초기화 후 재설정하기. 부하 최소화 해서 안전하게.

우선, 디스크 및 스왑 정보 확인하고

df -h
swapon -s

확인해서 현재 스왑의 경로를 확인 해 둔다.

작업 중 커널이 새 스왑을 할당하지 않도록 swappiness를 0으로 임시 변경합니다.
sudo sysctl vm.swappiness=0

** 진행하기
# 1. 8GB 임시 스왑 파일 생성 (status=progress 제거)
sudo dd if=/dev/zero of=/swapfile_tmp bs=1M count=8192

# 2. 보안 권한 설정
sudo chmod 600 /swapfile_tmp

# 3. 스왑 포맷
sudo mkswap /swapfile_tmp

# 4. 임시 스왑 활성화
sudo swapon /swapfile_tmp

# 5. 임시 스왑이 정상 등록되었는지 확인 (sda2와 swapfile_tmp 둘 다 나와야 함)
swapon -s

# 6. 기존 스왑(/dev/sda2) 데이터를 임시 스왑으로 낮은 부하로 이관
sudo ionice -c 3 swapoff /dev/sda2

# 7. 기존 스왑(/dev/sda2) 초기화 및 재활성화
데이터가 모두 비워진 /dev/sda2를 깨끗하게 재포맷하고 다시 켭니다.
sudo mkswap /dev/sda2
sudo swapon /dev/sda2

#8. 임시 스왑 해제 및 파일 삭제
본래 스왑이 재가동되었으므로, 임시 스왑을 끄고 파일을 삭제해 디스크 용량을 환수합니다.
sudo ionice -c 3 swapoff /swapfile_tmp
sudo rm -f /swapfile_tmp

#9. swappiness 서버 최적화값 설정
웹서버 메모리 관리를 위해 swappiness를 낮게(10) 설정하여 마무리합니다.Bash
sudo sysctl vm.swappiness=10

#10. 확인
swapon -s

CentOS 7.9 환경에서 구버전 ClamAV(0.103.x)를 설치하고, 공식 차단을 우회하여 마이크로소프트 미러 서버를 통해 바이러스 패턴 파일을 수동으로 업데이트하는 전체 과정을 일목요연하게 정리해 드립니다.
------------------------------
## 1단계: 기존 잘못 설치된 패키지 및 찌꺼기 제거
이전 작업에서 충돌을 일으켰던 최신 RPM 버전이나 저장소 캐시 찌꺼기를 완전히 지우고 기본 상태로 되돌립니다.

# 1. 수동 연결했던 명령어 심볼릭 링크 삭제
sudo rm -f /usr/bin/freshclam /usr/bin/clamscan
# 2. 충돌 위험이 있는 최신 수동 RPM 패키지 제거
sudo rpm -e clamav-1.4.1.linux.x86_64.rpm --nodeps 2>/dev/null || true
# 3. Docker 관련 저장소 파일 삭제 및 Yum 캐시 초기화
sudo rm -f /etc/yum.repos.d/docker-ce.repo
sudo yum clean all
sudo yum makecache

------------------------------
## 2단계: CentOS 7.9 지원 종료(EOL) 대응 및 ClamAV 기본형 설치
CentOS 7의 미러 서버가 닫혔으므로, 시스템 저장소 주소를 과거 보관소(vault.centos.org)로 돌려놓은 뒤 수동 업데이트가 가능한 최소 버전인 ClamAV 0.103.x를 설치합니다.

# 1. CentOS 기본 저장소 주소를 보관소(Vault)로 강제 전환 (한 줄씩 실행)
sudo sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-Base.repo
sudo sed -i 's/#baseurl=http:\/\/mirror.centos.org/baseurl=http:\/\/vault.centos.org/g' /etc/yum.repos.d/CentOS-Base.repo
# 2. 메타데이터 재생성
sudo yum clean all && sudo yum makecache
# 3. CentOS 7.9용 ClamAV 기본 패키지 설치
sudo yum install -y clamav clamav-update

------------------------------
## 3단계: 자동화 우회 쉘 스크립트 작성 및 등록
공식 자동 업데이트(freshclam)는 차단당하므로, 마이크로소프트 공식 리눅스 패키지 서버에서 순수 원본 주소를 실시간 다운로드 바(Bar)와 함께 가져오는 우회 스크립트를 생성합니다.

sudo tee /root/clamav_manual_update.sh << 'EOF'
#!/bin/bash
set -e

echo "=========================================="
echo " ClamAV 바이러스 패턴 수동 업데이트"
echo "=========================================="

# 1. 기존 백그라운드 자동 업데이트 서비스 중지
echo "[1/4] 기존 freshclam 서비스 중지 중..."
sudo systemctl stop clamav-freshclam 2>/dev/null || true

# 2. 임시 디렉터리로 이동하여 마이크로소프트 실제 ClamAV 패키지 경로에서 다운로드
echo "[2/4] 최신 바이러스 패턴 파일 다운로드 중..."
cd /tmp

echo "-> 1. main.cvd 다운로드 중 (Microsoft 공식 경로)"
wget --progress=bar:force https://packages.microsoft.com/clamav/main.cvd -O main.cvd

echo "-> 2. daily.cvd 다운로드 중 (Microsoft 공식 경로)"
wget --progress=bar:force https://packages.microsoft.com/clamav/daily.cvd -O daily.cvd

echo "-> 3. bytecode.cvd 다운로드 중 (Microsoft 공식 경로)"
wget --progress=bar:force https://packages.microsoft.com/clamav/bytecode.cvd -O bytecode.cvd

# 3. 기존 데이터베이스 폴더 정리 후 파일 이동
echo "[3/4] 데이터베이스 폴더 교체 및 소유권 설정 중..."
sudo rm -rf /var/lib/clamav/*
sudo mv /tmp/main.cvd /tmp/daily.cvd /tmp/bytecode.cvd /var/lib/clamav/

# ClamAV 사용자 권한 부여 (CentOS 7 기본값인 clamupdate 또는 clamav 자동 감지)
if id "clamupdate" &>/dev/null; then
    sudo chown -R clamupdate:clamupdate /var/lib/clamav/
else
    sudo chown -R clamav:clamav /var/lib/clamav/
fi

# 4. 업데이트 결과 및 버전 확인
echo "[4/4] 업데이트 완료! 현재 ClamAV 버전 및 패턴 정보:"
echo "------------------------------------------"
clamscan --version
echo "=========================================="
EOF

------------------------------
## 4단계: 스크립트 실행 및 최신 바이러스 패턴 주입
스크립트에 실행 권한을 부여하고 실행하여 최신 바이러스 데이터베이스를 서버에 먹여줍니다.

# 1. 스크립트 실행 권한 부여
sudo chmod +x /root/clamav_manual_update.sh
# 2. 수동 업데이트 스크립트 실행
sudo /root/clamav_manual_update.sh

(※ 결과창에 ClamAV 0.103.11/28xxx 형태로 최신 데이터베이스 고유 번호가 표기되면 패치가 완벽하게 성공한 것입니다.)
------------------------------
## 5단계: 불필요한 경로를 제외하고 서버 악성코드 스캔하기
서버 부하와 스캔 시간을 크게 잡아먹는 가상 폴더(^/proc, ^/sys, ^/dev)를 제외한 후 실시간 서버 전체를 정밀 검사합니다.

sudo clamscan -r -i --exclude-dir=^/proc --exclude-dir=^/sys --exclude-dir=^/dev /


* -r: 하위 디렉터리까지 정밀 스캔
* -i: 정상 파일은 지나치고 감염된(Infected) 파일만 화면에 출력

------------------------------
## 📅 향후 관리 방법 (매일 자동 패치 예약)
매번 수동으로 켜지 않고 시스템이 자동으로 매일 새벽 2시에 백신 패치를 받아오게 하려면 크론탭 설정을 추가해 둡니다.

# 1. 크론탭 수정창 진입
sudo crontab -e
# 2. 맨 아래 줄에 다음 내용 추가 후 저장 (:wq)0 2 * * * /root/clamav_manual_update.sh > /dev/null 2>&1

정리해 드린 가이드를 바탕으로 터미널에 하나씩 입력해 보시면 안전하고 깨끗하게 수동 백신 세팅을 끝마치실 수 있습니다.
추후 5단계 전체 검사 도중 감염 파일(FOUND)이 또 발견되어 안전한 조치나 격리 방법이 필요하시다면 언제든 편하게 질문을 이어서 해주세요!

CentOS 7.9 환경의 경우, 기본 EPEL 저장소에서 제공하는 ClamAV의 최신 패키지 버전이 낮아 yum update를 수행하더라도 차단이 풀리지 않는 경우가 많습니다. [1, 2] 
Cisco Talos(ClamAV 개발사)가 제공하는 공식 Linux RPM 바이너리 패키지를 수동으로 설치하여 엔진 버전을 최신으로 끌어올려야 정상적인 업데이트가 가능합니다. 아래 순서대로 작업을 진행해 주세요. [3, 4] 
------------------------------
## 1단계: 기존 구버전 패키지 완전히 삭제
버전 충돌을 방지하기 위해 설치되어 있던 구버전 ClamAV 관련 패키지를 먼저 제거합니다. (기존 설정 파일이 지워질 수 있으니 백업이 필요하다면 /etc/clamd.d/ 폴더를 미리 복사해 두세요). [2, 4, 5] 

sudo yum remove -y clamd clamav-data clamav-update clamav-filesystem clamav clamav-devel clamav-lib

------------------------------
## 2단계: 최신 독립형(RPM) 패키지 다운로드 및 설치
공식 다운로드 서버에서 현재 지원되는 최신 릴리스 패키지를 받아 직접 설치합니다. [4] 

# 1. 임시 작업 디렉터리로 이동
cd /usr/local/src
# 2. ClamAV 공식 Linux x86_64 패키지 다운로드 (버전 1.4.1 기준)
sudo wget https://www.clamav.net/downloads/production/clamav-1.4.1.linux.x86_64.rpm
# 3. 다운로드한 RPM 패키지 강제 설치 
sudo rpm -ivh clamav-1.4.1.linux.x86_64.rpm

(설치 중 의존성 오류 발생 시, 해당 패키지를 yum install로 설치 후 재시도)
------------------------------
## 3단계: 쿨다운(차단 기록) 해제 및 수동 업데이트
버전 업그레이드 후에도 기존 차단 기록(Mirrors 데이터)으로 인해 업데이트가 실패할 수 있습니다. [6] 

# 1. 서비스 중지 및 캐시 파일 삭제
sudo systemctl stop clamav-freshclam 2>/dev/null
sudo rm -f /var/lib/clamav/mirrors.dat /var/lib/clamav/daily.cvd /var/lib/clamav/main.cvd
# 2. 데이터베이스 강제 업데이트
sudo freshclam

------------------------------
## 4단계: 버전 검증 및 주의사항
설치 후 아래 명령어로 최신 버전(1.x)을 확인합니다. [7, 8] 

clamscan --version

⚠️ 필수 참고: CentOS 7은 2024년 6월 30일부로 지원이 종료(EOL)되었습니다. 향후 보안 위협에 노출될 수 있으므로, Rocky Linux 9 등 최신 OS로의 마이그레이션을 강력히 권장합니다. [9] 

[1] [https://www.danami.com](https://www.danami.com/clients/knowledgebase/302/How-can-I-fix-the-anti-virus-signature-service-stopping-with-the-error-You-are-running-an-out-of-date-version-of-ClamAV-or-FreshClam-or-You-have-been-blocked-by-the-CDN.html?language=portuguese-br)
[2] [https://serverfault.com](https://serverfault.com/questions/995435/your-clamav-installation-is-outdated)
[3] [https://www.youtube.com](https://www.youtube.com/watch?v=DOopgX-oxas&t=2)
[4] [https://velog.io](https://velog.io/@mimic1995/CentOS7-clamav-%EC%84%A4%EC%B9%98)
[5] [https://gist.github.com](https://gist.github.com/fernandoaleman/50b134b987297f97c803c91b591e5c52)
[6] [https://docs.clamav.net](https://docs.clamav.net/faq/faq-freshclam.html?highlight=update)
[7] [https://www.transip.eu](https://www.transip.eu/knowledgebase/700-installing-clamav-in-centos-almalinux)
[8] [https://hostpresto.com](https://hostpresto.com/tutorials/how-to-install-clamav-on-centos-7/)
[9] [https://forum.centos-webpanel.com](http://forum.centos-webpanel.com/centos-7-problems/clamav-database-update-blocked-by-cdn/)

설치 완료 후 실행 경로가 맞지 않다면

공식 RPM 패키지로 수동 설치할 경우, 실행 파일(freshclam, clamscan)이 일반적인 시스템 경로가 아닌 /usr/local/bin/ 디렉터리에 설치되기 때문에 발생하는 현상입니다. 시스템이 이 경로를 인식하지 못해 명령어를 찾을 수 없다고 나오는 것입니다. [1] 
아래의 순서대로 절대 경로를 지정하여 실행 파일의 위치를 바로잡아 주면 정상적으로 동작합니다. [2] 
------------------------------
## 1단계: 절대 경로로 명령어 위치 확인하기
실행 파일이 해당 위치에 잘 들어있는지 먼저 확인합니다. [2] 

ls -l /usr/local/bin/freshclam
ls -l /usr/local/bin/clamscan

(파일 목록이 정상적으로 출력된다면 설치는 완벽히 완료된 상태입니다.)
------------------------------
## 2단계: 시스템이 명령어를 인식하도록 심볼릭 링크 연결
어느 위치에서든 freshclam과 clamscan을 바로 입력할 수 있도록 표준 시스템 명령어 경로(/usr/bin/)에 링크를 걸어줍니다.

sudo ln -sf /usr/local/bin/freshclam /usr/bin/freshclam
sudo ln -sf /usr/local/bin/clamscan /usr/bin/clamscan

------------------------------
## 3단계: 샘플 설정 파일 활성화 (필수)
공식 RPM 패키지는 기본 설정 파일이 example 상태로 제공되어 그대로 실행하면 에러가 납니다. 이를 실제 설정 파일로 복사하고 활성화해 주어야 합니다. [1, 2] 

# 1. 설정 디렉터리로 이동
cd /usr/local/etc
# 2. 샘플 파일을 실제 설정 파일로 복사
sudo cp freshclahttp://m.conf.sample freshclam.conf
sudo cp clamd.conf.sample clamd.conf
# 3. 설정 파일 내부에 적힌 주석용 'Example' 문자열 제거 (제거해야 정상 작동)
sudo sed -i 's/^Example/#Example/' freshclam.conf
sudo sed -i 's/^Example/#Example/' clamd.conf

------------------------------
## 4단계: 업데이트 다시 실행하기
이제 시스템이 명령어를 완전히 인식하므로, 차단 캐시를 지우고 업데이트를 재시도하면 정상적으로 데이터베이스가 다운로드됩니다. [2] 

# 1. 기존 차단 로그 캐시 삭제
sudo rm -f /usr/local/share/clamav/mirrors.dat
# 2. 업데이트 실행
sudo freshclam

업데이트가 완료되면 바로 sudo clamscan -r -i / 명령어를 사용해 전체 서버 악성코드 검사를 시작하실 수 있습니다. 혹시 freshclam 진행 중 다른 에러 문구가 출력된다면 편하게 말씀해 주세요!

[1] [https://github.com](https://github.com/Cisco-Talos/clamav/issues/946)
[2] [https://docs.clamav.net](https://docs.clamav.net/faq/faq-troubleshoot.html)

만약, 모두 설치 후 아래와 같은 메세지가 보인다면,

[root@svr etc]# clamscan --version
clamscan: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /usr/local/lib64/libclamav.so.12)
clamscan: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /usr/local/lib64/libclamav.so.12)
clamscan: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /usr/local/lib64/libclamav.so.12)
clamscan: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /usr/local/lib64/libclamav.so.12)
clamscan: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /usr/local/lib64/libclamav.so.12)

이 오류는 CentOS 7.9의 핵심 시스템 버전(GLIBC 2.17)이 너무 낮아서, 최신 ClamAV 1.4.1 패키지가 요구하는 사양(GLIBC 2.27 이상)을 충족하지 못해 발생하는 문제입니다.CentOS 7 환경에서 GLIBC를 강제로 업데이트하면 전체 운영체제가 망가져 부팅이 안 될 수 있으므로 절대 무리하게 GLIBC를 수동 빌드하시면 안 됩니다.

이때는 사용이 불가 하니 설치를 중지하고 이전 버젼을 설치하거나 다른 방법을 강구해야 한다

설정파일 구문오류 체크하기
#lsyncd -nodaemon /etc/lsyncd.conf

파일 실시간 동기화할때 재부팅으로 전체가 다시 시작하는 경우 빠르게 처리 할 수 있는 설정

#vi lsyncd.conf

1. 원격 백업 설정
sync {
    default.rsync,
    source="/home",
    target="A",
    exclude={'/temp'},//위 source를 기준으로 입력한다
    delay = 10,
    rsync = {
        archive = true,
        compress = false, //로칼에서 백업시 압축하지 않는게 빠르다
        whole_file = false,
        acls = true,
        verbose = true,
        _extra = { "--size-only", "--update" }, // size나 수정일에 대해서만 체크한다.
        rsh = "/usr/bin/ssh -p 22 -o StrictHostKeyChecking=no"  //port와 ssh접속에 문제 없다면 생략가능
    }
}

2. 로칼 백업 설정

sync {
    default.direct,
    source="/home/user",
    target="/backup/user",
    exclude={'/thumbs','/thumbs2'},
    rsync = {
        archive=true,
        compress = false,
        whole_file = true,
        acls = true,
        verbose = true,
        _extra = { "--size-only", "--update" }
    }
}

위에 사용된 옵션 설명

1. archive = true
의미: 아카이브 모드(-a 옵션)를 사용합니다.
상세: 리눅스 파일의 거의 모든 속성을 유지하며 복사합니다. 여기에는 하위 디렉토리 재귀 복사(-r), 심볼릭 링크 유지(-l), 권한 유지(-p), 타임스탬프 유지(-t), 그룹(-g) 및 소유자(-o) 정보 유지가 포함됩니다. 가장 기본적이고 필수적인 옵션입니다.
2. compress = false
의미: 전송 시 압축을 하지 않습니다(-z 옵션 해제).
상세: 네트워크 대역폭이 충분하거나, 지금처럼 이미지 파일(이미 압축된 파일)을 옮길 때는 false로 두는 것이 좋습니다. 압축을 켜면 CPU 사용량만 늘어나고 전송 속도는 오히려 느려질 수 있기 때문입니다.
3. whole_file = false
의미: rsync의 '델타 전송(Delta Transfer)' 알고리즘을 사용합니다.
상세:
false일 때: 파일의 변경된 부분만 찾아내서 전송합니다. CPU 사용량은 늘어나지만 네트워크 전송량은 줄어듭니다.
true일 때: 파일이 조금만 바뀌어도 파일 전체를 다시 보냅니다.
운영 서버 팁: 네트워크가 매우 빠르고 CPU 부하를 줄여야 한다면 true가 유리하지만, 일반적으로 원격지 복사에서는 false가 네트워크 효율이 좋습니다.
4. acls = true
의미: ACL(Access Control Lists) 정보를 유지합니다(-A 옵션).
상세: 일반적인 리눅스 권한(rwx) 외에 더 복잡하게 설정된 확장 권한까지 그대로 복사합니다. 특정 사용자나 그룹에 별도로 부여된 권한이 있는 서버 환경이라면 이 옵션을 켜야 권한이 꼬이지 않습니다.
5. verbose = true
의미: 전송 과정을 상세하게 기록합니다(-v 옵션).
상세: 어떤 파일이 전송되고 있는지, 결과는 어떠한지 로그 파일(lsyncd.log)에 상세히 남깁니다. 처음 세팅하고 모니터링할 때 유용하지만, 파일 개수가 수백만 개라면 로그 파일이 너무 커질 수 있으니 안정화된 후에는 false로 바꾸기도 합니다.

lsyncd를 실행전 rsync로 전체 백업을 수행 후 에 해주면 좋다

- 전체
rsync -avP --delete --bwlimit=50000 root@10.0.0.1:/home/user /home/

명령어 옵션 설명
-a (archive): 권한, 소유자, 타임스탬프 등 모든 속성을 그대로 유지합니다.
-v (verbose): 어떤 파일이 복사되고 있는지 상세히 보여줍니다.
-P (progress/partial): 전송 진행률을 보여주고, 중간에 연결이 끊겨도 다시 실행하면 끊긴 지점부터 이어서 복사합니다. (2TB 작업 시 필수)
--bwlimit=50000: 전송 속도를 약 50MB/s로 제한하여 운영 서버의 네트워크 부하를 줄입니다.

잘 실행 되던 쿼리가 갑자기 느려 지는 경우가 있다.
또, 여러 조건에 따라서 정렬이 바뀌는 이상한 현상도 발행하는 경우가 있다.

모두, 통계값에 때문에 발행하는 문제라고 한다.
통계값에 따라서 쿼리 옵티마지져가 다르게 계산해 인덱스를 다르게 타는 현상때문에 그렇다고 한다.

그럼, 이런 현상을 막고 일관되게 쿼리가 실행되게 하려면 어떻게 해야 할까?
통계값이 자주 변경되면서 쿼리 실행 계획인 달라 진다면, 통계값을 어느정도 일관되게 유지 하면 된다.

자 통계값을 관리하는 방법을 알아보자.

현재, 운영중인 mysql서버는 5.5.6 버젼이다.
이 버젼에서는 innodb_stats_on_metadata 라는 설정값이 있고,
이 설정은 통계를 업데이트 하는 갱신하는 방법을 지정하는 설정이다.
값이 ON 이면 show table status, show index, analyze table 등으로 통계가 갱신이 된다.
심하게는 heidsql 에서 테이블 정보를 보는 과정에서도 갱신이 되기도 한다고 한다.

이렇게 자주 갱신되다 보면, 쿼리 실행 계획이 자주 변경되 일관된 실행계획을 유지하기가 어려운 경우가 발생하기도 한다.

이 설정을 OFF 로 하게 되면,
단순 조회만으로 통계를 갱신하지 않게 되어 일관된 실행 계획 유지가 가능하다.
이 경우 자동 갱신은 테이블 데이타의 1/16(6.25%) 이상 변경 되면 내부적으로 자동 갱신 된다고 한다.
수동으로 할 때는 analyze table 로 하면 된다.

이 마져도 메모리에 통계 정보가 저장되기 때문에 mysql 재시작 하게 되면 통계를 재 수집하게 된다.


mysql5.6 이상 버젼에서는,
innodb_stats_persistent = ON 을 통해서 메모리가 아닌, 시스템 테이블에 영구 보존이 가능해
서버 재시작시에도 갱신으로 인한 부하가 발생되지 않는다고 한다.


어쨋든, 나는 mysql 5.5.6을 사용하니
SET GLOBAL innodb_stats_on_metadata = OFF;
하고, 필요시 테이블 마다
ANALYZE TABLE 테이블명
하는 방식으로 해야겠다

tail 명령과 리디렉션(>) 으로 조합해서 할 수 있다.

tail -n [줄 수] [원본 로그 파일 경로] > [백업 파일 경로]

예로, 

tail -n 100 /var/log/syslog > /home/user/syslog_recent_backup.log

로그 파일을 비우는 기능을 사용할때 기존 로그를 전체 백업하긴 부담 스럽다면, 

이렇게 최근 몇줄만 백업하고 나머지는 삭제하는 방법 좋을거 같다.

tail -n 100 /var/log/syslog > /home/user/syslog_recent_backup.log

truncate -s 0 /var/log/syslog

로그파일을 삭제 하지 않고 비우는 방법

1. 로그 파일은 그대로 유지하면서 내용만 비우기 : 수동

- #cat /dev/null > /var/log/syslog

ㄴ파일의 내용을 /dev/null 파일의 빈 내용으로 덮어쓰는 방법

- #truncate -s 0 /var/log/syslog

ㄴ파일 내용을 비운다. 파일의 권한 속성은 그대로 유지 된다.

2. 로그 주기적인 관리 : 자동

- logrotate 도구를 사용해 주기적으로 파일의 일정 수준으로 자동 관리 할 수 있다.

- logrotate 설정은 /etc/logrotate.conf 또는 /etc/logrotate.d/ 하위 설정 파일을 관리를 통해 자동 관리가 가능하다.

* 주의 사항

로그를 비울때는 시스템 또는 실행중인 서비스에 문제가 될 지 검토 후 진행을 하고,

필요시 백업을 하고 비우도록 하자.

복제 서버에서 binlog 포맷을 변경하는 방법이다.

우선, 슬레이브 서버를 멈춘다

mysql>stop slave;

만약 슬레이브서버가 체인 형태로 더 있다면, 모든 slave서버를 중지 시킨다.

두번째로, 마스터서버에서 기존 로그를 닫고 새로 쓸 수 있도록 flush logs를 해준다.

mysql>flush logs;

그리고, binlog format을 원하는 포맷으로 변경한다.

mysql>set global binlog_format = 'ROW';

set global 로 변경했을때는 현재 서비스중인 상태에 적용하는 것으로

만약 서버가 재시작 되면 설정이 이전으로 돌아 가게 된다.

따라서, my.cnf 설정 파일에도 변경된 정보를 추가해 준다.

[root@]# vi /etc/my.cnf

binlog_format = ROW 

추가하고 저장한다.

이미 set global로 설정한 부분이 있으니, 당장은 서버를 재시작 할 필요는 없겠다.

mysql서버를 운영하다 보면 로그파일이 너무 커져 있는 경우가 있다.

주로, general 로그와 slow 로그 일건데..

이 로그를 정리하기 위해서는 간단히

mysql>FLUSH LOGS;

를 이용하면 된다. flush logs는 현재 로그파일을 닫고 새로운 로그 파일을 생성해서 기록하게 해주는 명령어다.

다만, flush logs 했을때 기존 로그 파일들은 수정하고 새로 생성할 수 있는 권한이 있어야 하는데,

로그 기록을 하고 있는 디렉토리에 mysql 계정에 해당 권한이 없으면 정상적으로 동작되지 않는다.

로그 기록되고 있는 위치를 확인하고, mysql 계정이 파일을 수정하고 새로 만들수 있는 권한이 있는지 확인해보기 바란다.

이제, 위와 같이 flush logs로만 로그 파일을 새로 변경하지 못할때 수동으로 변경하는 방법을 해보자.

간단하다.

#1. 로그 기록 설정을 중지하고.

#general log

mysql>SET GLOBAL general_log = 'OFF';

#slow log
mysql>SET GLOBAL slow_query_log = 'OFF';

#2. 기존 로그파일을 백업 또는 삭제한다.
[root@]# mv mysql-slow.log mysql-slow.log.old
[root@]# mv mysqld.log mysqld.log.old

#3. 새로운 로그 파일을 만들고 권한을 부여한다

[root@]# touch mysql-slow.log

[root@]# chown mysql:mysql mysql-slow.log

[root@]# touch mysqld.log

[root@]# chown mysql:mysql mysqld.log

#4. flush logs를 해서 기존 로그 파일을 닫고 새로운 파일에 로그를 기록할 수 있도록 해준다.
mysql>FLUSH LOGS;

#5. 로그기록 설정을 다시 ON으로 변경한다.

mysql>SET GLOBAL general_log = 'ON';
mysql>SET GLOBAL slow_query_log = 'ON';

#6. 로그 기록 상태를 확인해 본다.

웹에서 nodejs 소켓통신시 보안 관련 인증서 이슈가 있다.
클라이언트에서 node서버로 통신에는 문제 없겠으나,
node서버 내에서 통신시 ssl을 적용하지 않으면 문제가 되는 이슈가 있는데,
이를 해결 하기 위해서 node 서버측 스크립트(server.js)에 직접 ssl인증서 정보를 추가하는 방법이 있는데
이는 보안에 취약하다.

그래서, 가상호스트에 Reverse Proxy를 적용해
클라이언트와 서버간 데이타 전송은 ssl로 하고, node서버에서 내부 통신을 통해서 데이타 전송을 하면 보안 이슈가 해결 된다.

아래 클라이언트, 서버 관련 기본 소스와 가상호스트 내용 추가한다.

* 클라이언트 페이지
<script src="socket.io.js"></script>
<script>
var socket = io.connect('https://yourdomain.com', {
requestCert: true,
secure: true,
rejectUnauthorized: false,
transports: ['websocket']  //통신 방법
});
var socketid;
socket.on('connect', function(){
socketid = socket.id;
});
</script>

* node 서버측 스크립트
const os = require('os');
const nodeStatic = require('node-static');
const socketIO = require('socket.io');
const http = require('http');

// 💡 CORS 설정: 클라이언트가 접속하는 도메인으로 변경해야 합니다.
const ALLOWED_ORIGIN = "http://abc.com";

const options = {};

// 모든 네트워크 인터페이스(0.0.0.0)의 3000 포트에서 요청 수신
// Node.js 서버는 HTTP로만 응답하며, SSL 인증서는 Apache가 처리합니다.
var server = http.createServer(options, (req, res) => {
    // '/socket.io/' 경로가 아니거나, 파일이 존재하지 않는 경우 등 필요한 경우에만 정적 파일을 제공
    // Socket.IO는 '/socket.io/' 경로를 내부적으로 처리합니다.
}).listen(3000, '127.0.0.1', () => { // 'localhost' 대신 '0.0.0.0' 사용
    console.log('✅ Socket.IO server started and listening on 127.0.0.1:3000...');
});
// Socket.IO 서버 초기화 및 CORS 옵션 적용
var io = socketIO.listen(server, {
    cors: {
        // 💡 중요: 클라이언트 웹페이지가 로드되는 도메인을 정확히 지정합니다.
        origin: ALLOWED_ORIGIN, 
        methods: ["GET", "POST"],
        credentials: true
    }
});

io.sockets.on('connection', function(socket) { 
    function log() {
        var array = ['[Server Log]'];
        array.push.apply(array, arguments);
        socket.emit('log', array);
    }

    // 클라이언트 연결 이벤트 (Apache 리버스 프록시를 통과한 후)
    log('Client connected. Socket ID:', socket.id);
    
    // 리버스 프록시를 통해 전달된 클라이언트 정보 확인
    // Apache Vhost 설정에서 'X-Real-IP' 헤더를 전달했으므로, 이 정보를 확인할 수 있습니다.
    const realIp = socket.request.headers['x-real-ip'] || socket.request.connection.remoteAddress;
    log(`Client IP (via Proxy): ${realIp}`);

    // 클라이언트가 보낸 연결 확인 이벤트 수신
    socket.on('client_connected', function(data) {
        log(`Client ID confirmation received: ${data.id}`);
        // 여기에 추가적인 인증 또는 초기화 로직을 넣을 수 있습니다.
    });
    
    // 기타 소켓 이벤트 리스너 추가...

});


* 서버의 가상호스트
<VirtualHost *:80>
    ServerName yourdomain.com

    # Rewrite 모듈을 사용하여 HTTPS로 리다이렉트
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.com

    LogLevel        warn
    SSLEngine on
    SSLProtocol -ALL +TLSv1.2
    SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
    SSLCertificateFile      /etc/letsencrypt/live/yourdomain.com/cert.pem
    SSLCertificateKeyFile   /etc/letsencrypt/live/yourdomain.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/yourdomain.com/chain.pem

    CustomLog "logs/yourdomain.com-ssl_access_log" combined

#   ProxyRequests Off  # 리버스 프록시 모드로 설정
    ProxyPreserveHost On
    ProxyTimeout 600

    RequestHeader set X-Forwarded-Proto "https"

    # Socket.IO 프록시 설정
    ProxyPass /socket.io/ ws://127.0.0.1:3000/socket.io/
    ProxyPassReverse /socket.io/ ws://127.0.0.1:3000/socket.io/

    # 일반 HTTP(s) 프록시 설정
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

mysql에서 실행되는 쿼리들중 오래 걸리는 쿼리를 확인하기 위해서 slow query 를 설정한다.

방법은

1. my.cnf 에 아래와 같이 입력하고, mysql을 재시작 해주거나

slow_query_log_file = /var/log/mysql-slow.log

long_query_time = 3

slow_query_log = 1

2. mysql 콘솔에서 set global 을 이용해 바로 변경하는 방법이다. 이때 set global은 서버가 재시작 되면 초기화 된다는점을 유념해야 한다.

mysql> set global long_query_time = 1;// 초단위 입력

mysql> set global slow_query_log = 'ON';// ON , OFF

이렇게 하면 느린 쿼리를 확인 할 수 있다.

그런데, 이렇게 했음에도 slow query에 설정된 값보다 작은 시간들의 쿼리 로그가 기록된다면,

예로 long_query_time = 1; 로 1초 이상 쿼리를 로그 기록 하도록 설정 했음에도 1초 미만의 쿼리들이 기록이 된다면, 

설정에서 아래 내용들을 확인해 봐야 한다.

long_query_time이 1초로 설정되어 있는데도 1초 미만의 쿼리가 로그에 기록된다면, 다음을 확인해야 합니다.

• min_examined_row_limit 값: 이 값이 0으로 설정되어 있다면, 실행 시간이 짧더라도 모든 쿼리가 기록될 수 있습니다. 이 값을 적절한 값(예: 1000)으로 변경해야 합니다.
• log_queries_not_using_indexes: 이 설정이 ON으로 되어 있다면, long_query_time에 관계없이 인덱스를 사용하지 않는 쿼리는 모두 로그에 기록됩니다. 이 설정을 OFF로 변경하면 이로 인한 로그 기록을 막을 수 있습니다.

slow query 기록에 영향을 주는 설정값으로는

1. long_query_time : 쿼리 실행 시간

2. min_examined_row_limit : 쿼리 실행시 검사한 쿼리 행의 최소 수

3. og_queries_no_using_indexes  :   : 인덱스를 사용하지 않는 쿼리를 식별하는 설정값으로 'ON/OFF'

여기서 신경 써야 할 것(간과 하는 것)이 

log_queries_no_using_indexes 인데, 이 설정이 'ON'  되어 있을 경우 long_query_time 과 무관히게 로그에 기록한다.

min_examined_row_limit 는 검사한 쿼리의 행 수를 제한 하는 설정으로 0이면 검색한 행의 값이 0개 이더라도, query time 이 1초를 넘으면 기록하게 되어 로그파일 사이즈 증간, 파일 I/O 부하등을 유발 할 수 있어 적당한 값을 설정하는 것을 권고 한다고 한다.

Rocky8 에서 기본 저장소에는 mod_evasive 가 없는거 같다.

그래서, 여기저기 찾아보니 raven 저장소를 설치하면 된다고 한다.

- raven 저장소 설치
#dnf install https://pkgs.sysadmins.ws/el8/base/x86_64/raven-release-1.0-1.el8.noarch.rpm -y

- 확인
#yum repolist
raven                                                                                             Raven's RPM repo for el8-x86_64 - base
raven이 보이면 된다

- raven 저장소에서 mod_evasive 설치하기
#dnf --enablerepo=raven-extra install mod_evasive

- 설치확인
#ls /usr/lib64/httpd/modules/ | grep evasive
mod_evasive 


- 설치가 잘 되었으니, 이제 설정을 해주면 된다.
#vi /etc/httpd/conf.d/mod_evasive.conf

DOSPageCount 5 #동일페이지 요청횟수, DOSPageInterval 에 설정된 초동안 동일 아이피에서 호출할 수 있는 수
DOSSiteCount        50 #기본값
DOSPageInterval     1 #기본값
DOSSiteInterval     1 #기본값
DOSBlockingPeriod   10 #기본값
DOSLogDir   "/var/log/mod_evasive" #로그를 기록하는 디렉토리, 디렉토기 권한 apache에서 쓰기 가능하게 chown apache 권한 준다.
DOSWhitelist    127.0.0.1 192.168.0.* #이 부분도 중요하다. 이 IP들은 ddos 공격형태가 되더라도 접속 허용해주는 설정이다.

이 부분만 수정해 줬다. 
다른 부분은 운영하는 사이트에 맞게 조절해주면 된다.
다만, 너무 값을 낮게 설정하게 되면, 정상적인 트래픽도 차단이 될 수 있으니,
적정한 수를 확인하면서 적용해 주도록 한다.

모두 적용을 했으면, 
#systemctl restart httpd

적용이 잘 되고 있다면,  차단이 되었을때 httpd status에서도 볼 수 있다.
#systemctl status httpd
~~~
~~~
7월 10 14:41:18 svr133 mod_evasive[3269551]: Blacklisting address 112.223.109.114: possible DoS attack.
7월 10 14:43:32 svr133 mod_evasive[3269549]: Blacklisting address 39.119.233.194: possible DoS attack.
7월 10 14:50:42 svr133 mod_evasive[3269551]: Blacklisting address 210.124.191.225: possible DoS attack.
7월 10 14:51:07 svr133 mod_evasive[3269550]: Blacklisting address 221.150.189.139: possible DoS attack.




mod_evasive를 운영하다가 중지를 시키려면,

1. 설정값들을 크게 설정해 주거나, 비활성화(주석)
ㄴex) DOSPageCount 10000 또는 DOSBlockingPeriod 0 으로 해서 설정을 거의 무효화 하는 방식
ㄴex) mod_evasive.conf 에서 <IfModule mod_evasive20.c>~</IfModule> 블럭 전체를 주석처리하는 방식
2. 모듈을 삭제하거나
ㄴdnf remove mod_evasive -y
3. mod_evasive.conf 파일명을 변경 해줘도 된다.
ㄴmv mod_evasive.conf mod_evasive.conf.bak
4. mod_evasive 모듈 로드 되지 않게 하기
ㄴmod_evasive.conf 에서 주석처리해 준다. 
ㄴ#LoadModule evasive20_module modules/mod_evasive.so

편하게 할 수 있는 방법으로 하면된다.
나라면, 파일명 바꾸는 식으로 하겠다.

변경을 했으면,

#systemctl restart httpd

centos 6버젼에서 사용 가능한 저장소 정보

우선, 기존 저장소를 백업하고 내용을 변경한다.

# mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/backup/

# vi /etc/yum.repos.d/CentOS-Base.repo

--------------------------------------------------------------------------------------------------------------------------------------------------

#yum clean all

#yum makecache

#yum update -y

위 내용으로 변경 후 yum 업데이트는 정상으로 수행 되었다.

현재(2025년 7월 08일) 사용이 가능한 것으로 확인되었다.

centos7에서 letsencrypt 설치하기
- 일반적으로 certbot 클라이언트를 사용하면 된다. 따라서 certbot 패키지를 설치한다.

1. epel 저장소 활성화 하고.
#yum install epel-release -y

2. certbot설치한다.
#yum install certbot python2-certbot-apache -y

별 문제 없다면 간단히 설치가 가능하다.
이후, 인증서를 생성해서 이용하면된다.


주로 사용하는 명령은,
certbot certonly :: 신규 생성할때
certbot renew :: 갱신할때.
ㄴ실행시 인증과 관련된 문제가 있을때 "--no-verify" 명령 옵션을 넣주고 실행한다.
ㄴ갱신 테스트 해볼때는 "--dry-run" 옵션을 추가해서 실행한다.
cerbot certificates :: 설치된 인증서 확인할때.

centos7에서 zabbix agent 설치하기

#yum search zabbix*
있으면 설치하고 없으면, zabbix 저장소를 추가해준다.

#rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/7/x86_64/zabbix-release-6.0-1.el7.noarch.rpm
추가 완료 한 후

#yum install zabbix-agent -y
설치 완료 후, 설정하기

#vi /etc/zabbix_agentd.conf
-- Server=자빅스서버아이피(192.168.0.1)
-- ServerActive=자빅스서버아이피(192.168.0.1)
-- Hostname=자빅스클라이언트아이피(192.168.0.100)
Server=192.168.0.1
ServerActive=192.168.0.1
Hostname=192.168.0.100

변경 완료 후, agent 시작
#systemctl start zabbix-agent

서버 재시작할때 자동으로 실행하도록 저장
#systemctl enable zabbix-agent

자빅스 서버서 클라이언트 추가해주고, 모니터링 한다.

무료 인증서 letsencrypt 관리 프로그램 certbot 설치하기

letsencrypt 를 설치(dnf install letsencrypt) 후 

기존 사용하던 인증서를 복사해서

renew(certbot renew) 를 해 봤을때, 

실패가 나면서 아래와 같은 오류 메세지가 있다면,

 "The requested apache plugin does not appear to be installed"

certbot 실행에 필요한 apache plugin이 없다는 것이다.

certbot 관련 plugin은 letsencrypt를 설치 후 확인해 보면,

[root@sv]# yum list installed | grep certbot
certbot.noarch                        1.11.0-2.el7                   @epel
python2-certbot.noarch                1.11.0-2.el7                   @epel

두가지만 나오는데,

갱신(renew)시 실패나면서 필요하다는 apache plugin은 없는 상태가.

certbot apache plugin은 찾아보면, python 관련되는 플러그인으로

위에 나온 python2-certbot 유형으로 찾으면 되는데. 

위 의 경우는

python2-certbot-apache 가 필요한 상태이다.

설치는

yum install -y python2-certbot-apache 

하면 된다.

이후 다시 확인해보면,

[root@sv]# yum list installed | grep certbot
certbot.noarch                        1.11.0-2.el7                   @epel
python2-certbot.noarch                1.11.0-2.el7                   @epel

python2-certbot-apache.noarch         1.11.0-1.el7                   @epel

추가된 항목이 보인다.

CentOS 7까지는 위와 같이 하면 될거고,

Rokey linux 에서는

설치된 버젼 확인후 apache plugin을 설치해 주면 된다.

apache plugin까지 설치하고 확인해보면, 아래와 같을 것이다.

[root@svr]# dnf list installed | grep certbot
certbot.noarch                              1.22.0-1.el8                                @epel
python3-certbot.noarch                      1.22.0-1.el8                                @epel
python3-certbot-apache.noarch               1.22.0-1.el8                                @epel

postfix 와 mailx 가 필요하다.

설치 되어 있지 않다면, 설치해 준다.

설치 확인

#dnf list installed | grep postfix

postfix.x86_64                              2:3.5.8-7.el8                               @baseos

# dnf list installed | grep mailx
mailx.x86_64                                12.5-29.el8                                 @baseos

검색 결과가 나오지 않았다면, 설치해 줘야 한다.

#dnf install -y postfix mailx

설치가 완료되면, 필요한 작업을 한다.

나의 경우,

서버 백업 쉘스크립트에서, 담당자에게 메일 보내는 작업에 사용중이다.

php-fpm 사용시

html, php 확장자 사용 관련 수정 사항

/etc/httpd/conf.d/php.conf
에서 

<IfModule  mod_php.c>
    <FilesMatch \.(php|html|phar)$>
        SetHandler application/x-httpd-php
    </FilesMatch>
</IfModule>

<IfModule !mod_php5.c>
  <IfModule !mod_php7.c>
    <IfModule !mod_php.c>
      # Enable http authorization headers
      SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1

      <FilesMatch \.(php|html|phar)$>
          SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"
      </FilesMatch>
    </IfModule>
  </IfModule>
</IfModule>


두 부분에 html 확장자 추가

추가로,
php-fpm 관련 www.conf 파일을 수정해 줘야 한다.

/etc/php-fpm.d/www.conf
#vi /etc/php-fpm.d/www.conf

해당 파일에서 내용중
## 주석해제 후 내용수정
#security.limit_extensions = .php .php3 .php4 .php5 .php7
주석 되어 있던 부분을 해제  하고 .html 을 추가해 준다.
security.limit_extensions = .php .php3 .php4 .php5 .php7 .html


위 부분과 관련한 에러 로그는 아래과 같이 보일 수 있으니 참고 하시라...

[Wed Apr 02 17:59:36.338751 2025] [proxy_fcgi:error] [pid 25475:tid 139693190534912] [client 127.0.0.1:57039] AH01071: Got error 'Access to the script '/home/aaa/404.html' has been denied (see security.limit_extensions)', referer: https://aaa/index.html 

Rokey linux 8에서 모니터링 zabbix-agent 설치하기

Rokey linux 8에서 zabbix는

dnf install 이나, yum install 로 바로 설치 되지 않는다.

레포지토리 관련한 이슈가 있다고 한다.

(자세한건 잘 모름)

그래서, 우선 레포지토리 관련되는 rpm 먼전 설치하고 진행해야 한다.

아래 진행 순서 기록해 둔다.

[root@svr ~]# rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-4.el8.noarch.rpm
https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-4.el8.noarch.rpm(을)를 복구합니다
경고: /var/tmp/rpm-tmp.CMnyz3: Header V4 RSA/SHA512 Signature, key ID a14fe591: NOKEY
Verifying...                          ################################# [100%]
준비 중...                         ################################# [100%]
Updating / installing...
   1:zabbix-release-6.0-4.el8         ################################# [100%]


[root@svr ~]# dnf install -y zabbix-agent
Zabbix Official Repository -x86_64  302 kB/s | 573 kB     00:01

Zabbix Official Repository (non-supported) - x86_64         1.2 kB/s | 1.4 kB     00:01
Zabbix Official Repository (Agent2 Plugins) -x86_64        1.4 kB/s | 1.7 kB     00:01
종속성이 해결되었습니다.
==================================================================================

꾸러미                     구조                           버전                                 저장소                        크기==================================================================================
설치 중:
 zabbix-agent       x86_64                 6.0.39-release1.el8              zabbix                           585 k

연결 요약
=======================================================================================
설치  1 꾸러미

전체 내려받기 크기: 585 k
설치된 크기 : 2.2 M
꾸러미 내려받기 중:
zabbix-agent-6.0.39-release1.el8.x86_64.rpm                                                       452 kB/s | 585 kB     00:01
-----------------------------------------------------------------------------------------------------------------------------------------------------------------합계                                                                                                                                                                                                                                           451 kB/s | 585 kB     00:01
Zabbix Official Repository - x86_64                                                      1.6 MB/s | 1.7 kB     00:00
GPG키 0xA14FE591 가져오는 중:
사용자 ID : "Zabbix LLC <packager@zabbix.com>"
지문: A184 8F53 52D0 22B9 471D 83D0 082A B56B A14F E591
출처 : /etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-A14FE591
키 가져오기에 성공했습니다
연결 확인 실행 중
연결 확인에 성공했습니다.
연결 시험 실행 중
연결 시험에 성공했습니다.
연결 실행 중
  준비 중     :                                                                                                                                                 1/1
  구현 중     : zabbix-agent-6.0.39-release1.el8.x86_64                                                                               1/1
  설치 중     : zabbix-agent-6.0.39-release1.el8.x86_64                                                                               1/1
  구현 중     : zabbix-agent-6.0.39-release1.el8.x86_64                                                                               1/1
  확인 중     : zabbix-agent-6.0.39-release1.el8.x86_64                                                                               1/1

설치되었습니다:
  zabbix-agent-6.0.39-release1.el8.x86_64

완료되었습니다!


* 설정 파일 수정하기
vi /etc/zabbix/zabbix_agentd.conf

변경할 부분은 
zabbix server IP가 192.168.0.1 이고, 
모니터링 대상 zabbix agent 서버 ip가 192.168.0.2 이라고 할때

Server=192.168.0.1
StartAgents=1
ServerActive=192.168.0.1
Hostname=192.168.0.2

이 정도만 변경 셋팅하면 된다.
이후, 
#systemctl start zabbix-agent
#systemctl enable zabbix-agent

zabbix 설정 끝.

Rokey linux 8 이상 사용시 
이전 centos 7버젼까지 사용하던 
hosts.deny, hosts.allow가 보안상 사용 제외 되었다고 한다.

대신, firewalld 와 iptables를 사용해야 한다는데...
이러면, 개별 서버별로 포트관리나, ip별 접근 제어를 해야 해서 복잡하게 되었다.

업그레이드 해서 좋았는데..
이런 어려움이 있네. 공부해야 하겠다.

어려운 부분은 서버 관리업체에 맏기고,
이전에 하던거 처럼 ssh에 대한 접근 제어만 해보도록 하자.

firewalld, iptables 사용 없이
ssh의 설정을 통해서 한다.

/etc/ssh/sshd_config 파일에서
AllowUsers, DenyUsers, AllowHosts, DenyHosts 를 이용해
적절히 설정하면 된다고 한다.

계정과 ip를 이용해 접근 제어 하려면,
- 허용하는 user
AllowUsers root@192.168.0.1 *@192.168.0.1
- 제외하는 user
DenyUsers root@192.168.0.2

이런 방식으로 하면 되고, 여러개일 경우 콤마나 공백을 띄워서 작성해주면 된다.

IP로 접근 제어를 할때는 
- 허용할때
AllowHosts 192.168.0.0/24 172.16.0.1
- 제외할때
DenyHosts 192.168.0.0/24 172.16.0.1

--> 이 설정 기능은 ssh 최신 버젼에서는 없어졌다고 합니다. AllowUsers, DenyUsers로 이용해야 한다고 합니다.

이렇게 입력하고, 저장 후 sshd를 재시작 해주면 된다.
systemctl sshd restart


centos 7까지의 설정에서는 hosts.deny, hosts.allow 에서 
개별 데몬별로도 설정이 가능했지만, 
현재 rokey linux 8 이상에서는 보안상 이전 방식이 사용되지 않고,
조금 번거롭지만, 개별 서비스별로 설정을 해야 할 거 같다.