GN⁺: AWS에서 내 온프레미스 서비스로의 연결을 차단함
(consulting.m3047.net)- 1989년 이전에는 대중이 인터넷에 접근할 수 없었음. 정부, 군대, 연구/교육 기관에만 개방된 대규모 네트워크가 있었음
- AOL, Compuserve 등의 서비스가 등장하여 초기 클라우드 네이티브의 전신이 됨
- 1995년 NSFNet이 백본에 대한 대중 접근을 차단함. 상업용 인터넷 구축을 위한 조치였음
- 2000년경 대규모 도태가 발생했고, 생존한 모델은 광고와 사용자 행동 데이터 판매에 기반을 둠
- 현재 AI의 특징은 모든 접근 가능한 콘텐츠를 트레이닝 데이터로 사용하는 것임
오늘날의 상황
- 필자는 실험 및 편의상 AWS로부터의 자신의 온프레미스 서버 접근을 차단하고 있음
- 필자가 운영 중인 웹서비스, DNS서버, 이메일 등은 개인 사용자 대상임
- AWS의 크기가 너무 커서 방화벽 규칙 생성이 많아짐. 크롤러/스캐너 차단의 부수적 효과가 있음
- 대부분의 유명 리소스는 클라우드에 호스팅되어 있음
- 오픈소스가 권한없이 의도치 않은 용도로 전용되는 데이터 절도 문제도 존재함
정책으로 격상시키기
- 대형 클라우드 제공업체는 DNS, Whois 등의 도구로 포렌식에 유용한 정보를 공유해야 함
- 개별 IP에 대한 Whois, 역방향 DNS에 인코딩된 추가 정보 등이 필요함
- 현재 악용 패턴과 영향받는 주소 블록을 논의하는 "스톰 센터" 블로그도 운영해야 함
- SMTP는 SPF와 같은 추가적인 정보를 DNS TXT 레코드로 게시함
- 적절한 완화조치는 모든 당사자에게 도움이 되지만, 잘못 타겟팅된 완화조치는 그렇지 않음
- 이런 상황에 이르게 된 것은 부끄러운 일임. 확산된다면 인터넷의 발칸화로 이어질 것임
Hacker News 의견
- 주요 클라우드 제공업체들은 기계가 읽을 수 있는 IP 범위 목록을 게시함
- 인터넷에서 인프라를 공격하는 사람들이 매우 빠르게 나타남
- BGP를 통해 서브넷을 발표하자마자 포트 스캔 활동이 급증함
- 많은 사람들이 모든 IP 범위를 무차별적으로 스캔하는 것 같음
- 내부 웹 서비스를 인터넷에 공개하는 것은 충격적임
- VPN 같은 추가 보호 계층이 필요함
- SSH는 단일 바스천 호스트에서만 공개함
- VPN 계층을 추가하여 이를 제거하고 싶음
- Hetzner, Digital Ocean, Linode, OVH, Contabo를 차단함
- pfBlocker NG 또는 UFW 규칙을 사용하여 ASN을 차단할 수 있음
- Amazon 서버가 온프레미스 서버를 느리게 만들자 IP 범위를 차단함
- 스크립트를 작성하여 주기적으로 IP 범위를 다운로드하고 차단함
- AWS에서 실행되는 데스크톱을 차단할 수 있음
- 특정 IP를 화이트리스트에 추가할 수 있음
- 프록시나 VPN을 사용하여 차단을 우회할 수 있음
- 인터넷의 큰 부분을 차단하고 싶다면 이해할 수 있음
- 특정 서비스에 대해서만 차단함
- 공유 지식의 혜택을 믿음
- AWS 직원이지만, 핑 트래픽이 스푸핑되었다면 AWS가 출처인지 알 수 없음
- 문제의 요약이 필요함
- 데이터 스크래핑, DDOS 공격, 대역폭 문제, 보안 문제 중 무엇인지 명확하지 않음
- 클라우드 간 네트워킹이 필요한 서버를 운영함
- 클라우드 서비스에서 들어오는 것은 봇, 스캐너, 스크래퍼뿐임
- 중국의 대형 ISP를 차단함
- 인바운드 연결을 차단하고 아웃바운드 연결을 유지하는 것이 도전 과제임
- DDoS와 대형 기술 회사의 봇으로 인해 문제가 심각해짐
- CIDR 집계와 데이터 센터 ISP의 속도 제한을 사용함
- 모든 IP에 대해 합리적인 제한을 설정함