흙수저의 엔지니어링

동기화 하기 전 해당 Repository 폴더 내용 확인

동기화 할 폴더에서 팝업 메뉴 실행 → SVN Commit... Click

파일 동기화 하기 전 메시지 입력 (왜 동기화를 했는지 파악하기 위함)

동기화할 파일 선택 → OK Click

SVN 동기화 완료

(몇 번 더 테스트 하는 바람에 AT revision이 1이 아니라 3이네요)

SVN 서버의 Repository

동기화하는 폴더에 변경이 생기면 아래와 같이 폴더에 "!" 표시가 보입니다.

이때 "SVN Commit" 을 하시면 됩니다.

동기화 할 폴더에서 팝업 메뉴 실행 → SVN Checkout... Click

OK Click

Checkout Click

OK Click

원하는 곳에 동기화를 진행할 폴더 생성

해당 폴더에서 팝업 메뉴를 선택 → TortoiseSVN → Repo-browser 선택

생성한 Repository 입력

기존 생성했던 Repository  정보

https 이기 때문에 인증서 오류가 나옵니다.

→ Accept the certificate permanently 선택

ID / Password 입력

Repository Browser 로그인 성공 → OK Click

Create New Repository... Click

Regular FSFS repository Click

Repository 이름 입력

Empty repository Click

Customize permissions Click → Custom... Click

Add... Click

Create user... Click

User name: ID 입력

Password: 비밀번호 입력

Confirm password: 비밀번호 재입력

입력 후 OK Click

OK Click

Permissions(권한) 선택 → 확인 Click

Next > Click

Create Click

입력 정보 및 Repository URL 확인 → Finish Click

Repository 생성 완료

왼쪽 매뉴의 카테고리를 세분히 하면서 많이 늘어나니까, 화면이 부족하여 잘리더군요.

근데 왜 스크롤이 안되지????

그래서 찾아서 수정 했습니다.

티스토리 블로그 관리 → 스킨편집 → html 편집 → CSS 선택

이후 #sidebar를 검색하시면 아래와 같이 보입니다.

/*
 * sidebar
 */
#sidebar { position: fixed; top: 0; left: 0; bottom: 0; padding: 0; width: 300px; height: 100%; background-color: #fff; border-right: 1px solid #ddd; cursor: default;}

위의 화면이 보기 힘드시죠?? 그래서 아래와 같이 줄 바꿈을 하였습니다.

/*
 * sidebar
 */ 
#sidebar {
	position: fixed;
	top: 0;
	left: 0;
	bottom: 0;
	padding: 0;
	width: 300px;
	height: 100%;
	background-color: #fff;
	border-right: 1px solid #ddd;
	cursor: default; }

위의 코드에서 코드 한줄을 추가해주시면 됩니다.

/*
 * sidebar
 */ 
#sidebar {
	position: fixed;
	top: 0;
	left: 0;
	bottom: 0;
	padding: 0;
	width: 300px;
	height: 100%;
	background-color: #fff;
	border-right: 1px solid #ddd;
	cursor: default;
	overflow-y: auto; } #해당 줄만 추가하면 됩니다.

fortigate 6.X 와 7.X대 syslog가 변화가 있었네요.

7.X대 logstash 설정은 코드가 좀 더 업그레이드 되었습니다.

[root@tmplogsvr 192.168.x.x]# vi /etc/logstash/conf.d/logstash.conf

input {
        file {
                path => "/var/log/rsyslog/192.168.x.1/*.log"
                start_position => "beginning"
                tags => ["fortigate"]
        }
        file {
                path => "/var/log/rsyslog/192.168.x.2/*.log"
                start_position => "beginning"
                tags => ["fortigate"]
        }
}

filter {
        if "fortigate" in [tags] {
                grok {
                        patterns_dir => ["/etc/logstash/pattern.d"]
                        match => { "message" => [ "%{FORTILOG} %{GREEDYDATA:sub_message}" ] }
                        overwrite => [ "message" ]
                }
                kv {
                        value_split => "="
                }

                if "wan" in [srcintfrole] {
                        geoip {
                                source => "srcip"
                                target => "geoip_src"
                        }
                }

                if [sentbyte] != "" and [rcvdbyte] != "" {
                        bytes {
                                source => "rcvdbyte"
                                target => "rcvdbyte"
                        }
                        bytes {
                                source => "sentbyte"
                                target => "sentbyte"
                        }
                }
                mutate {
                        convert => {
                                "transport" => "integer"
                                "duration" => "integer"
                                "sentpkt" => "integer"
                                "rcvdpkt" => "integer"
                                "srcserver" => "integer"
                                "proto" => "integer"
                                "sessionid" => "integer"
                                "policyid" => "integer"
                                "crscore" => "integer"
                                "craction" => "integer"
                                "srcport" => "integer"
                                "dstport" => "integer"
                                "cpu" => "integer"
                                "mem" => "integer"
                                "totalsession" => "integer"
                                "disk" => "integer"
                                "setuprate" => "integer"
                                "disklograte" => "integer"
                                "fazlograte" => "integer"
                                "freediskstorage" => "integer"
                                "sysuptime" => "integer"
                        }
                }
        }
}

output {
        if "fortigate" in [tags] {
                elasticsearch {
                        hosts => "http://192.168.x.x:9200"
                        index => "logstash-fortigate-index-%{+YYYY.MM.dd}"
                        data_stream => "false"
                }
        }
}

[root@tmplogsvr pattern.d]# vi /etc/logstash/pattern.d/fortigate.pattern
FORTILOG (?<timestamp>^\w+\s+\d+\s+\d+\:\d+\:\d+)\s(?<log_send_dev>(?:%{IP}|\_gateway))

PUT _cluster/settings
{ "persistent": { "cluster.max_shards_per_node": "3000" } }

fortigate에서 syslog를 전달할 경우 아래와 같이 _gateway로 표시되는 경우가 있습니다.

특별한 문제는 없지만, 그래도 IP가 보기 좋은 것 같더군요.

예를 들어 어떤 IP가 syslog를 전달 해 주는 지 확인도 가능하고요.

Jun 15 11:01:13 _gateway date=2023-06-15 time=11:01:12 devname="xxxxxxxx" devid="FG200F########" eventtime=1686794472544187716 tz="+0900" logid="0000000020" type="traffic" subtype="forward" level="notice" vd="root" srcip=192.168.xxx.xx srcport=52170 srcintf="ha" srcintfrole="undefined" dstip=192.168.xxx.x dstport=5601 dstintf="dmz" dstintfrole="lan" srccountry="Reserved" dstcountry="Reserved" sessionid=144924 proto=6 action="accept" policyid=17 policytype="policy" poluuid="0aaaaaaa68-0aa8-51ee-06c7-4a2eb8b62f63" policyname="serial to dmz" service="tcp/5601" trandisp="noop" duration=121 sentbyte=2356 rcvdbyte=2492 sentpkt=11 rcvdpkt=8 appcat="unscanned" sentdelta=2356 rcvddelta=2492 dsthwvendor="MSI" dstosname="Linux" masterdstmac="ac:a0:ad:5a:9a:2a" dstmac="2c:f0:5a:5a:9a:2a" dstserver=0

syslog 설정을 UI로 하면 특별한 설정이 없는데, CLI로 확인할 경우 source-ip를 설정할 수 있습니다.

hostname # config log syslogd setting 

hostname (setting) # show
config log syslogd setting
    set status enable
    set server "192.168.xxx.xxx" #syslog server
    set source-ip "192.168.xxx.xxx" #syslog 전달할 ip
end

hostname (setting) #

이후 syslog를 확인하면 아래와 같이 _gateway가 아닌 IP로 표시되는 것을 확인할 수 있습니다.

(로그 서버와 같은 대역에서 설정을 하면 _gateway로 표시가 되네요~)

Jun 15 11:01:13 192.168.xxx.xxx date=2023-06-15 time=11:01:12 devname="xxxxxxxx" devid="FG200F########" eventtime=1686794472544187716 tz="+0900" logid="0000000020" type="traffic" subtype="forward" level="notice" vd="root" srcip=192.168.xxx.xx srcport=52170 srcintf="ha" srcintfrole="undefined" dstip=192.168.xxx.x dstport=5601 dstintf="dmz" dstintfrole="lan" srccountry="Reserved" dstcountry="Reserved" sessionid=144924 proto=6 action="accept" policyid=17 policytype="policy" poluuid="0aaaaaaa68-0aa8-51ee-06c7-4a2eb8b62f63" policyname="serial to dmz" service="tcp/5601" trandisp="noop" duration=121 sentbyte=2356 rcvdbyte=2492 sentpkt=11 rcvdpkt=8 appcat="unscanned" sentdelta=2356 rcvddelta=2492 dsthwvendor="MSI" dstosname="Linux" masterdstmac="ac:a0:ad:5a:9a:2a" dstmac="2c:f0:5a:5a:9a:2a" dstserver=0

굳이 뭐하러 UTM 2대를 내부 통신으로 연결할까요?

필요 없을 것 같지만, 실무에서는 기존 환경이 한번에 없어지면 안된다고 합니다.

하지만, 장비 도입은 업체간 계약으로 진행하는 것으로 시간을 질질 끌 수는 없습니다.

실무자 입장에서는 장비도 도입해야 하고, 기존 환경을 유지해야 하기 때문에 찾은 방법입니다.

신규 장비와 기존 장비를 연결하여 내부통신이 되도록 설정하고, 필요한 대역을 하나씩 옮기게 할 수 있습니다.

원래는 라우터와 라우터를 연결하는 기술인데, UTM은 Layer 7 애플리케이션 기반 정책을 수용하기 때문에 라우팅의 기능까지 포함하고 있습니다.

그래서 UTM이 라우터의 역할도 수행 가능합니다.

개인적으로 인원이 200여명 이하 수준인 회사에서는 라우터까지 필요 없다고 생각을 합니다.

(있다면 좋지만) 회사에서 라우터가 저렴하진 않기 때문에 라우터를 잘 사주지도 않습니다.

그래서 제가 선호하는 방식은 아래의 방식입니다.

문제점이 있다면, 장애 포인트가 단일 포인트라는 것입니다.

UTM에 문제가 발생하면 내부 전체가 먹통이 됩니다.

그리고 UTM이 라우터의 기능까지 포함하기 때문에 그 만큼 성능이 요구되기도 합니다.

아래는 라우터가 포함된 구조입니다.

해당 구조의 문제점은 라우터를 관리하는 리소스가 필요한 것입니다.

UTM에 문제가 발생한다고 내부 네트워크는 영향을 받지 않기 때문에 내부 인트라넷은 살아 있을 수 있습니다.

단, 네트워크 환경(DHCP서버와 DNS 서버 역할)이 라우터나 서버에서 작동되고 있어야 합니다.

네트워크 환경이 UTM을 포함하고 있다면 첫번째 환경과 다를바가 없습니다.

경험 상으로 UTM이 문제가 발생하면 대부분의 업무가 인터넷 환경이 기반이 되기 때문에 첫번째 환경이나 두번째 환경이 마찬가지로 일을 하지 않습니다.

그래서 장애가 발생하면 첫번째나 두번째나 똑같습니다. ㅎㅎㅎㅎ

그럼 환경 설정을 시작해보겠습니다.

제가 설정한 환경은 axgate와 fortigate 장비를 연결하였으나, 연결하는 방식은 똑같습니다.

[필요한 환경]

아래의 대역들이 서로 통신

ㅇ 첫번째 UTM IP 대역: 192.168.0.0/24 / fortigate

ㅇ 두번째 UTM IP 대역: 192.168.100.0/24 / axgate

[첫번째 UTM]

1. UTM에서 1개의 인터페이스에 IP 설정을 합니다.

   - IP: 1.1.1.1 / Subnet: 255.255.255.252 / GateWay IP: 1.1.1.2

2. Routing 정책을 추가합니다.

  - (찾아가야할 네트워크) 192.168.0.0/24 → IP 1.1.1.2

3. 정책을 추가합니다.

  - INBOUND: 출발지 192.168.0.0/24 → 도착지: 192.168.100.0/24 (출발지 인터페이스: IP 1.1.1.1 된 인터페이스)

  - OUTBOUND: 출발지 192.168.100.0/24 → 도착지: 192.168.0.0/24 (도착지 인터페이스: IP 1.1.1.1 된 인터페이스)

[두번째 UTM]

1. UTM에서 1개의 인터페이스에 IP 설정을 합니다.

   - IP: 1.1.1.2 / Subnet: 255.255.255.252

2. Routing 정책을 추가합니다.

  - (찾아가야할 네트워크) 192.168.100.0/24 → IP 1.1.1.1

3. 정책을 추가합니다.

  - INBOUND: 출발지 192.168.100.0/24 → 도착지: 192.168.0.0/24 (출발지 인터페이스: IP 1.1.1.1 된 인터페이스)

  - OUTBOUND: 출발지 192.168.0.0/24 → 도착지: 192.168.100.0/24 (도착지 인터페이스: IP 1.1.1.1 된 인터페이스)

[연결 테스트]

192.168.0.0/24 → 192.168.100.0/24

192.168.100.0/24 → 192.168.0.0/24

포티게이트의 웹 페이지 접근 보호 방법을 공유 합니다.

웹 페이지 노출을 맞기 위해서는 관리자 계정에 접근 제한을 하시면, 자동으로 웹 페이지 화면 노출이 차단됩니다.

WAN 인터페이스의 Administrative access에서 PING을 제거한다면,

외부에서 PING 체크도 되지 않으면서, 허용된 IP로 웹을 접속할 수 있게 됩니다.

[관리자 계정의 "Restrict login to trusted hosts" 활성화 여부: OFF]

[관리자 계정의 "Restrict login to trusted hosts" 활성화 여부: ON]

[WAN 인터페이스의 "PING" 체크 해제]