MacBook 터치바 오류 해결 법 (Control Strip Error)

오류는 크게 두가지 이다.

1. 아예 검은 화면으로 사라지거나, 터치바의 터치가 안먹는 경우

이 경우는 hang 걸린 상태로 해당 프로세스를 죽여주면 다시 살나면서 정상화 된다.

  • 터미널을 열고 (Spotlight에서 terminal을 입력 후 terminal.app 선택 )
  • 아래 명령을 입력 해준다.
killall ControlStrip

2. 이상 동작하는 경우 - 다양한 증상이 있다.

이 경우는 설정이 꼬여있는 경우로, 아래 증상 들이 나타난다.

  • 특정 버튼이 안 눌린다.
  • 터치바 축소된 상태에서만 동작하지만 터치바 확장시 검은 화면으로 터치바가 사라진다.
  • 확장 프로그램 환경설정 버튼만 나오고 누르면 설정의 확장 프로그램 나오지만 실제 제대로 설정 안되는 경우
  • 확장 프로그램 환경설정 설정이 터치바에 뜬다면 거의 이 경우 이다.

내용은 TouchBar 설정 파일을 지우고, 현재 MacBook에 있는 임시 파일을 모두 삭제한다. (따라서 시간이 좀 걸린다.)
터미널에 익숙한 사람은 아래 커맨드를 치고, 아닌 사람은 finder에서 찾아서 휴지통으로 넣고 리부팅 한다.

  • 터미널 사용
rm -f ~/Library/Preferences/com.apple.touchbar.agent.plist
rm -rf ~/Library/Caches/*
  • finder 앱으로 문제 설정 파일을 지울 경우
  1. Finder 실행 후 Shift + Command + G 를 눌러서 폴더로 이동 입력 창 띄운다.
  2. ~/Library/Preferences/ 를 입력하고 이동 버튼 누르고 com.apple.touchbar.agent.plist 파일을 찾아서 휴지통으로 이동
    처음 경로 입력때 첫번째 ~를 빠뜨지지 않도록 주의 하자
  3. 다시 Shift + Command + G 눌러서 ~/Library/Caches 를 입력해서 이동
  4. Command + A 를 눌러서 전체 선택한다음 휴지동으로 이동
  5. 껏다 켠다.
  6. 잘되면 휴지통 비운다.

'ETC.' 카테고리의 다른 글

PM, RFI, RFP, WBS, SOW, POC, BMT  (0) 2019.09.18
DDoS 장비 구성 방식  (0) 2019.01.23
애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29

RFI(Request For Information): RFP 작성을 위한 정보 요청서  

RFP(Request For Proposal): 요구사항 기반의 제안 요청서 

WBS(Work Breakdown Structure): 업무 분해 구조, TBS(Task Breakdown Structure): 작업 분해 구조
: 제품을 개발 생산하는 과정에서 기술적인 사항과 관련하여 하드웨어, 소프트웨어, 서비스 및 기타 작업 과제들을 상세하게 구성하여 조직화하는 것

SOW(Statement Of Work): 작업 지시서, 작업기술서, 업무기술서, 시방서. 공급할 제품 또는 서비스의 상세한 설명

POC(Proof Of Concept): 레퍼런스가 없거나 아직 시장에 나오지 않은 (신기술이 적용된) 신제품에 대한 기능과 성능을 검증하는 단계 

BMT(Bench Marking Test): 동일한 시험환경에서 경쟁사간의 제품 기능 및 성능에 대한 비교시험

'ETC.' 카테고리의 다른 글

MacBook 터치바 오류 해결  (0) 2020.03.22
DDoS 장비 구성 방식  (0) 2019.01.23
애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29

What’s Blue Origin’s motto?
“Gradatim Ferociter” is Latin for “Step by Step, Ferociously.” Bezos says that’s his approach to spaceflight. “If you’re building a flying vehicle, you can’t cut any corners. If you do, it’s going to be [just] an illusion that it’s going to make it faster. … You have to do it step by step, but you do want to do it ferociously.”

아마존의 창업자 제프 베조즈가 창업한 우주 기업 '블루 오리진'의 모토 이다.

Gradatim Ferociter : "한걸음씩 용감하게" 라고 보통 번역되었있는데 아래의 영어설명을 들어오면 “Step by Step, Ferociously.” 이다.

Ferocious : 사나운, 흉포한; 맹렬한, 격렬한

You have to do it step by step, but you do want to do it ferociously.”
당신은 그것을 차근차근 해나가야 하지만, 맹렬히(격렬히) 하기를 원해야 한다.

한걸음씩 나아가지만, 보다 공격적으로 적극적으로 하기를 원해야 한다는 뜻.

 

 

 

'ETC. > English' 카테고리의 다른 글

'확인하다' 영어 표현  (0) 2019.06.15

'확인하다' 영어 표현 차이

Clarify, Verify, Validate, Confirm, Check

  • Clarify – (다시 한번 말해달라고 하며 애매모호한 점을 명확하게 하기 위한) 확인하다, 명확히 하다.
    Clarify the position. (입장이 무엇인지 확인하다.) 
  • Verify – (진실로 주장되거나 알려진 사실이 실제로 진실인지 알아보기 위한) 확인하다, 정말인지 검증하다.
    Verify the claim. (주장이 사실인지 확인하다.) 
  • Validate – (권한이 있는 기준에 따라) 검증하다/ 인증하다 / 확인하다, 유효한지 검증하다
    Validate a contract. (계약을 인증하다)
  • Confirm – (사실로 서로 알고 있지만 공식으로 다시 한번) 확인하다. / 승인하다, 내용을 재확인하다.
    Confirm your appointment. (예약을 확인하다)
  • Check – (사실인지 아닌지 알지 못하는 상태에서) 확인하다. / 맞는지 아닌지 체크하다.
    Check your spelling. (스펠링이 맞는지 확인하다)

'ETC. > English' 카테고리의 다른 글

Gradatim Ferociter  (0) 2019.06.30

https://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?seq=17002


[Product Issue] TG DPX, 인라인 vs. 아웃오브패스 대결의 종결자

  • 안철수연구소
  • 2010-11-19

2006년도 하반기부터 시작된 국내 DDoS 시장에서 DDoS 공격 대응 제품은 여러 형태나 분류로 나눌 수 있다. 그 중 구성 방식에 따라 인라인(Inline) 방식의 제품과 아웃오브패스(Out-of-Path) 방식의 제품으로 구분하는 것이 가장 대표적이다. 이러한 두 가지 형태의 구성 방식은 사실 네트워크 담당자가 아니라면 생소하게 느껴질 수 밖에 없는 용어다. 
이 글에서는 인라인 구성 방식과 아웃오브패스 구성 방식에 대해 쉽고 명확하게 이해를 할 수 있도록 소개하고자 한다.


구성 방식에 따른 분류


인라인 방식과 아웃오브패스 방식은 해당 장비가 네트워크 구간 내에 어디에 위치하느냐에 따라 구분된다. 인라인 방식은 네트워크 구간 내에 위치하게 되며, 빠른 대응이 가장 큰 장점이다. 반면, 아웃오브패스 방식은 네트워크 외부에 위치하며, 네트워크 안정성이 높다는 것이 장점이다. 인라인 방식과 아웃오브패스 방식, 각각의 특성은 [표 1]과 같다.

 

 

Inline 구성 방식

Out-of-Path 구성 방식

구성의 특징

네트워크 구간 내에 위치

네트워크 외부에 위치

트래픽 기준

양방향 트래픽

단뱡향 트래픽

(일부 양방향 트래픽)

보안 적용의 장점

빠른 대응

네트워크 안정성 뛰어남

대규모 트래픽 구간에 설치 적합

구성의 단점

평상시 네트워크에 관여

Inline 대비 느린 대응

양방향 트래픽 구성 시 구성 복잡

적용 제품

방화벽, IPS, 웹 방화벽,

L2/L3/L4/L7 Switch

DDoS, 웹 방화벽, L4/L7 Switch, Proxy


이제 본격적으로 인라인 방식과 아웃오브패스 방식에 대해 자세히 알아보기로 하자.


Inline 구성 방식이란?


1. 구성 방식의 설명
인라인 방식은 라우터, 스위치 등과 같은 네트워크 장비 및 방화벽, IPS와 같은 보안 장비들의 구성 방식처럼 트래픽 소통 구간에 설치되는 방식을 의미한다(그림 1).

 

[그림 1]  Inline 구성 방식의 예


이 방식의 경우 네트워크 구간 사이에 위치하기 때문에 해당 장비의 설치 시 실시간 네트워크 트래픽의 단절 현상이 있으며, 회선 구성 등의 변경도 불가피하게 일어날 수 밖에 없다. 특히 인라인 방식의 제품이 IP 어드레스(Address)를 설정하는 구성 방식인 L3 (Routed) 인라인일 경우에는 설치되는 네트워크 구간 상단 및 하단 장비의 네트워크 IP 설정도 변경이 되어야 하는 부분이 있다. 이로 인해 최근에는 인라인 구성 방식으로 설치 시에는 IP 어드레스가 필요없는 L2 (Transparent) 모드를 선호하며, 대부분의 인라인 제품은 해당 구성 방식을 지원하고 있다.


2. 인라인 제품이 관여하게 되는 네트워크 트래픽의 특징
인라인 방식의 제품은 [그림 1]과 같이 트래픽이 소통되는 네트워크 구간 내에 설치가 되기 때문에, 내부로 들어오는 인바운드(Inbound) 트래픽과 외부로 나가는 아웃바운드(Outbound) 트래픽 등 양 양방향 트래픽 모두 해당 제품을 거치게 된다. 
모든 고객에게 있어서 설치된 인라인 제품의 장애나 트래픽 전송 지연 문제에 대해서는 매우 민감한 사안일 수 밖에 없다. 이로 인해 기본적으로 인라인 제품은 최소한의 전송 지연 시간 (Latency Time)이나 장애 시 트래픽 바이패스(Traffic Bypass) 기능 등의 대비책을 제공하고 있다.


3. 보안적인 측면에서 인라인 방식은 인바운드

보안적인 측면에서 인라인 방식은 인바운드 트래픽에 대한 보안 설정과 함께 아웃바운드 트래픽에 대한 보안 설정을 할 수 있다는 이점을 가지고 있다. 
특히 TCP 프로토콜(Protocol)의 경우에는 세션기반 프로토콜(Session Oriented Protocol)로서, 클라이언트와 서버 간의 양방향 통신을 유지해야만 하는 특징이 있다. 따라서, 일반적인 인라인 구성 방식의 방화벽이나 IPS 에서는 TCP 프로토콜에 대해 양방향 세션이 정상적으로 통신이 되고 있는지와 함께, TCP 프로토콜의 규약에 맞는 양방향 통신이 되고 있는지에 대해서도 점검하여 비정상적인 세션을 차단할 수 있는 보안 기능을 제공한다. 이 기능이 바로 잘 알려진 ‘스테이트풀 인스펙션(Stateful Inspection)’이다.
또한, 네트워크 구간 내에서 동작을 하고 있으므로, 보안 위협에 대한 탐지에 대해 즉시 차단 명령을 내리면 실시간으로 보안 정책이 적용될 수 있는 것이 가장 큰 특징이다. 물론, 최근에는 네트워크 구성이 매우 복잡하고 고도화되고 있어 네트워크 구간 내의 회선이 2중화 이상으로 구성이 되는 경우가 비일비재하다. 이러한 구성 방식을 대응하기 위하여 인라인 방식 제품은 하나의 장비에서 여러 회선을 수용할 수 있는 구성 방식과 함께 2대 이상의 인라인 방식 제품이 서로 실시간 TCP 세션을 공유할 수 있도록 하는 액티브-액티브(Active-Active) HA 구성 방식도 지원하는 제품도 있다.

 
4. 적용 제품의 예
A. 방화벽
    A. L3 (Routed) Mode 구성 방식의 방화벽
    B. L2 (Transparent) Mode 구성 방식의 방화벽
    C. L2 (Transparent) Mode 구성 방식의 Bypass 기능을 내장한 방화벽
B. IPS
    A. L2 (Transparent) Mode 구성 방식의 Bypass 기능을 내장한 IPS
C. Router/Switch
    A. L3 기반의 Routing 처리(Static & Dynamic Routing Protocol)
    B. L2 기반의 Swtching 처리


Out-of-Path 구성 방식이란?


1. 구성 방식의 설명
아웃오브패스 방식은 ‘Out-of-Path’라는 단어에서 의미하는 바와 같이 설치되는 장비가 트래픽의 소통 구간에서 외부로 빠져 나와있는 구성 방식을 의미한다. 이를 도식화하면 [그림 2]와 같다.

[그림 2] Out-of-Path 구성 방식의 예


특히, 아웃오브패스 방식은 인라인 방식과는 다르게 네트워크 구간 외부에 설치되어 전체 트래픽 중 특정한 트래픽만 통과하거나, 평상시에는 전혀 트래픽이 통과하지 않는 구성으로 이용이 가능하다. 이로 인해 제품이 설치가 되더라도 기존의 네트워크 트래픽 흐름에는 영향을 주지 않는 장점을 가지고 있다. 즉, 인라인 방식의 약점인 전송 지연, 또는 장애 등의 문제로부터 좀 더 자유로울 수 있다는 것이다.


2. 아웃오브패스 방식이 관여하는 네트워크 트래픽의 방향성
아웃오브패스 방식을 통과하는 트래픽의 유형은 크게 ‘특정 서비스 트래픽의 양방향 트래픽’이나 ‘특정 서비스 트래픽의 단방향 트래픽’의 두 가지 형태로 분류할 수 있다.

 

[그림 3] Out-of-Path 구성 양방향 트래픽  [그림 4] Out-of-Path 단방향 트래픽


먼저, 여기서 언급한 ‘특정 서비스 트래픽’이란 전체 네트워크 트래픽 아웃오브패스 방식의 제품만을 통과하는 서비스 트래픽을 의미하는 것이다. 예를 들어 대외 서비스를 하는 서버가 웹 서버, DNS 서버, 메일 서버가 있다고 가정하자. 이 경우, 아웃오브패스 방식 제품에서는 DNS 서버와 메일 서버의 트래픽을 제외한 웹 서버만을 통과시킨다. 즉, DNS 서버와 메일 서버의 트래픽은 아웃오브패스 방식의 제품이 관여하지 않는다는 것이다. 이로 인하여 기존의 DNS 서버와 메일 서버의 트래픽은 기존의 네트워크 경로를 그대로 이용하게 되므로, 서비스에 영향을 받지 않는다.
만약 양방향 트래픽을 이용할 경우에는 위에서 예를 든 웹 서버의 경우와 같이 클라이언트에서 서버로 요청하는 트래픽(Inbound Traffic)이 아웃오브패스 방식 제품으로 유입되고, 서버에서 클라이언트로 응답하는 트래픽(Outbound Traffic) 또한 아웃오브패스 방식의 제품으로 유입되는 구성 방식을 의미한다.


3. 보안 제품의 구성 제약 및 적용의 범위
아웃오브패스 방식에서 양방향 트래픽을 구성할 경우에는 네트워크 상에서의 트래픽 라우팅의 고려가 매우 중요하다. 일반적으로 네트워크 트래픽 라우팅은 목적지 IP 기반의 라우팅 정책을 적용하게 된다. 예를 들어 ‘웹 서버로 향하는 트래픽을 아웃오브패스 방식 제품으로 보내겠다’라고 하는 형태로 구성이 된다. 하지만 웹 서버가 랜덤한 출발지 IP로의 응답 트래픽을 아웃오브패스 방식 제품으로 보내고자 하는 라우팅은 목적지 IP 기반의 라우팅 정책으로는 적용이 불가능하다. 이로 인하여 PBR (Policy Based Routing) 등의 기법을 이용하여 출발지 IP 기반의 라우팅 기법을 적용해야만 웹 서버의 아웃바운드 트래픽도 아웃오브패스 방식 제품으로 트래픽을 유입시킬 수 있다.


양방향 트래픽 기준의 아웃오브패스 방식 제품은 이러한 문제점을 해결하기 위해 트래픽 통신을 중계시켜 주는 ‘프록시 IP’를 설정하여 운영하게 된다. 예를 들어 클라이언트가 웹 서버로 요청할 때에는 아웃오브패스 방식 제품에 설정된 웹 서버의 대표 IP로 요청을 하게 되고, 아웃오브패스 방식 제품은 설정된 프록시 IP를 이용해 서버로 트래픽을 중계하게 된다. 이후 서버의 응답 트래픽은 프록시 IP로 전달되고, 이 응답을 아웃오브패스 방식 제품이 클라이언트에게 전달하는 복잡한 구조로 대응한다.


하지만 대부분 가장 효율적인 방법으로 랜덤한 클라이언트의 요청 트래픽인 인바운드 트래픽에 대해서만 관심을 가지고 아웃바운드 트래픽에 대해서는 적용하지 않는 단방향 기준의 보안 정책도 많이 사용하고 있다. 이에 대한 대표적인 예가 DDoS 공격 방어의 경우이다. 
예를 들어, 웹 서비스의 보안 영역 중 DDoS 공격의 경우에는 외부로부터 웹 서버로 유입되는 대규모의 DDoS 트래픽에 관한 보안 정책이 필요하고, 그 반대인 웹 서버가 외부의 불특정 대상에게 DDoS 공격을 감행하는 사례는 매우 적다고 판단할 수 있다. 이때에는 DDoS 공격 방어를 위해서는 아웃바운드 트래픽에는 관여할 필요 없이 인바운드 트래픽 만을 대상으로 DDoS 공격 방어를 수행하면 된다. 한가지 예를 더 들자면, L4/L7 스위치의 경우에도 클라이언트의 웹 서비스에 대한 요청 트래픽만 처리하고, 웹 서비스의 응답 트래픽은 L4/L7 스위치를 거치지 않고 직접 클라이언트에게 전달되는 DSR(Direct Server Response) 방식을 들 수 있다.


특히 대규모 웹 서비스의 트래픽 특성을 살펴보면, 웹 서비스를 요청하는 클라이언트로부터의 인바운드 트래픽은 양이 작으며, 서비스에 응답을 하고 웹 페이지를 전달하는 아웃바운드 트래픽은 상대적으로 양이 많다. 이 경우 인바운드 트래픽만을 기준으로 보안을 구축할 때에는 대규모 서비스 망이라고 하더라도 상대적으로 적은 인바운드 트래픽 기준으로 보안 제품을 선택할 수 있으므로, 제품의 활용 효과 면에서도 이점을 가질 수 있다.


4. 적용 제품의 예
특정 서비스의 트래픽 중 양방향 트래픽을 사용하는 제품은 Transparent Mode의 L4/L7 스위치나 프록시 기반의 방화벽, 웹 방화벽 기반이 될 수 있다.
특정 서비스의 트래픽 중 단방향 트래픽을 사용하는 제품은 DSR(Direct Server Response) 모드의 L4/L7 스위치나 DDoS 공격 방어 제품이 있다.


지금까지 인라인 구성 방식과 아웃오브패스 구성 방식에 대해 간단히 기술적으로 비교해 보았다. 이 중 가장 많은 이야기를 이어나갈 수 있는 DDoS 공격 대응 제품에서의 인라인 구성 방식과 아웃오브패스 구성 방식에 대해서 이야기를 하고자 한다.


DDoS 공격 대응 제품, 인라인 vs. 아웃오브패스 전격 비교


DDoS 공격 대응 제품에 있어서 인라인 방식과 아웃오브패스 방식의 대결 구도는 어제 오늘의 일이 아니다. 고객은 DDoS 공격 대응 제품의 도입부터 이 두 가지 방식을 고려해야만 했다. 또한 벤더사는 자신의 제품이 채택한 방식의 강점을 부각시키기 위해 노력해왔다.


DDoS 공격 대응 제품의 구성 방식에 대한 이해


[그림 1]과 같이 인라인 구성 방식의 경우 네트워크 구간 내에 위치하게 되며, 단일 제품 또는 2대 이상의 다수의 제품으로 구성된다. 이 경우 DDoS 공격 대응 제품은 실시간으로 트래픽을 모니터링하며 차단할 수 있다.
반면 아웃오브패스 구성 방식의 경우에는 앞에서 설명한 바와 같이 네트워크 구간 외부에 위치하여 평상시에는 동작하지 않는 특징을 가지고 있다. 이로 인하여 DDoS 공격 발생 시 동작할 수 있도록 항시 모니터링하는 ‘탐지 전용’ 제품과 DDoS 공격을 실제적으로 차단하게 되는 ‘차단 전용’ 제품으로 역할이 나누어지게 된다. 물론, 대규모 트래픽을 처리할 수 있도록 탐지 장비와 차단 장비는 2대 이상의 다수의 제품으로 구성되는 클러스터(Cluster) 구성 방식도 있다.


DDoS 공격 방어 대상 트래픽: 양방향 Vs. 단방향


일부 네트워크 구성의 특성에 따라 인바운드 DDoS 공격과 아웃바운드 DDoS 공격 두 가지를 모두 고려하는 경우가 있다. 이러한 사례를 생각해보면 DDoS 공격 대응 제품이 보호하는 대상이 서버뿐만 아니라 클라이언트까지 포함된 네트워크 구간일 경우가 여기에 해당된다. 특히 서버가 외부 IDC에 있는 것이 아닌 자체 망의 DMZ 구간 내에 포함이 되어 있는 경우이다. 이 경우 DDoS 공격 대응 제품은 DMZ 네트워크와 내부 네트워크의 트래픽 단일 유입 구간에 설치가 될 경우에는 인바운드 DDoS 공격에 대해 DMZ 네트워크의 서버에 대한 DDoS 공격 방어를 수행한다. 그리고, 내부 네트워크 구간의 클라이언트 PC가 아웃바운드 DDoS 공격을 할 경우에도 방어를 수행하는 경우가 있다. 이 때에는 양방향 트래픽의 방향성에 적합한 인라인 구성 방식의 DDoS 공격 대응 제품이 적합하다.


하지만, 일반적으로 DDoS 공격은 외부에서 내부 서비스로의 대규모 트래픽을 유발하여 외부의 정상적인 사용자들이 서비스로 접근을 하지 못하게 하는 특징을 가지고 있다. 따라서 일반적으로 DDoS 공격 대응 제품은 인바운드 트래픽 관점에서의 방어를 원칙으로 한다.


따라서, 대외 서비스를 수행하는 서버에 대한 DDoS 공격 방어를 하기 위해서는 인라인 구성방식의 DDoS 공격 대응 제품에서 인바운드 DDoS 공격만을 관여하도록 하거나, 또는 대규모 트래픽이 발생하는 IDC 구간일 경우에는 아웃오브패스 구성 방식의 DDoS 공격 대응 제품이 적합하다.


DDoS 공격 방어 동작 시간의 적합성: 인라인 vs. 아웃오브패스


DDoS 공격은 공격이 발생하면 즉시 서비스가 마비되는 현상을 초래하므로 이에 대한 대응 시간이 매우 중요하다. 
인라인 구성의 경우 앞서 설명한 바와 같이 양방향, 또는 단방향 트래픽에 대해 실시간으로 탐지/차단을 수행하기 때문에 DDoS 공격 발생 시 즉시 설정되어 있는 정책에 의해 공격을 차단할 수 있다. 이 경우 최소 1초 이내의 DDoS 공격 탐지/차단 동작이 수행될 수 있는 장점이 있다.


반면, 아웃오브패스 구성의 경우에는 평상시 DDoS 공격을 차단하는 제품은 동작하지 않고, 이를 동작시키기 위해 상시 모니터링을 하는 DDoS 공격 탐지 장비가 별도로 구성이 된다. 이 경우 DDoS 공격이 발생이 되면 먼저 DDoS 공격 탐지 장비가 DDoS 공격을 인지하여 DDoS 공격 차단 장비로 동작 명령을 전달하여, 차단 장비가 DDoS 트래픽에 대해 차단을 처리하게 된다. 이로 인하여 아웃오브패스 구성 방식의 DDoS 공격 대응 제품은 인라인 구성 방식의 제품보다는 대응 시간이 느리다는 구조적 한계가 분명히 존재한다.


이를 보완하기 위하여 아웃오브패스 구성 방식에서 빠르게 동작할 수 있는 여러 가지 기술들이 개발되고 있다. 예를 들어, 기존의 사용되었던 스위치/라우터에서 수집되는 트래픽 플로우 정보가 아닌 실시간 트래픽 기준으로 탐지할 수 있는 기술이 적용되고 있다. 아울러 인바운드 트래픽만을 기준으로 하여 실시간 트래픽을 모니터링해 효율성을 극대화하는 기술도 현재 이용되고 있다. 


DDoS 공격 방어 기능: 인라인 vs. 아웃오브패스/양방향 vs. 단방향/클러스터링


지금까지 인라인 구성 방식과 아웃오브패스 구성 방식, 그리고 트래픽의 방향성에 대해 설명을 하였다. 하지만, 가장 중요한 것은 각 구성 환경과 트래픽 특성에 따라 DDoS 공격을 어떻게 방어할 수 있는지에 대한 DDoS 공격 방어 기능이다. 단순히 네트워크 구성만 지원한다고 해서 DDoS 공격을 대응할 수 있는 것은 아니므로, 본연의 기능인 DDoS 공격 방어 기능에 다시 초점을 맞추어야 한다.


우선, 인라인 구성 방식에서의 양방향 트래픽 관점에서의 DDoS 공격 방어 기능을 살펴보자. 이 경우에는 외부로부터 유입되는 인바운드 DDoS 공격에 대해 탐지/차단할 수 있는 기능이 기본적으로 제공이 되어야 한다. 특히 단순한 임계치(Threshold) 기반의 DDoS 공격 탐지/차단은 해당 정책에 의해 탐지/차단 되는 트래픽이 실제로 정상적인 패킷(Packet)인지 아닌지에 대해 명확히 판단할 근거가 없다. 따라서, 이러한 임계치 기반의 DDoS 공격 탐지/차단 동작 방식 이전에 해당 패킷이 정상적인 패킷 인지를 검증해 줄 수 있는 ‘인증 기반’의 DDoS 공격 탐지/차단 방식이 필요하다. 아울러 아웃바운드 DDoS 공격에 대해서는 내부 클라이언트/서버의 IP는 알고 있으므로, 이와 다른 IP 에서 발생할 경우에는 즉시 차단하고, 정상적인 응답 트래픽 특성이 아닌 경우에는 인증 기반 및 임계치 기반으로 탐지/차단 할 수 있는 기술이 필요하다.


두 번째로, 인라인 구성의 단방향 트래픽 관점과 아웃오브패스 구성의 단방향 트래픽 관점에서의 DDoS 공격 방어 기능에 대해 살펴보자. 앞서 언급한 바와 같이 인바운드 DDoS 공격에 대해 정확히 방어하기 위하여 ‘인증 기반’의 패킷 검증 방식과 ‘임계치(Threshold) 기반’의 정책 기반의 DDoS 탐지/차단 방식이 동시에 지원되어야 한다. 하지만 ‘인증 기반’의 경우에는 해당 구성에서는 단방향 트래픽만을 가지고 ‘인증 기반’을 사용해야 하므로, 인라인 구성 방식에서 사용하는 인증 기반 기술과는 다른 단방향 트래픽을 기준으로 한 독특한 기술이 필요하다. 또한 단순히 아웃오브패스 DDoS 탐지 장비에서 보여지는 양방향 트래픽 기준의 정상/비정상 연결(Connection) 여부만을 가지고 판단하는 것이 아닌, DDoS 공격 발생 시 아웃오브패스 DDoS 차단 장비에서의 실시간 인증 기반 검증이 제대로 된 DDoS 공격을 방어할 수 있는 기술이다.


마지막으로, 단방향 트래픽 기준의 인라인 및 아웃오브패스 구성 방식을 고려할 때 가장 큰 강점은 바로 여러 대의 DDoS 제품을 하나의 DDoS 제품처럼 클러스터링하는 것이다. 이 경우에도 앞서 설명한 바와 같이 ‘인증 기반’과 ‘임계치 기반’ 두 가지 방식이 지원되어야 하는 것이 매우 중요하다. 이와 더불어 다중 장비의 정책을 동시에 동기화 할 수 있는 관리 방안과 함께 ‘인증 기반’의 검증의 경우에는 다중 장비의 ‘인증’ 동작 정보가 실시간으로 공유가 되어야 여러 대의 DDoS 제품이 하나의 DDoS 공격 대응 솔루션으로 사용될 수 있다. 
 

[그림 5] Inline Cluster 구성의 예              [그림 6] Out-of-Path Cluster 구성의 예

 

AhnLab TrusGuard DPX, 
Inline / Out-of-Path / Clustering 구성이 지원되는 DDoS 공격 대응 제품


AhnLab TrusGuard DPX(이하 TG DPX) 는 업계 최초로 라이선스(License) 변경만으로도 동일 제품에서 인라인 구성 방식과 아웃오브패스 구성 방식, 그리고 클러스터링 구성까지 지원하는 제품이다. 
특히, 다단계 필터 구조를 통하여 기본적으로 제공되는 자동 학습 기반의 임계치 기준의 DDoS 탐지/차단 방식을 지원할 뿐만 아니라 실시간 인증 기반을 통하여 DDoS 공격 발생 시 유입되는 트래픽이 정상적인지 비정상적인지를 확인할 수 있는 기능을 제공한다.

[그림 7] AhnLab TrusGuard DPX 구성 방식의 예


TG DPX는 단방향 트래픽만을 기준으로 하여 아웃오브패스에서의 DDoS 공격 탐지를 할 수 있으며, 공격 차단을 공격 대상의 트래픽만을 기준으로 하여 인증 기반과 임계치 기반의 DDoS 공격 방어를 처리할 수 있는 독특한 기술을 제공하고 있다. 또한 DDoS 공격 차단을 수행하는 다중 장비간의 인증 정보를 실시간으로 공유함으로써, 단방향 트래픽 기준의 인라인 및 아웃오브패스 클러스터링 구성 방식까지 지원하고 있다.
이를 통하여 TG DPX는 기존 DDoS 공격 방어 시 임계치 기반 방식의 DDoS 공격 차단 처리 방식과 대비 정확하고 오탐이 최소화된 DDoS 공격 대응 기능을 제공한다. @


'ETC.' 카테고리의 다른 글

MacBook 터치바 오류 해결  (0) 2020.03.22
PM, RFI, RFP, WBS, SOW, POC, BMT  (0) 2019.09.18
애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29

출처: http://agilemanifesto.org/iso/ko/manifesto.html  http://agilemanifesto.org/iso/ko/principles.html

Principles behind the Agile Manifesto (애자일 소프트웨어 개발 선언)

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
공정과 도구보다 개인과 상호작용
포괄적인 문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기

That is, while there is value in the items on
the right, we value the items on the left more.
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

12 Principles Behind the Agile Manifesto (애자일 선언 이면의 원칙)

We follow these principles:
우리는 다음 원칙을 따른다:

  1. 고객만족 추구
    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
  2. 요구변경 적극 수용
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    • 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
  3. 짧은 배포 간격
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    • 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
  4. 현업-개발자간 일일 의사소통
    • Business people and developers must work together daily throughout the project.
    • 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
  5. 동기부여된 사람들 중용. 지원 및 신뢰
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
  6. 면대면 대화
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
  7. 작동하는 소프트웨어를 척도로
    • Working software is the primary measure of progress.
    • 작동하는 소프트웨어가 진척의 주된 척도이다.
  8. 지속가능한 개발 장려
    • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
  9. 좋은 기술, 설계에 관심
    • Continuous attention to technical excellence and good design enhances agility.
    • 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
  10. 단순성 추구
    • Simplicity–the art of maximizing the amount of work not done–is essential.
    • 단순성이 – 안 하는 일의 양을 최대화하는 기술이 – 필수적이다.
  11. 자기조직적 팀
    • The best architectures, requirements, and designs emerge from self-organizing teams.
    • 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
  12. 정기적으로 효율성 제고
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    • 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.


'ETC.' 카테고리의 다른 글

PM, RFI, RFP, WBS, SOW, POC, BMT  (0) 2019.09.18
DDoS 장비 구성 방식  (0) 2019.01.23
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29
[리눅스] CentOS 7 타임존 변경  (0) 2018.02.08

TCP 튜닝 -  CENTOS7

net.ipv4.tcp_congestion_control = bbr 적용을 위해 커널 4.15 로 업그레이드 (4.9이상 필요)

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm yum --disablerepo="*" --enablerepo="elrepo-kernel" list available yum --enablerepo=elrepo-kernel -y install kernel-ml

grub2-set-default 0

#리부팅 커널 버전 확인 reboot uname -sr


상기 커널 업그레이드를 할수 없다면 net.ipv4.tcp_congestion_control = cubic 로 변경 하거나 지운다(default가 cubic)

echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/ip_forward.conf

cat << EOF > /etc/sysctl.d/nettune.conf net.core.rmem_default = 524288 net.core.wmem_default = 524288 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.netdev_max_backlog = 30000 net.core.somaxconn = 1024 net.core.default_qdisc = fq net.ipv4.tcp_rmem = 262144 524288 16777216 net.ipv4.tcp_wmem = 262144 524288 16777216 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_max_tw_buckets = 1800000 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_congestion_control = bbr EOF


sysctl --system #sysctl -p /etc/sysctl.d/ip_forward.conf #sysctl -p /etc/sysctl.d/nettune.conf

http://meetup.toast.com/posts/55

https://www.tecmint.com/increase-linux-server-internet-speed-with-tcp-bbr/

https://www.vultr.com/docs/how-to-deploy-google-bbr-on-centos-7


iperf3

#클라이언트 iperf3 -V -c 10.178.31.240 -b 1G --get-server-output -P 5 iperf3 -V -c 10.178.31.240 -b 1G --get-server-output --udp -P 5 #서버 iperf3 -V -s




'ETC.' 카테고리의 다른 글

DDoS 장비 구성 방식  (0) 2019.01.23
애자일 소프트웨어 개발 선언,  (0) 2018.08.12
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29
[리눅스] CentOS 7 타임존 변경  (0) 2018.02.08
Proxy 설정 - nginx 사용하기  (0) 2017.12.14

원문 : https://www.clien.net/service/board/cm_nas/11884520


무료인증서 - 3개월 마다 갱신 필요.

Wildcard 가능해짐(2018년3월)

https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579


DNS 확인 방법으로는 인증서 자동 업데이트가 되지 않으므로, 추가

며칠 후면 인증서 발행 툴들이 보다 쉽게 적용할 수 있도록 업데이트 되리라 믿습니다.


Wildcard이기 때문에 서버로 인증받는게 아닌 도메인의 TXT값을 직접 입력해주어야한다.

아래 과정 중 나오는 값은 _acme-challenge 호스트네임으로 TXT로 입력해주면 된다.

_acme-challenge.opencloud.kr


1. 서버 접속 후 루트 접근 

$ sudo su -


2. certbot 설치

# git clone  https://github.com/certbot/certbot

# cd certbot

# sudo ./certbot-auto --os-packages-only    #여기서 y를 눌러서 필수 패키지를 설치한다.

# ./tools/venv.sh


3. certbot 으로 인증서 발행

# source ./venv/bin/activate

# 도메인명과 이메일을 수정해서 아래 명령을 시행합니다.

sudo ./venv/bin/certbot -d *.도메인명 --email 이메일 --text --agree-tos --server  https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns --expand --renew-by-default  --manual-public-ip-logging-ok certonly


처음 위 명령을 실행하면 이메일을 등록하라고 합니다. Y 를 누릅니다.

다음으로 certbot 프로그램이 _acme-challenge.도메인명  에 입력할 DNS TXT를 화면상에 보여 줍니다.

_acme-challenge.[도메인명] DNS TXT

도메인에 해당값을 셋팅한 후 엔터를 누르면 해당 도메인을 검증하고 인증서가 발행됩니다.

재실행시 TXT값이 바뀌므로 도메인 셋팅 후 엔터를 누르도록 합니다.


추가) 인증서 확인

# ./venv/bin/certbot certificates

인증서 위치

# /etc/letsencrypt/live/[도메인명]


# 인증서 폴더 접근 권한 설정

sudo chown [사용자명] /etc/letsencrypt/live


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

*추가 정보1: PEM ->  PFX (IIS 서버용으로 변환)

sudo openssl pkcs12 -passout pass:[패스워드] -export -out ./cert.pfx -inkey /etc/letsencrypt/live/[도메인명]/privkey.pem -in /etc/letsencrypt/live/[도메인명]/cert.pem -certfile /etc/letsencrypt/live/[도메인명]/chain.pem


변환된 인증서 접근권한 부여


sudo chown [사용자명] ./cert.pfx


*추가 정보2: 와일드카드 외 도메인 등록

익스체인지 서버에서는 와일드카드(*) 도메인 인증서 등록시 에러가 발생하더군요, 아래와 같이 mail을 명시적으로 추가해서 만들어 주니 문제가 없었습니다.

sudo ./venv/bin/certbot -d mail.[도메인명],*.[도메인명]  --email [이메일] --text --agree-tos --server  https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns --expand --renew-by-default  --manual-public-ip-logging-ok certonly


=======================

crontab에 아래 추가

# 매일 리뉴얼 체크를 한다.

0 4 * * * /bin/bash -l -c '/root/certbot/certbot-auto renew --quiet --no-self-upgrade'

# 혹시 리뉴얼된 인증서를 어디 복사해야 한다면 아래 처럼 rsync로 변경 확인 후 복사해 준다.  

5 4 * * * /bin/bash -l -c 'rsync -L --checksum /etc/letsencrypt/live/cloudz.info/privkey.pem /srv/docker/redmine/redmine/certs/redmine.key'

5 4 * * * /bin/bash -l -c 'rsync -L --checksum /etc/letsencrypt/live/cloudz.info/fullchain.pem /srv/docker/redmine/redmine/certs/redmine.crt'


'ETC.' 카테고리의 다른 글

애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
[리눅스] CentOS 7 타임존 변경  (0) 2018.02.08
Proxy 설정 - nginx 사용하기  (0) 2017.12.14
Subnet BIT  (0) 2017.08.30

https://www.fun25.co.kr/blog/linux-centos-7-change-timezone/?page=9


CentOS 7 에서 타임존 변경 방법입니다.

사용가능한 타임존

# timedatectl list-timezones | grep Seoul
Asia/Seoul

타임존 변경

# timedatectl set-timezone Asia/Seoul


수동으로 변경해야 할 경우는 기존의 /etc/localtime 파일을 삭제 후

# ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

타임존 확인

# date
2016. 01. 18. (월) 21:12:30 KST


'ETC.' 카테고리의 다른 글

애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29
Proxy 설정 - nginx 사용하기  (0) 2017.12.14
Subnet BIT  (0) 2017.08.30

정확하게는 Reverse Proxy 형태의 포트 포워딩 되시겠다.

방법은 여러가 지가 있겠으나... 일단 TCP 레벨이 가능한 아래 2가지를 먼저 해본다.

NGINX/HAProxy를 쓰는 방법

IPTables(CentOS6) 또는 FirewallD(CentOS7)를 쓰는 방법

NGINX 설정

sudo su -
yum install -y nginx nginx-mod-stream
vi /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

stream {
    server {
        listen     443;
        proxy_pass s3.ap-northeast-2.amazonaws.com:443;
    }
}
#자동 시작 설정 및 서비스 시작
systemctl enable nginx
systemctl start nginx

#동작 테스트
curl -v --insecure https://localhost

'ETC.' 카테고리의 다른 글

애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29
[리눅스] CentOS 7 타임존 변경  (0) 2018.02.08
Subnet BIT  (0) 2017.08.30

+ Recent posts