서버 방화벽 강화

기술자가 아닌 개발자가 되자·2023년 10월 18일
linux프로젝트
0
1:S 19 Sep 2023 01:07:32.861 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:32.861 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:32.862 * REPLICAOF 120.77.210.109:60125 enabled (user request from 'id=1957 addr=47.94.158.5:48330 laddr=192.168.48.2:6379 fd=11 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=30 qbuf-free=20444 argv-mem=26 multi-mem=0 rbs=1024 rbp=155 obl=0 oll=0 omem=0 tot-mem=22322 events=r cmd=slaveof user=default redir=-1 resp=2')
1:S 19 Sep 2023 01:07:33.118 # Error condition on socket for SYNC: Connection refused
1:S 19 Sep 2023 01:07:33.649 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:33.649 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:33.903 # Error condition on socket for SYNC: Connection refused
1:S 19 Sep 2023 01:07:34.653 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:34.654 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:34.907 # Error condition on socket for SYNC: Connection refused
1:S 19 Sep 2023 01:07:35.692 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:35.692 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:35.950 # Error condition on socket for SYNC: Connection refused
1:S 19 Sep 2023 01:07:36.697 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:36.697 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:36.955 # Error condition on socket for SYNC: Connection refused
1:S 19 Sep 2023 01:07:37.701 * Connecting to MASTER 120.77.210.109:60125
1:S 19 Sep 2023 01:07:37.701 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:07:37.957 # Error condition on socket for SYNC: Connection refused
1:M 19 Sep 2023 01:07:38.380 * Discarding previously cached master state.
1:M 19 Sep 2023 01:07:38.380 # Setting secondary replication ID to aa05b88d98c151625d9b0d867942fb14cacb11fe, valid up to offset: 1. New replication ID is 32dd01fdf5b93659fb06cf191fb3f261c4642aa4
1:M 19 Sep 2023 01:07:38.380 * MASTER MODE enabled (user request from 'id=1957 addr=47.94.158.5:48330 laddr=192.168.48.2:6379 fd=11 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=16 qbuf-free=20458 argv-mem=12 multi-mem=0 rbs=1024 rbp=223 obl=0 oll=0 omem=0 tot-mem=22308 events=r cmd=slaveof user=default redir=-1 resp=2')
1:S 19 Sep 2023 01:08:47.474 * Before turning into a replica, using my own master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
1:S 19 Sep 2023 01:08:47.474 * Connecting to MASTER 81.71.101.5:60131
1:S 19 Sep 2023 01:08:47.474 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:08:47.474 * REPLICAOF 81.71.101.5:60131 enabled (user request from 'id=1959 addr=47.94.158.5:49368 laddr=192.168.48.2:6379 fd=11 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=27 qbuf-free=20447 argv-mem=23 multi-mem=0 rbs=1024 rbp=155 obl=0 oll=0 omem=0 tot-mem=22319 events=r cmd=slaveof user=default redir=-1 resp=2')
1:M 19 Sep 2023 01:08:52.949 * Discarding previously cached master state.
1:M 19 Sep 2023 01:08:52.949 # Setting secondary replication ID to 32dd01fdf5b93659fb06cf191fb3f261c4642aa4, valid up to offset: 1. New replication ID is 752fb8b6bfc7d7b1d1d1af7da1af3cbcfe9d27ac
1:M 19 Sep 2023 01:08:52.949 * MASTER MODE enabled (user request from 'id=1959 addr=47.94.158.5:49368 laddr=192.168.48.2:6379 fd=11 name= age=8 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=16 qbuf-free=20458 argv-mem=12 multi-mem=0 rbs=1024 rbp=223 obl=0 oll=0 omem=0 tot-mem=22308 events=r cmd=slaveof user=default redir=-1 resp=2')
1:S 19 Sep 2023 01:09:58.618 * Before turning into a replica, using my own master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
1:S 19 Sep 2023 01:09:58.618 * Connecting to MASTER 153.0.195.243:60112
1:S 19 Sep 2023 01:09:58.619 * MASTER <-> REPLICA sync started
1:S 19 Sep 2023 01:09:58.619 * REPLICAOF 153.0.195.243:60112 enabled (user request from 'id=1961 addr=47.94.158.5:49616 laddr=192.168.48.2:6379 fd=11 name= age=3 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=29 qbuf-free=20445 argv-mem=25 multi-mem=0 rbs=1024 rbp=155 obl=0 oll=0 omem=0 tot-mem=22321 events=r cmd=slaveof user=default redir=-1 resp=2')
1:M 19 Sep 2023 01:10:04.636 * Discarding previously cached master state.
1:M 19 Sep 2023 01:10:04.637 # Setting secondary replication ID to 752fb8b6bfc7d7b1d1d1af7da1af3cbcfe9d27ac, valid up to offset: 1. New replication ID is 1131302c988fe147944ce744bc766a75f448332f
1:M 19 Sep 2023 01:10:04.637 * MASTER MODE enabled (user request from 'id=1961 addr=47.94.158.5:49616 laddr=192.168.48.2:6379 fd=11 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 ssub=0 multi=-1 qbuf=16 qbuf-free=20458 argv-mem=12 multi-mem=0 rbs=1024 rbp=223 obl=0 oll=0 omem=0 tot-mem=22308 events=r cmd=slaveof user=default redir=-1 resp=2')
1:M 19 Sep 2023 02:07:31.082 * 1 changes in 3600 seconds. Saving...
1:M 19 Sep 2023 02:07:31.083 * Background saving started by pid 152
152:C 19 Sep 2023 02:07:31.087 * DB saved on disk
152:C 19 Sep 2023 02:07:31.088 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
1:M 19 Sep 2023 02:07:31.184 * Background saving terminated with success

저번에 방화벽을 닫고 docker-container로 각 프로세스들을 연결해주었는데도, 외부 ip에서 침입이 계속 일어났다.

ufw allow ~~

처음에 이렇게만 방화벽 허용을 제어해 주었다.


Vultr Firewall

우리는 vultr 의 cloud 서비스를 사용하는데, vultr는 vultr의 방화벽과 os 방화벽 이 두개 이중 방화벽이 존재한다. 따라서 os 방화벽만 허용하면 SSH 트래픽만 차단되고 HTTP트래픽은 허용되어버린다.
때문에 HTTP 트래픽이 허용되어 접근한 것으로 보인다.
따라서 두개를 적절히 조정해주어야 한다. 먼저 vultr 방화벽은 따로 설정해주었다.


iptables -t filter -F
iptables -t filter -X

먼저 방화벽 필터 테이블에서 모든 규칙을 삭제한다.


iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

입력 (INPUT), 전달 (FORWARD), 및 출력 (OUTPUT) 트래픽에 대한 기본 정책을 설정하는데 모두 DROP 으로 설정하여서 모든 입력(시스템에 들어오는 모든 연결 및 패킷), 전달 (시스템이 패킷을 다른 네트워크 디바이스로 전달하는 경우), 출력(시스템에서 나가는 모든 연결 및 패킷)을 차단시킨다.


iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

하지만 동일 네트워크 안에서 프로세스들 끼리 소통은 가능해야 하므로, 루프백(Loopback) 인터페이스를 통해 로컬 시스템에서 발생하는 트래픽
은 허용해준다.


iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

포트 22로 들어오는 (SSH 트래픽) 트래픽을 승인하도록 설정한다. 따라서 이 규칙을 통해 SSH 서비스에 대한 연결을 허용한다다.시스템에서 TCP 프로토콜을 사용하여 포트 22로 나가는 (SSH 클라이언트가 SSH 서버에 연결하는) 트래픽도 승인한다.


iptables -t filter -A INPUT -i docker0 -j ACCEPT
iptables -t filter -A OUTPUT -o docker0 -j ACCEPT

내 서버의 모든 서비스는 도커 컨테이너화 되어있으므로 도커에 대한 입출력도 가능하게 해주어야 한다.

이 규칙은 docker 인터페이스로 들어오거나 나가는 트래픽을 승인하도록 설정합니다.

iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

그리고 Http와 Https에 대한 통신도 가능하게 해주고


iptables -t filter -A INPUT -p tcp --dport 3000 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 3000 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 4000 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 4000 -j ACCEPT
.
.
.

그 외의 허용할 port에 대해서도 적용해준다. 


#!/bin/sh

# reset :
iptables -t filter -F
iptables -t filter -X

# Block all :
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

# Localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Authorize already established connections :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Authorize backloop :
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

# Authorize ssh :
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

iptables -t filter -A INPUT -i docker0 -j ACCEPT
iptables -t filter -A OUTPUT -o docker0 -j ACCEPT

iptables -t filter -A INPUT -i br-191de775dcfd -j ACCEPT
iptables -t filter -A OUTPUT -o br-191de775dcfd -j ACCEPT
iptables -t filter -A INPUT -i br-23f7161234e1 -j ACCEPT
iptables -t filter -A OUTPUT -o br-23f7161234e1 -j ACCEPT
iptables -t filter -A INPUT -i br-575a61498a80 -j ACCEPT
iptables -t filter -A OUTPUT -o br-575a61498a80 -j ACCEPT
iptables -t filter -A INPUT -i br-6a8503766537 -j ACCEPT
iptables -t filter -A OUTPUT -o br-6a8503766537 -j ACCEPT
iptables -t filter -A INPUT -i br-977a4c08f70f -j ACCEPT
iptables -t filter -A OUTPUT -o br-977a4c08f70f -j ACCEPT
iptables -t filter -A INPUT -i br-af3792b88199 -j ACCEPT
iptables -t filter -A OUTPUT -o br-af3792b88199 -j ACCEPT
iptables -t filter -A INPUT -i br-cc566434d5d5 -j ACCEPT
iptables -t filter -A OUTPUT -o br-cc566434d5d5 -j ACCEPT

# Authorize HTTP :
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT

# Authorize HTTPS :
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 4000 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 4000 -j ACCEPT
.
.
.

이렇게 이 모든 명령어 들을 파일로 저장한 다음, 서버가 재시작 될때마다 실행되도록 해주었다.이렇게 방화벽 설정을 강화했는데, 이래도 redis에 공격이 들어오는지 계속 확인해봐야겠다.

profile
기술자가 아닌 개발자가 되자
https://www.youtube.com/watch?v=__9qLP846JE
이전 포스트

nest.js와 mysql연동하기

다음 포스트

nestjs의 Error customizing하기

0개의 댓글

관련 채용 정보