원본 저장소 데이터 들고 있는거고 pub/sub 메시지 전달자 역할이기 때문에 보안은 중요하다
커넥션 제어
커넥션을 제어하는 3가지 방법
bind
10.0.0.2, 127.0.01만 레디스 접근 가능
bind: 서버는 여러 개의 네트워크 인터페이스를 가질 수 있다.여러 IP 중 어떤 IP만 레디스 접근 가능하게할건지 지정한다.
0.0.0.0 혹은 * 로 설정하면 모든 연결 허용
특정 값 설정하는 것 권장
패스워드
이전 버전
각 인스턴스에 하나의 패스워드만 설정 가능 (requirepass)
# 비번 설정 or redis.conf
CONFIG SET requirepass password
-a (auth)로 redis-cli 접속
redis-cli -a password
혹은
redis-cli AUTH password
<br>
### 6버전 이후
- ACL(Access Control List) 로 PW 설정 권장
- 유저 생성, 유저별로 다른 pw 설정, 권한 부여 가능
<br>
<br>
## Protected mode
`yes` (기본값)면 pw 설정 안 했을 때 로컬(127.0.0.1) 접속만 허용한다.
- `bind`로 다른 IP 지정해도 마찬가지
`no` 면 pw 없이 접근 가능하므로 운영 모드에서 `yes` 설정 권장
<br>
# 커맨드 제어
- `CONFIG SET`으로 중요 설정값 변경 가능하기 때문에 제어는 중요
- 커맨드 제어 방법 2가지
<br>
## 커맨드 이름 변경
- `rename-command`로 특정 커맨드를 다른 이름으로 변경하거나 못 쓰게 비활성화할 수 있다.
- redis.conf에서만 변경 가능, 동적 변경 불가, `CONFIG GET`으로 확인 불가, `CONFIG SET` 세팅 불가
<br>
_redis.conf_
```java
rename-command CONFIG CONFIG_NEW
CONFIG 커맨드를 CONFIG_NEW로 변경
redis.conf
rename-command CONFIG ""
CONFIG 커맨드를 사용 불가
센티널 사용중이라면
센티널에서 레디스로 REPLICAOF, CONFIG 커맨드 직접 날려 레디스 제어하기 때문에 sentinel.conf에서도 똑같이 rename 해줘야함
enable-protected-configs no
enable-debug-command no
enable-module-command no
no면 모든 연결 수행 차단, yes면 모든 연결 수행 허용, local이면 로컬에서만 수행 허용
enable-protected-configs : CONFIG로 기본 경로 dir, 백업 파일 dbfile 등 옵션 변경하기 차단
enable-debug-command : DEBUG 커맨드 차단
DEBUG SEGFAULT: Redis 프로세스를 즉시 충돌(Crash)시키고 종료합니다. (테스트용)
DEBUG RELOAD: RDB 파일을 저장하고 다시 로드합니다. (데이터가 클 경우 서비스 지연 발생)
DEBUG SLEEP <seconds>: 지정된 시간 동안 Redis 서버를 완전히 멈춥니다(Hang). 모든 클라이언트의 요청이 차단됩니다.
DEBUG OBJECT <key>: 특정 키가 메모리 어디에 어떻게 저장되어 있는지 상세 내부 정보를 보여줍니다.
레디스 다운 가능
enable-module-command : MODULE 커맨드 차단
MODULE LOAD <path>: 서버가 실행 중인 상태에서 새로운 모듈(.so 파일)을 동적으로 로드합니다.
MODULE LIST: 현재 로드된 모듈 목록을 확인합니다.
MODULE UNLOAD: 로드된 모듈을 제거합니다.
악성 코드 모듈 업로드 가능
레디스 해킹 사례
서버 A 레디스는 protected-mode no라 pw 없이 접근 가능 / 서버 B에서 A를 해킹하는게 목표
▶️ 서버B에서 SSH 키 생성 후 레디스 통해 A에 키 저장 후 접근 가능하게 함
서버 B에서 키 생성: ssh-keygen -t rsa > key.txt
B에서 A 접근해
flushall로 레디스 전체 삭제 후 key.txt 내용을 레디스 키의 데이터로 넣기
데이터 저장 경로, 파일명 변경 CONFIG SET dir /home/centos/.ssh / CONFIG SET dbfilename authorized_keys
SAVE 로 데이터 백업 파일 저장
→ B 의 공개키가 저장되어 SSH로 B가 A에게 접근 가능하게 됨
SSH → 접근하려는 쪽이 키 생성해서 보내는 구조 (공개키는 보내고 비밀키는 자기가 갖고)
SSH 원리는 공개키 암호화(Public Key Cryptography) 방식을 사용하며, 절차를 제대로 밟았다면 비밀번호 없이 접속이 가능해집니다.
1. 공개키 암호화 원리 (자물쇠와 열쇠)
SSH 키 쌍을 생성하면 두 개의 파일이 만들어집니다.
비밀키 (Private Key): 나(A 서버)만 가지고 있는 '열쇠'입니다. 절대 남에게 주면 안 됩니다.
공개키 (Public Key): 누구에게나 줘도 되는 '자물쇠'입니다. 이 파일을 B 서버에 보내는 것입니다.
2. 접속 가능하게 만드는 법 (핵심 절차) A → B로 접근하는 상황
A 서버에서 생성한 공개키 파일을 B 서버의 특정 위치에 저장해야 합니다. 단순히 전송만 한다고 끝나는 게 아니라, B 서버의 약속된 장소에 등록해야 합니다.
A 서버: ssh-keygen으로 키 생성 (id_rsa, id_rsa.pub).
전송: id_rsa.pub(공개키) 파일을 B 서버로 보냅니다.
B 서버 등록: 받은 공개키 내용을 B 서버 사용자의 ~/.ssh/authorized_keys 파일 안에 한 줄로 추가(append)합니다.
꿀팁: ssh-copy-id 유저명@B서버IP 명령어를 쓰면 이 복잡한 과정을 한 방에 자동으로 처리해 줍니다.
3. 왜 비번 없이 접속될까? (인증 과정)
A가 B에 접속을 시도하면 다음과 같은 대화가 오갑니다.
B 서버: "오, 내 authorized_keys에 자물쇠가 하나 있네? 이걸로 암호화한 문제를 낼 테니 풀어봐!"
