AWS에서 내 온프레미스 서비스로의 연결을 차단함

 (consulting.m3047.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 공개 인터넷이 대형 클라우드 사업자 중심의 분절된 생태계로 갈라질 수 있으며, AWS발 온프레미스 접속 차단은 그 흐름을 보여주는 운영 사례임
  • 차단 대상은 주로 AWS 안의 클라이언트가 온프레미스 서비스에 여는 TCP 연결 시도이고, 로컬 클라이언트가 AWS 호스팅 서비스로 나가는 접속은 계속 가능함
  • 운영 중인 온프레미스 서비스는 웹, Trualias 데모, DNS, SMTP이며, DNS는 UDP와 TCP fallback 및 제한적인 보안 텔레메트리 공개 접근을 제공함
  • AWS 차단은 과도한 ping 트래픽과 abusive crawler/scanner 대응에서 시작됐고, 현재 abuse 대상 또는 출처로 관찰된 AWS 주소 공간 53개 CIDR을 관리함
  • 대형 클라우드 사업자가 reverse DNS, whois, DNS 네임스페이스, abuse 패턴 같은 포렌식 정보를 더 잘 공개하지 않으면 클라우드 내부 이용자는 불편을 거의 못 느끼는 분절이 강화될 수 있음

대형 클라우드가 만드는 분절 가능성

  • 대형 클라우드 사업자가 “too big to fail”한 bulletproof infrastructure가 되면 인터넷 분절을 직접 초래할 수 있음
  • 아직 완전히 현실화된 현상은 아니지만, 이미 시작됐거나 곧 나타날 수 있는 상태로 봄
  • 클라우드 네이티브 생태계는 실제 인터넷과 비교해 맞춤형 인프라를 갖고 있으며, 각 클라우드 서비스는 공통 아키텍처보다 구별되는 기능을 중심으로 구성됨
  • 많은 서비스가 특정 클라우드 안에서 자기완결적으로 동작하고, 일반 인터넷과의 투명한 상호운용성에는 장벽이 있음
  • 클라우드 네이티브 커뮤니티는 일반 인터넷을 외부 자원처럼 다루며, 인터넷 자체보다 특정 클라우드 사업자 생태계와 더 많이 상호작용함

공개 인터넷의 상업화 흐름

  • 1989년 이전 인터넷은 일반 공개 접근이 없었고, 정부·군·연구·교육 기관이 쓰는 사설 성격의 네트워크였음
  • NSF가 백본의 핵심을 관리했고, 초기 공개 접근은 비상업적 트래픽 조건 아래 허용됨
    • 상업 서비스 자체가 금지된 것은 아니었지만, NSFNet 백본을 지나는 트래픽은 광고나 유료 서비스 트래픽이 아니어야 했음
  • 상업 사업자들이 별도의 상업 인터넷을 구축했고, 1995년 NSFNet은 공개 접근을 비활성화함
  • 2000년 전후의 대규모 도태 이후에는 사용자 행동 데이터 기반 광고와 사용자 행동 데이터 판매 모델이 살아남음
  • 현재의 AI 흐름에서는 접근 가능한 콘텐츠를 대량 수집하고 세탁해 모델 학습에 쓰는 점이 두드러지며, 큐레이션과 학습은 주로 클라우드에서, 점점 클라우드 사업자 자신에 의해 이뤄짐

온프레미스 서비스에서 AWS 연결 차단

  • 온프레미스 서버로 들어오는 AWS 접근을 대부분 비활성화하고 있음
  • 기술적으로는 주로 TCP 트래픽에 관심이 있으며, 초기 핸드셰이크로 클라이언트와 서버를 구분할 수 있음
    • AWS 안의 클라이언트가 온프레미스 서비스에 연결을 시도하는 것은 차단함
    • 로컬 네트워크의 클라이언트가 AWS에 호스팅된 서비스로 연결하는 것은 가능함
  • 로컬에서 인터넷에 공개된 여러 서비스를 운영함
    • 웹 서비스
    • Trualias 데모
    • DNS 서버
    • SMTP 이메일 서버
  • 수년간 no crawl 정책을 유지해 왔고, 제공 자산은 주로 인터넷상의 개인 이용자를 대상으로 함
  • DNS 서버는 UDP와 TCP fallback을 사용하며 제한적인 공개 보안 텔레메트리를 제공함
    • 예시 쿼리: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • 클라우드에서 실행되는 서비스에도 유용할 수 있지만, 운영에 의존하려면 먼저 연락하길 기대함

reverse DNS와 SMTP 예외

  • 웹 서비스만 문제라면 reverse DNS 조회 같은 다른 완화책을 쓸 수 있음
  • 클라우드 사업자는 reverse DNS를 부실하게 운영하는 경우가 많고, 이는 클라우드 안의 리소스가 일시적이라는 서사와 맞아떨어짐
  • AWS는 다른 많은 클라우드 사업자보다 reverse DNS를 더 잘하는 편이며, 인스턴스의 reverse DNS를 설정할 수 있다고 들었지만 직접 시도하지는 않았음
  • SMTP에는 예외를 둠
    • 특별히 문제가 심하지 않다면, 다른 서비스 연결은 차단하더라도 메일 서버 연결은 허용함
    • 기술적으로 정확한 reverse DNS 없이도 SMTP를 운영할 수 있지만, 실제로는 정확한 reverse DNS가 없으면 상대가 메일을 받아주지 않음
  • reverse DNS를 평가하면 SYN이 정당한 메일 서버에서 왔는지 초기 판단을 할 수 있음
    • 평판 서비스는 reverse DNS를 점수화할 수 있음
    • 임대형·일시적 리소스에 흔한 패턴이 존재함
  • reverse DNS의 존재 여부나 형태만으로도 주소가 클라우드 사업자에 속하는지 합리적으로 가늠할 수 있음

AWS 주소 차단이 시작된 이유

  • 일부 abusive 서비스의 식별 가능한 netblock을 차단하는 작업에서 출발했고, 이후 작은 호스팅 사업자를 선별 차단하는 개념 증명으로 이어짐
  • AWS의 경우 시작점은 과도한 ping 트래픽이었음
    • ping은 연결 없는 프로토콜이라 출발지를 위조할 수 있음
    • 위조된 ping 요청의 응답은 공격자가 아니라 위조된 실제 위치로 가게 됨
  • 끊임없는 ping 응답을 억제하려면 일시적 방화벽 규칙을 생성해야 하지만, Amazon 규모가 너무 커서 규칙 수가 많아짐
  • AWS 주소 범위를 수집하기 시작했고, 현재 abuse 대상이거나 abuse 출처로 관찰된 AWS 주소 공간을 대표하는 53개 CIDR을 갖고 있음
  • 때로는 그 두 배에 달하는 임시 방화벽 규칙도 관찰됨
  • “too big to fail” 클라우드 사업자에서 임대한 abusive crawler와 scanner를 막는 것은 좋은 부수효과이며, 웹 로그에서 사라져도 아쉽지 않음

클라우드 이용자가 겪는 영향

  • 인기 있는 리소스나 클라우드 배포 가능성이 있는 리소스 대부분은 GitHub에 호스팅되어 있음
  • 다른 리소스를 클라우드에 배포하는 사람은 스테이징에 사용할 자체 저장소를 유지해야 함
  • 저장소가 AWS에 있으면 더 이상 업데이트 확인이 불가능해짐
    • 데스크톱에서 확인해야 함
    • 사설 호스팅 리소스에서 확인해야 함
    • 별도 arrangement를 논의할 수 있음
  • 스마트폰, S3 버킷, EC2 인스턴스만 가진 상태를 “인터넷에 있다”고 보기는 어렵지만, 스마트폰에서는 그런 리소스에 접근할 수 있어야 함

데이터 도용 완화와 의도하지 않은 사용

  • 오픈소스 자료가 허락 없이 의도하지 않은 목적으로 전용되는 데이터 도용도 별도의 완화가 필요한 위협임
  • AWS 차단은 그런 완화책의 하나로도 작동함
  • cats, bunnies, birds 관련 자료도 완화책 맥락에서 함께 다뤄짐
    • cats와 bunnies는 관련 영상이 매우 많고 일부는 구매 가능하다는 이유로 등장함
    • birds는 OSI 2계층에서 더 효과적이며, IP datagram 전송 방법으로 RFC에 문서화돼 있음

대형 클라우드 사업자에게 필요한 공개 정보

  • 대형 클라우드 사업자는 지금보다 더 나은 포렌식 정보 배포 체계를 제공해야 함
  • DNS와 whois는 잠재적으로 유용한 정보를 배포하는 도구가 될 수 있음
  • 큰 사업자라면 자체 reverse DNS를 운영할 수 있어야 함
  • 개별 주소에 대한 whois, reverse DNS에 인코딩된 추가 정보, DNS 네임스페이스의 별도 공개 정보가 필요할 수 있음
  • 현재 abuse 패턴과 영향을 받는 주소 블록을 다루는 storm center blog도 가능한 방식임
  • SMTP에는 reverse DNS뿐 아니라 DNS TXT 레코드로 게시되는 SPF가 있음
  • 하나의 IP 주소만으로도 다음 질문에 답할 정보를 찾을 수 있어야 함
    • 해당 주소 뒤의 리소스가 ping을 보내는지
    • 얼마나 많은 ping을 보내는지
    • outbound TCP 연결을 만드는지
    • 어떤 서비스로 연결하는지
    • 누가 리소스를 제어하는지
    • 리소스가 공격받고 있는지
    • 어떤 종류의 공격인지
    • 인터넷의 다른 리소스가 어떤 완화를 제공하길 원하는지
  • 적절한 완화는 모두에게 도움이 되지만, 잘못 겨냥한 완화는 그렇지 않음

분절된 인터넷의 결과

  • 이런 방식이 확산되면 balkanized internet으로 이어질 수 있음
  • 대형 클라우드 사업자의 거품 안에서 온라인 생활을 하는 사람들은 불편을 대부분 알아차리지 못할 수 있음
  • 알아차리는 불편도 특정 클라우드 사업자를 선택한 탓으로 받아들일 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 주요 클라우드 제공자들은 모두 기계가 읽을 수 있는 IP 대역 목록을 공개하고 있음
    예: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... 등

    • 오늘 확인해 보진 않았지만, 예를 들어 Amazon의 JSON 파일은 실제 소유 여부와 별개로 사실상 3.0.0.0/8을 쓴다는 점을 가려버림
      “Amazon의 거대한 JSON 목록을 차단해 보자” 같은 게임은 안 할 생각이고, 규칙은 53개뿐임. 어느 정도 부작용은 감수할 수 있고, AWS에 있는 사이트들도 잘 접속됨

  • 요즘 인터넷에서는 인프라를 공개하자마자 공격성 트래픽이 붙는 속도가 미쳤음
    최근 애니캐스트 구성을 위해 /23 서브넷 하나를 BGP로 광고했는데, 라우트가 올라가고 라우터로 트래픽이 흐르자마자 tcpdump가 대역 내 모든 IP에 대한 포트 스캔으로 폭주함
    물론 라우트 자체 때문은 아니고, 많은 주체가 모든 IP 대역을 무차별·상시로 스캔하는 듯함. 이 대역은 수년간 광고되지 않았으니 누군가의 활성 서버 목록에 있었던 것도 아님
    GitLab 같은 내부 웹 서비스를 아직도 인터넷에 그대로 노출하는 건 충격적임. 적어도 VPN 같은 추가 보호 계층을 둬서 공개 인터넷에서 서비스가 발견되지 않게 해야 한다고 봄
    공개 접근 가능한 것은 단일 배스천 호스트의 SSH뿐이고, 이것도 나중에는 VPN 계층을 얹어 없애고 싶음

    • 기대치를 다시 조정하는 편이 나음. 포트 스캔은 별것 아니고, 공격이라고 부르기도 애매한 인터넷 배경 복사 같은 것임
      우주에 가면 배경 복사가 있듯, 인터넷에 가면 인터넷의 배경 복사가 있음. 취약한 서비스를 돌리지 않는다면 이런 포트 스캔은 한 달에 바나나 하나 더 먹는 정도의 위험과 비슷함
      콘솔에서 직접 보고 있으니 거슬리는 것뿐임. 비행기에 과민한 가이거 계수기를 들고 타면 놀랄 수 있지만, 모르고 있으면 해가 되지 않는 것과 같음
      내부 서비스를 인터넷에 노출하는 것에는 나도 놀라는데, 이유는 두 가지임. 대부분 프로그램의 인증 시스템을 신뢰하지 않고, 어떤 내부 서비스를 쓰는지 외부에 알리고 싶지 않기 때문임. 순수 기술 보안보다 사생활에 가까운 이유도 있음
      반대로 인터넷에 있어야 하고, 강한 정문을 갖췄거나 충분히 샌드박스된다고 믿는 것들은 하루 종일 인터넷에 있어도 됨
      포트 스캔은 도시를 돌아다니며 어느 집 불이 켜져 있는지 적는 것의 인터넷판임. 좀 스토커 같을 수는 있지만 공개 정보임
      참고로 ssh -w는 VPN 터널 인터페이스를 만들지만, 실제 VPN 제품처럼 나머지 설정을 자동 구성해 주지는 않음
    • 그 위에 VPN 계층을 추가하고 싶다면 어떤 VPN 소프트웨어를 쓸지 궁금함. 개인적으로는 OpenSSH만큼 신뢰할 만하다고 느낀 걸 못 찾았음
    • 잘못 설정된 공개 SSH는 절대 올리면 안 됨. 문자 그대로 몇 초 만에 털릴 수 있음
      인터넷은 점점 Cyberpunk의 blackwall 뒤에서 벌어지는 일처럼 느껴짐
    • “요즘”만의 일은 아님. 25년 전에도 노출된 웹 서버를 스크립트나 봇이 계속 확인하는 건 꽤 흔했고, 웹 접근 로그에서 자주 보였음
      방화벽의 거부 접근 로그를 켜면 알려진 포트와 알려지지 않은 포트에 대한 시도가 영구적으로 흘러들어왔음
      무언가를 노출한다면, 깊숙이 숨긴 웹 구성 요소라 해도 그것이 데이터와 인프라로 들어가는 문이 되지 않게 해야 함
      그때와 조금 달라진 건 트래픽의 출처와, 받아야 할지 차단해야 할지 판단하는 기준임. 합법 서버·서비스, 최종 사용자 쪽 프록시, 클라우드 제공자, 크롤러 수가 크게 늘어났음
    • 이건 IPv4에 특화된 문제처럼 들림. IPv6 전용으로 가면 악성 행위자에게 IP 스캔이 사실상 비현실적이지 않을까?

  • 정말 아쉬운 일임. 그렇게 하면 본인의 콘텐츠가 검색 엔진에 전혀 안 나오고, Marginalia에도 안 잡히며, Wayback Machine에도 저장되지 않을 위험이 있음
    원래 그걸 원한다면 모든 클라우드와 데이터센터를 차단하는 게 맞을 수 있음. 심지어 어떤 소규모 ISP가 CGNAT 게이트웨이를 어디서 돌리느냐에 따라 그 ISP 이용자까지 막을 수도 있음. 가능성은 낮지만 불가능하진 않음
    글에서 실제 남용으로 언급된 것은 스푸핑된 출발지 주소의 ping뿐으로 보임. 스푸핑된 ping 패킷이 AWS에서 왔는지는 알 수 없음. 출발지 주소는 스푸퍼가 응답을 보내길 원하는 주소이지, 스푸퍼의 주소가 아니기 때문임
    훨씬 덜 침습적인 완화책은 ping을 초당 10개 정도로 속도 제한하는 것임
    인터넷이 발칸화되고 있긴 하지만, 주된 원인은 IP 대역 차단보다는 광고·데이터 수익을 위해 소셜 미디어가 사일로화하고, AI 학습 데이터에서 수익을 뽑아내려는 흐름임. Reddit/Google 독점 계약 같은 사례가 여기에 가까움
    몇 번의 ping 때문에 특정 제공자를 차단하면서 IP 연결성이 발칸화된다고 불평하는 사고방식은 이해하기 어려움. 발칸화를 만드는 쪽은 차단하는 쪽임

    • 요즘 검색 엔진에는 거대한 광고 범벅 콘텐츠 농장과 Wikipedia, Stack Overflow, 대형 뉴스·미디어 사이트, YouTube 같은 대형 사이트 말고는 거의 나오지 않음
      개인 블로그나 작은 취미 사이트가 검색 결과에 보인 지 꽤 오래됐음
      Wikipedia나 Stack Overflow가 필요하면 그 사이트에서 직접 검색하면 됨. “늘 보이는 후보들”을 제외하고 더 긴 꼬리의 콘텐츠를 볼 수 있는 옵션이 있었으면 함
    • 발칸화를 일으킬 수 있는 조치를 “강제로” 하게 된 데 대한 한탄으로 보임
      다만 전체 톤은 모기 물린 일을 장대한 역사 서사로 엮는 느낌에 가까움
    • 작은 ISP라도 왜 자기 IP 공간이 아닌 곳에서 CGNAT 게이트웨이를 돌리겠음?
      클라우드에서 CGNAT 게이트웨이를 운영하면 문제가 많을 것임. 가입자들이 주거용 IP가 아니게 되니 Netflix 같은 서비스를 못 볼 수도 있고, Cloudflare나 Google에서 봇 방지 CAPTCHA를 더 자주 마주칠 가능성도 큼
      실제로 알려진 사례가 있는지 궁금함
    • “검색 엔진에 나오지 않는 것”을 단점이나 손해로 보는 전제가 무엇인지 궁금함. 그 관점을 공유하진 않지만 이해해 보려는 중임
    • 글쓴이는 오래전부터 크롤링 금지 정책을 유지해 왔다고 말해 왔음. 아마 신경 쓰지 않을 것이고, Google의 엔시티피케이션을 보면 오히려 맞는 선택일 수도 있음

  • Hetzner, DigitalOcean, Linode, OVH, Contabo는 한동안 차단해 왔음
    pfBlocker NG에서 ASN 차단으로 할 수도 있고, UFW 규칙으로도 가능함: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • 이렇게 통째로 막으면 정상 조직이 사이트에 접근하지 못할 수 있음. 무언가를 판매하는 사이트라면 문제가 될 수 있음
      예를 들어 어떤 조직이 클라우드 제공자 위에서 WireGuard나 다른 VPN 솔루션을 직접 운영하고, 사람들이 거기를 통해 접속하면 나가는 IP가 클라우드 제공자 IP로 보이게 됨
    • 요즘 크고 작은 기업들은 클라우드에 출구 노드를 둔 VPN이나 유사 솔루션을 많이 씀. 이런 차단은 결국 업무용 컴퓨터에서 웹사이트에 접근하지 못하게 만들 수 있음
    • 이런, 왜 Hetzner까지?
    • 현실 세계처럼 상호적이어야 한다고 봄. 누군가 제공자를 차단하면, 그 제공자도 되돌려 차단할 수 있어야 함
      자동화까지 붙일 수도 있음. 그래야 공정하고 각 당사자가 무슨 일이 벌어지는지 알 수 있음. 아니면 이런 모래상자식 장난 대신 진짜 총을 쓰든가

  • 처음 생각한 건 AWS에서 돌아가는 실제 데스크톱, 특히 Amazon Workspaces 같은 서비스가 막힐 수 있다는 점이었음
    다만 그런 서비스의 IP 공간도 공개 문서화되어 있는 듯해서, 필요하면 해당 IP를 별도로 허용할 수 있음
    그렇다 해도 프록시나 VPN을 쓰면 이런 차단을 우회하는 건 아주 쉬움

    • 당신에게는 쉬울 수 있음. 하지만 요즘 서버리스로 몰려가는 많은 사람들을 보면, 기술자 대부분도 자기 네트워킹이나 인프라를 직접 다루고 싶어 하지 않는 듯함

  • 오래전에 Amazon 서버 수십 대가 우리 온프레미스 서버를 느리게 만들기 시작해서 이렇게 했음
    어떤 SSO 시도 같은 것이었을지도 모르지만 끝내 완전히 추적하진 못했음. 그냥 주기적으로 Amazon IP 대역 목록을 내려받아 전부 차단하는 스크립트를 작성하고 넘어갔음

  • 이해는 됨. 내가 만든 것에서 인터넷의 큰 영역을 벽으로 막고 싶다면 나도 같은 일을 했을 것임. 국가 전체를 차단하는 것과 크게 다르지 않음
    소음을 줄이고 “작은 친구 그룹”만 허용하고 싶은 욕구도 이해됨
    다만 나는 도메인 전체가 아니라 특정 서비스에만 그렇게 함. Mumble 서버는 친구들이 있는 3~4개 국가에만 열고, 클라우드 제공자는 제외함. 기술 블로그는 전 세계 누구나 볼 수 있게 둠
    나는 공유 지식이 모두에게 이롭다는 쪽에 확고히 서 있음. 300보드 C64 모뎀의 모뎀 초기화 문자열에 대한 내 메모가 단 한 사람에게라도 도움이 된다면, 그 사람은 내가 겪은 고통을 반복하지 않을 것이고 세상은 조금 더 나아질 것임
    여러 이유로 그런 욕구가 생기는 건 이해함. 괜찮음. 각자 알아서 하면 됨

    • 내가 쓴 Zen InterSLIP Dialing Script는 문자 그대로 전 세계를 돌았음
      Amazon은 무시하기엔 너무 큼. ICMP와 SYN 트래픽 중 많은 것이 쓰레기라는 건 이해함. 나도 차단을 돕고 싶고 실제로 완화책도 기본적으로 갖춰 두고 있음
      문제는 Amazon이 “규모 있게” 내 완화책을 건드리기 때문에 골칫거리라는 점임. Amazon은 쭉정이와 알곡을 가려내는 데 도움을 주지 않음. “ping 문제에 대해 PCAP을 보내라”는 식임
      Amazon에 자료를 보내고 아무 응답도 못 들으면 배울 게 없음. 좋은 트래픽도 나쁜 트래픽도, 그들을 공격하는 스푸핑 트래픽도 굳이 필요하지 않음
      그들이 내가 그들을 돕도록 도울 생각이 없다면, 전부 필요 없음. 그냥 내 삶을 단순하게 유지하는 중임

  • 이런 걸 보면 예전 인터넷이 그리워짐. 상업화 이전의 인터넷이 얼마나 멋졌는지 설명하기 정말 어려움
    그 결과가 이렇게 될 거라고 정확히 맞혔다는 씁쓸한 즐거움은 잃어버린 것에 대한 보상으로 전혀 충분하지 않음

    • 아, 그렇지. 향수 어린 헛소리임. 인터넷은 처음부터 돈 얘기였음

  • AWS는 DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, 심지어 Google 같은 곳에 비하면 보이스카우트 수준임
    특히 DigitalOcean은 “사이버보안” 커뮤니티에 마케팅한 것이 끔찍한 실수였다고 봄

    • 사실 글을 읽어보면 “개념 증명으로 일부 소규모 호스팅 제공자를 차단했다”고 적었는데, 그게 바로 DigitalOcean임. 당신이 말한 이유 때문임

  • 이해관계 고지: AWS가 현재 내 고용주임
    뭔가 뻔한 걸 놓친 것일 수도 있는데, 글쓴이가 ping 트래픽이 스푸핑됐다고 믿는다면 어떻게 AWS가 출처라고 알 수 있음?

    • AWS는 엄청난 양의 남용, 조악한 스크래퍼와 크롤러의 출처라는 평판이 매우 나쁨. 나쁜 크롤러와 실제 공격은 구분하기 어려울 때도 많음
      경험상 AWS에서 압도적인 트래픽이 나온 경우를 너무 많이 봤고, 어떤 경우에는 같은 해결책, 즉 AWS 전체 차단까지 갔음
      AWS가 신경을 안 쓰는 건지, 대응이 느린 건지는 모르겠음. 신고가 너무 어려운 것일 수도 있음
      놓친 뻔한 점은 이것임. AWS는 “나쁜” 트래픽의 거대한 출처이고, 오작동하는 고객을 중단시키기는 너무 어려운 반면 악성 행위자가 말도 안 되는 용량을 빌리기는 너무 쉬움
      GCP나 Azure가 같은 수준의 미친 트래픽 출처가 되는 건 거의 본 적이 없음
답변달기