2018-03-29

[보안] Alice와 Bob

네트워크 프로토콜을 설명하는 글을 읽으면 AliceBob, Carol, Eve, Mallory 등 많은 이름이 등장한다. 보통 이 이름들은 일정한 규칙을 가지고 부여되기 때문에 각 이름이 무슨 의미를 가지는지 안다면 그 프로토콜이 무엇을 어떻게 풀려고 하는지 조금은 더 이해하기 쉬워진다. 이번 글에서는 많이 네트워크 프로토콜에서 많이 사용되는 이름들이 무슨 의미를 가지는지 간략하게 정리해보았다.

네트워크 참여자 - Alice, Bob

보통 AliceBob은 서로 통신하려는 사람을 의미한다. 이때 통신하는 메시지는 보통 암호화하여 통신하는 메시지를 의미하는데 비대칭 키를 사용할지, 대칭 키를 사용할지는 그때그때 다르다.

다자 간 통신 참여자 - Carol, Dave, Erin, Frank, Gray

CarolDaveAliceBob과 함께 통신에 참여하는 경우 사용된다. CarolDave 말고도 CharlieDavid 같은 이름을 사용하기도 하지만 보통 CarolDave를 많이 사용한다.

5명 이상의 참여자가 필요한 프로토콜을 묘사할 때는, E, F, G로 시작하는 이름들을 사용한다. 보통 Erin, Frank, Gray 등의 이름이 사용되는데 어떤 이름을 사용할지는 딱히 정해져 있지 않다. 다른 용도로 사용되는 EveFaythe, Grace 등을 제외하고 아무 이름이나 사용된다.

공격자 - Eve, Mallory, Oscar, Trudy

Eve는 보통 네트워크를 감시하여 패킷을 도청하는 공격자를 의미한다. 다만 Eve는 능동적으로 공격을 하지는 않고 AliceBob이 주고받는 대화를 도청하여 무슨 대화를 주고받는지 알아내는 공격자에게 붙이는 이름이다. 이름의 유래는 eavesdrop에서 나왔다.

Trudy라는 이름은 Eve보다 조금 더 적극적인 공격자를 지칭할 때 사용된다. AliceBob 사이에 끼어들어 AliceBob의 메시지를 가로채 변조하여 보내거나 지우고 자신이 보내고 싶은 메시지를 보내는 공격자를 의미한다. 이름은 intruder에서 유래했다.

조금 더 포괄적인 공격자를 부르는 이름으로 Mallory가 있다. 이름의 유래는 malicious라는 단어에서 나왔다. EveTrudy와 구분 없이 공격자는 전부 합쳐 Mallory라고 부르기도 하므로 Mallory라는 이름이 나오면 이 사람이 어떤 공격을 하는지는 상황에 맞게 해석해야 한다. 이와 비슷한 의미로 사용되는 Oscar라는 이름도 있다.

감시자 - Walter, Wendy

Walter 혹은 Wendy라는 이름은 참여자를 감시하는 합법적인 감시자를 의미한다. 이들이 하는 일은 Mallory를 비롯한 공격자들과 비슷하지만, WendyWalter라는 이름이 나오면 AliceBob이 악의적인 사용자가 된다. 하지만 검열 감시를 피하는 것을 목적으로 하는 프로토콜을 설명할 때도 WalterWendy라는 이름을 사용한다. 예를 들면 검열하는 정부나 기업을 Wendy라고 이름 붙이고 이를 피하기 위한 참여자를 AliceBob이라고 이름하기도 한다.

WalterWendy는 크게 구분 없이 사용되는데 굳이 구분하면 Wendy는 허락되지 않은 정보를 주고받을 때 패킷을 검열하여 보내지 않도록 하는 역할을 하지만 Walter는 패킷을 검열하지는 않고 감시하는 역할만 할 때 사용된다. 보통 메시지를 감시하는 사람이 검열도 하기 때문인지 Wendy라는 이름이 더 많이 사용된다.

신뢰할만한 제삼자 - Trent, Ted

지금까지 설명한 이름들은 AliceBob의 통신을 방해하는 역할에 주어지는 이름이었다. 하지만 지금 설명할 TrentAliceBob의 통신을 도와주는 역할을 한다. 구체적으로 어떤 역할이 있지는 않고, AliceBob의 통신을 도와주는 역할을 한다. AliceBob이 통신할 shared secret을 생성, 관리해주기도 하고, 어떨 때는 AliceBob이 직접 통신하는 것이 아닌 대신 통신할 수 있는 암호화 된 채널을 만들어주기도 한다. 비대칭 키를 사용하는 경우, AliceBob의 public key를 저장하는 저장소를 Trent라고 부르기도 한다. Trent 대신 Ted라고 부르기도 하며 이름의 유래는 trust다.

2018-03-26

이더리움과 Eclipse attack

p2p 네트워크는 많은 취약점을 가지고 있는데 대표적인 것이 Eclipse attack이다. Eclipse attack은 네트워크 전체를 공격하는 것이 아니라 목표로 하는 노드의 Routing table을 공격하여 목표로 하는 노드와 전체 네트워크 사이에 악의적인 노드를 집어넣는 공격이다. Routing table을 공격하는 방법이기 때문에 routing-table poisoning이라고도 불린다.

이더리움도 p2p 네트워크를 사용하여 메시지를 주고받기 때문에 eclipse attack이 가능하리라 생각은 했는데 지난 3월 1일 발표 된 페이퍼에 따르면 단 2개의 노드만으로 하나의 노드를 완전히 고립시키는 것이 가능하다고 한다. 이 페이퍼는 올해 1월 진행됐던 바운티 프로그램에서 나온 문제점들을 정리한 페이퍼로 크게 세 가지 공격방법으로 나눌 수 있다.

우선 첫 번째 문제는 이해하기 위해 이더리움이 p2p 네트워크를 어떻게 관리하는지 이해해야 한다. 네트워크 그래프 구성에 가장 중요한 것은 다른 노드를 어떻게 찾을 것인가 하는 것이다. 이를 흔히 node discovery라고 하는데 이더리움은 node discovery를 위해 DHT(Distributed Hash Table) 프로토콜 중 하나인 Kademlia의 일부를 수정해서 사용한다.
Kademlia가 다른 DHT와 다른 가장 큰 특징은 노드 간의 거리를 XOR distance로 측정한다는 것이다. XOR distance의 거리는 symmetric 하므로 노드 아이디만 알고 있으면, 노드 A가 생각하는 노드 B까지의 거리나, 노드 B가 생각하는 노드 A까지의 거리나, 노드 C가 생각하는 노드 A와 노드 B 사이의 거리가 같다. 따라서 각 노드는 자신이 알고 있는 노드 중에서 자신과 가까운 노드들과만 통신하면 적은 연결 수로도 큰 네트워크를 구성할 수 있다는 장점이 있다. Kademlia 페이퍼에는 대략 노드의 개수를 N이라고 할 때 각 노드는 O(log(N))개의 연결만 유지하면 된다고 말한다.
이더리움이 Eclipse attack에 취약했던 근본적인 원인이 여기에 있다. Kademlia 프로토콜에서는 거리를 노드 아이디를 기반으로 구하는데, 어떤 노드의 아이디가 무엇인지 네트워크 안에 있는 모든 노드가 같은 값으로 알고 있어야 한다. 그래야 Kademlia가 주장하는 효율성을 가져올 수 있다. 문제는 분산 환경에서 각자의 아이디를 동의하는 방법이 없기 때문에 연결을 요청하는 노드가 자신의 public key를 알려주면 그 public key를 노드 아이디를 Keccak hashing 한 값을 노드 아이디로 준다. 즉, 각 노드가 자신의 아이디를 정하여 알려주는 것이다. 따라서 하나의 머신에서 여러 개의 노드 아이디를 생성해낼 수 있고, 악의적인 사용자가 하나의 머신을 여러 개의 노드인 것처럼 꾸미는 Sybil attack이 가능해진다.
이를 막기 위해 IP 주소와 노드 아이디를 기억하여 하나의 주소에서 여러 개의 키를 사용 못 하게 하는 것이 필요하지만, 아직 구현된 솔루션은 존재하지 않는다.

두 번째 공격 방법은 서버의 시간을 조정하는 것이다. 이더리움은 replay-attack을 막기 위해서 메시지에 보낸 시간을 적는다. 그리고 받은 메시지의 시간이 현재 시각과 20초 이상 차이가 나면 replay-attack으로 받은 메시지로 가정하고 무시한다. 문제는 replay-attack인지 판단하기 위해 메시지에 적힌 시간을 사용할 뿐, 메시지를 보낸 실제 시간은 알 수 없다는 것이다. 예를 들어 두 노드 사이에 시간이 20초 이상 난다면, replay-attack이 아닌 정상적인 메시지도 절대 처리되지 않는다.
현대 서버 환경에서 이럴 일은 거의 없다. 보통 서버 시간을 수동으로 설정하지 않고 NTP(Network Time Protocol)를 이용해 주기적으로 동기화하기 때문이다. 따라서 모든 서버의 시간은 길어봐야 몇 초 이내의 오차를 가질 것이라고 가정해도 된다.
하지만 이는 정상적인 상황에서만 가능한 가정이다. 만약 희생자가 될 노드가 사용할 NTP 서버를 해킹하거나 NTP 메시지를 가로채 동기화하지 못 하는 상황을 만들면 어떻게 될까. 아니면 조금 더 적극적으로 NTP 메시지를 가로채 실제 시간과 20초 이상 앞으로 당기면 어떻게 될까.
이 경우 희생자 노드는 네트워크상의 모든 노드와 시간 차이가 나게 될 테니, 다른 노드들은 모두 이 노드에서 보내는 메시지를 무시할 것이다. 그렇게 되면 희생자 노드는 네트워크에서 잊히게 되고 결국 희생자와 통신하는 것은 NTP 서버를 해킹했던 공격자 노드밖에 남지 않게 된다.
이는 메시지에 시간을 적는 방식으로 replay-attack을 막으려고 했던 이더리움 프로토콜의 문제다. 이런 공격을 막기 위해서는 세션별 혹은 메시지 별로 nonce를 사용하여 sign 하는 방법을 이용해야 한다. 하지만 이에 관한 솔루션도 아직 이더리움에는 구현된 것은 없는 것으로 보인다. 따라서 이더리움 노드를 돌리고 있는 서버는 시간이 잘 동기화되고 있는지 주기적으로 확인하는 방법밖에 없다.

마지막 공격 방법은 일종의 타이밍 어택이다. 이더리움은 네트워크에 너무 많은 리소스를 사용하지 않기 위해 통신할 최대 연결 수를 정해놓고 있다. 현재 최대 연결 수는 25개로 25개 이상의 연결이 맺어지면 더는 새 연결을 요청하거나 받아주지 않는다.
반대로 말해서 어떤 노드의 연결을 25개 점유할 수 있으면 이 노드는 더 이상 새 연결을 요청하지도 받아주지도 않을 것이다. 그렇다면 이것은 어떻게 가능할까?
간단하다. 연결이 0개인 순간을 노리면 된다. 어떤 서버라도 서버가 처음 시작했을 때는 연결이 0개인 상태가 된다. 이 타이밍을 노려서 25개의 연결을 먼저 맺으면 된다. 그렇다면 서버가 재시작되는 순간은 어떻게 찾을까.
하드웨어 문제든 OS 업데이트든 이더리움 클라이언트를 업데이트하든 서버가 재시작될 이유는 많이 있다. 하지만 조금 더 공격적으로 DoS 공격을 하여 이더리움 클라이언트를 죽이는 방법도 있다. 보통 이더리움 마이닝 노드는 서버가 종료되면 바로 다시 시작하게 돼 있기 때문에 DoS 공격으로 서버를 죽이고 나면 얼마 지나지 않아 서버가 재시작할 것이고 이때 25개 이상의 연결을 빠르게 요청하면 된다.
이를 막는 방법은 앞에서 설명한 두 방법보다 쉽다. 앞의 두 방법은 프로토콜 자체를 바꿔야 하지만 이 공격은 구현체를 수정하는 것만으로 쉽게 막을 수 있다. 전체 연결 개수 제한과 별개로 외부에서 들어오는 연결의 개수를 제한하는 것이다. 즉, 최소 몇 개의 연결은 내가 요청하는 노드와 연결이 되도록 하면 누군가 다른 사람에 의해 내 연결이 독점 당할 위험은 사라진다. 이 솔루션은 2월에 릴리즈 된 go-ethereum 1.8 버전부터 적용된 것으로 보인다.

2018-03-25

2018년 12번째 주

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

not invented here syndrome

not invented here syndrome이란 말 그대로 자신이 아닌 다른 사람 혹은 다른 팀에서 개발한 물건을 배척하는 태도를 말한다. 너무나 당연하게 이런 태도는 잘못된 것이다. 사람이 필요로 하는 것은 대부분 비슷하기 때문에 이미 그것을 만든 사람이 있을 것이다. 게다가 내가 천재가 아닌 이상 더 오랜 시간 개발되고 테스트해온 다른 라이브러리가 더 안정적으로 돌아갈 것은 당연하다.
하지만 요새는 오히려 반대의 태도. 즉, 모든 라이브러리나 툴을 외부에서 가져와서 해결하려는 태도 때문에 개발이 더 느려지게 되었다. 라이브러리 혹은 프레임웍은 일반적인 문제에 대해서 해결하고자 작성됐기 때문에 간단한 문제를 써드파티 라이브러리로 해결하려고 할 때 오히려 문제가 더 커지기도 한다. 널리 쓰이는 용어는 아니지만 이를 not invented here의 반대된다는 뜻에서 invented here syndrome이라고 부르는 사람도 있다.
결국 엔지니어링은 트레이드오프 사이에서 하나를 선택하는 것이기 때문에 직접 구현할지 써드파티 라이브러리를 사용할지 적절한 수준에서 잘 선택해야 한다.

조직문화와 리더십을 일치시키지 마라

회사 경영에서 추구하는 바를 크게 성과 지향과 관계 지향으로 나눴을 때 어느 쪽을 추구할 것인지에 대해서 조직이 추구하는 방향과 리더가 추구하는 방향을 일치시키지 말라는 글이다.
상식적으로는 리더가 성과 지향일 경우 조직 문화도 성과 지향적이어야 높은 성과를 내기 쉽고, 리더가 관계 지향일 때는 조직도 관계 지향적이어야 회사가 원활하게 돌아간다고 생각하기 쉬운데, 이를 전면적으로 부정하는 연구결과이다. 물론 성과지향인지 관계지향인지는 주관적인 것이기 때문에 단순 설문으로 잘 측정됐을지라거나, 구성원의 행복도 같은 것을 무시하고 재무제표 상에서의 성과만을 측정했다는 점에서 논란의 여지가 있을 수 있겠지만 그래도 조직을 운영할 때, 혹은 일 할 회사나 팀을 선택할 때 한 번 생각해볼 만한 주제라고 생각한다.

EditorConfig

얼마 전까지만 해도 거의 모든 작업을 vim으로만 했기 때문에, vim 설정만 잘해놓으면 됐다. 근데 최근에 Clion을 적극적으로 사용하게 되면서 둘 사이의 스타일이 달라져서 생기는 문제가 발생하게 됐다.
그래서 찾아보니 서로 다른 IDE에서 코딩 스타일을 통일하기 위한 EditorConfig라는 설정이 있다는 것을 알게 됐다. clion을 비롯한 JetBrains 제품들은 별도의 플러그인 없이도 EditorConfig 설정을 읽고 있고, vim을 위해서는 EditorConfig 팀이 제작한 플러그인이 존재한다.

CAP theorem

CAP theorem은 분산 스토리지는 consistency(a.k.a. C), availability(a.k.a A), partition tolerance(a.k.a. P)를 동시에 만족시킬 수 없다는 것이다. 여기서 C, A, P는 각자 일반적으로 사용되는 용어와 다른 용어로 사용되기 때문에 CAP theorem을 이해하려면 각자가 정의하는 것을 이해하는 것이 중요하다.

C는 모든 read operation이 최신 데이터를 받는 것을 보장하는 것이다. C를 보장하는 시스템은 만약 최신 데이터를 돌려줄 것을 보장하지 못한다면 에러를 돌려줘야 한다. 개인적으로 분산 스토리지를 구현할 때 C, A, P 중 가장 구현하기 어려운 특성은 C라고 생각한다.

A는 모든 operation이 에러가 아닌 데이터를 돌려주는 것이다. 이때 돌려주는 값은 최신 값이 아니어도 상관없다. 심지어 eventual consistencyA를 보장하는 시스템에서는 실제로 존재할 수 없는 데이터 조합이 생길 수도 있다.

P는 partition 상황에서도 시스템이 정상 동작해야 한다는 것이다. 여기서 시스템이 정상 동작한다는 것이 언제나 최신 데이터를 보장하거나 에러가 아닌 값을 준다는 것이 아니다. 그것은 CA가 보장하는 것이고 partition 상황에서도 partition이 아닌 상황과 같은 것을 보장하면 P를 보장한다고 할 수 있다.

근데 여기서 partition은 정말 네트워크 레이어에 문제가 생겨 물리적으로 다른 망이 구성되는 상황을 말하는 것이 아니다. partition은 일부 메시지가 전달되지 않는 상황도 포함된다. 이는 분산환경에서 매우 흔히 발생하는 일이고 P를 포기한다는 것은 결국, 분산 환경을 포기한다는 말이 되기 때문에 분산 데이터 스토리지를 만들 때는 결국 CPAP 중 하나를 선택해야 한다.

개인적으로 생각하기에 CPAP 중 구현하기 더 어려운 것은 CP라고 생각된다. 모든 노드가 언제나 같은 상태를 유지하게 하는 것은 생각보다 어렵고 비싸다. 게다가 CP는 근본적으로 AP보다 latency와 throughput이 떨어진다.

하지만 이런 문제에도 불구하고 데이터 스토리지를 사용하는 application을 선택하는 입장에서는 AP보다 CP를 선호해야 한다고 생각한다. CP 대신 AP를 선택하는 이유는 가용성 때문이다. 가용성은 분명 중요하다. 하지만 스토리지의 가용성과 application 전체의 가용성은 다른 말이다. 데이터 스토리지가 정상적으로 동작하고 있다고 하더라도, 데이터의 일관성이 보장되지 못해서 잘못된 값을 돌려주었다면 이 application은 정상적으로 동작했다고 말할 수 있을까.

이런 일을 방지하기 위해서 AP인 스토리지를 사용하는 로직에는 데이터를 체크하는 복잡한 로직이 들어간다. 복잡한 로직은 높은 버그 가능성과 같은 의미이다. application 로직이 복잡해져서 버그가 발생했고 이를 고치기 위해 서비스를 종료했다면 이 application의 가용성은 떨어지게 된다. 게다가 버그로 인해 잘못된 응답을 준 경우는 오히려 처리하기 쉽다. 만약 버그로 인해 잘못된 데이터가 스토리지에 저장됐다면 이는 잡기도 어려울뿐더러, 고치기도 어렵다.

APCP보다 latency와 throughput이 떨어지기 때문에 성능이 필요한 application을 위해서는 AP인 스토리지를 선택해야 주장하는 사람들도 있다. 하지만 성능도 가용성과 마찬가지로 스토리지의 성능은 스토리지를 사용하는 application의 성능과는 별개다. AP인 스토리지를 사용하여 CP인 스토리지를 사용할 때보다 높은 성능을 보여준다는 것을 주장하기 위해서는 데이터 스토리지의 처리 시간이 application 처리 시간의 대부분을 차지한다는 것을 증명해야 한다. 여기서 측정하는 시간은 단순히 데이터 스토리지에 요청한 operation의 처리속도가 아니라, 네트워크 전송 속도를 제외한 데이터 스토리지 내부의 소요 시간이어야 한다.

설령 스토리지가 처리 속도에 충분한 영향을 준다고 하더라도 AP인 데이터 스토리지를 선택하기 전에 중요한 것이 처리 속도인지, 스토리지를 바꾸지 않으면 처리 속도를 올릴 방법이 없는지 고민해봐야 한다.

2018-03-11

2018년 10번째 주

 이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Slack Is Shutting Down Its IRC Gateway

 채팅 프로그램들은 누구나 겪는 문제 중 하나가 일부 사용자가 IRC 클라이언트를 포기하지 않는다는 것이다. Slack도 마찬가지였고, 이에 대해서 Slack은 IRC Gateway를 지원하여 IRC 사용자들도 Slack에 포함시키려는 노력을 하였다.

https://xkcd.com/1782/

 하지만 이제는 Slack을 IRC 클라이언트에서 사용할 수 없다. Slack이 IRC 서포트를 중지한다고 발표했다.
 모든 플랫폼에서 같은 사용자 경험을 주고 싶은데 IRC에서 지원하지 않는 기능들이 방해되기 때문이라고 한다. 하지만 이미 Slack에서 IRC Gateway를 사용하는 사람들은 그 한정된 기능에 적응하고 사용하고 있는 사람들일 텐데, 이 사람들을 포기하면서 같은 사용자 경험을 주는 것이 그리 중요한 일일까 싶다. 그보다는 IRC Gateway를 이용하는 사람들을 Slack이 유료로 파는 기능들을 사용하지 않기 때문이 아닐까 싶다.

Why RSS Still Beats Facebook and Twitter for Tracking News

 Facebook이나 Twitter 같은 SNS가 생긴 뒤로 많은 사람이 자신의 포스팅을 SNS에 올리기 시작했고, RSS(Rich Site Summary)는 이제 사용되지 않을 것으로 생각했다. 대표적인 RSS 구독 서비스였던 Google Reader가 2013년 서비스를 종료했던 것이 RSS의 죽음을 나타내는 가장 상징적인 사건이었다.
 하지만 사람들은 여전히 RSS를 포기하지 않았다. 5년이 지난 지금까지 사람들은 여전히 RSS를 사용하고 있다. RSS는 SNS가 가지지 못 하는 장점이 여러 개 있다.
 일단 RSS를 사용하면 내가 구독하고 있는 것을 못 보고 넘어갈 일이 없다. SNS는 기본적으로 최근 포스트를 우선으로 보여준다. 내가 매일 접속하여 꾸준히 보지 않으면, 놓치는 정보가 있을 수 있다.
 게다가 SNS에서 보여주는 정보는 내가 원하는 정보라고 확신할 수 없다. RSS는 내가 RSS Reader에 구독을 원하는 주소를 등록하는 방식이지만, SNS는 자신들이 추천하는 포스트를 나에게 보여준다. 나름대로의 추천 알고리즘을 통해 정보를 뿌려주지만 내가 원하는 글이라고 확신할 수 없다.
 마지막으로 RSS는 하나의 서비스만 사용하면 되는데, SNS는 종류별로 가입해야 한다. 글을 올리는 사람이 모든 SNS에 다 올리면 좋겠지만, 현실은 그렇지 않다. 모든 글을 구독하기 위해서는 모든 SNS에 가입해야 하고, 내가 원하는 글만 보는 것이 아니라 각 SNS가 추천하는 글도 다 보게 된다.
 이런 문제들을 해결할 방법이 나오기 전에는 RSS가 죽을 일은 없을 것 같다.

static local variable


 일단 C++11 이후. 즉, 모던 C++에서는 맞는 말이다. 그 이전에서는 멀티 스레드 프로그램에서는 싱글턴을 사용해야 했는데, 그런 경우가 있으면 2018년에 모던 C++이 아닌 상황에서 이미 망한 프로젝트니까 빠르게 도망치자.
 과거에, 그러니까 C++의 abstract machine이 스레드에 대해 고려를 하지 않았던 시절에는 여러 스레드에서 동시에 static local variable을 사용하는 것이 문제가 될 수 있었다. 하지만 모던 C++에서는 abstract machine에 스레드 개념이 들어갔고, 여러 스레드가 동시에 접근하더라도 static local variable이 단 한 번만 초기화돼야 한다고 명시됐으니 그냥 컴파일러를 믿고 사용하면 된다.

2018-03-04

2018년 9번째 주

 이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다.
 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다.

Lifetime Safety: Preventing Leaks and Dangling

 Herb Sutter와 Neil MacIntosh가 쓴 C++에서 memory leakdangling pointer를 어떻게 없앨 수 있는지에 관한 글이다. 일반적으로 C++의 포인터는 매우 강력하기 때문에, memory leak이나 dangling pointer를 없애기 위해서 C++의 기능을 일부 제한하거나 새로운 문법을 추가하거나 한다. 하지만 이 글에서는 언어를 바꾸지 않으면서 런타임 오버헤드 없이 컴파일 타임에 분석할 수 있는 알고리즘을 제시한다.
 특히 이 알고리즘은 프로그램 전체를 분석하는 것이 아니라 함수 단위, 정확히는 블록 단위로 적용할 수 있고, 변수 재사용 등 많은 스타일 가이드에서 권하지 않지만 실제로는 많이 사용되는 패턴들에 대해서도 고려돼있기 때문에 레거시 코드에 적용하기도 좋다.
 기계적인 작업이기 때문에 툴을 만드는 것이 가장 좋을 것이다. 하지만 툴을 만들 여유가 없더라도 포인터나 레퍼런스를 어떻게 써야 안전한지 보여주는 좋은 글이기 때문에 일단 읽어보는 것을 추천한다.

GitHub DDoS 공격당함

 지난 2018년 2월 28일, GitHubDistributed Denial-of-Service(a.k.a. DDoS) 공격을 당해 약 10분 정도 서비스가 멈췄었다. 이 공격은 memcached를 이용한 공격으로 중국의 0kee team이 찾은 Deluge라는 기법을 이용한 공격이었다.
 Deluge는 다른 서버에 설치된 memcached에 데이터를 요청할 때 source IP를 목표가 되는 서버의 IP로 수정하여 보내, memcached 서버가 목표가 된 서버로 데이터를 보내게 만드는 공격이다.
 이런 부류의 공격을 IP spoofing이라고 하는데, 이는 Internet protocol(a.k.a. IP)OSI 7 layer에서 말하는 session layer에 관한 부분이 없기 때문에 생기는 근본적인 취약점을 이용한 것이기 때문에, 네트워크 프로토콜을 IP 위에 올린다면, 프로토콜을 작성하는 차원에서 세션 처리를 신경 쓰지 않았다면 근본적으로 막을 방법은 없다.
 IP spoofing 자체는 흔하게 사용되는 공격법이지만 memcached를 사용하는 Deluge는 그중에서도 큰 획을 그었다. 단순히 GitHub을 공격했기 때문이 아니라 적은 패킷으로 많은 데이터를 공격하게 할 수 있기 때문이다. 이 비율을 bandwidth amplification factor라고 하는데 Deluge는 지금까지 알려진 IP spoofing 공격 중에서 가장 높다.