Chặn kết nối từ AWS đến dịch vụ on-premises của tôi
(consulting.m3047.net)- Internet công cộng có thể bị chia tách thành một hệ sinh thái phân mảnh xoay quanh các nhà cung cấp đám mây lớn, và việc chặn truy cập từ AWS đến on-premises là một ví dụ vận hành cho xu hướng đó
- Đối tượng bị chặn chủ yếu là các nỗ lực kết nối TCP mà client trong AWS mở đến dịch vụ on-premises; còn kết nối đi từ client cục bộ đến dịch vụ hosted trên AWS vẫn có thể tiếp tục
- Các dịch vụ on-premises đang vận hành gồm web, demo Trualias, DNS và SMTP; DNS cung cấp UDP, TCP fallback và quyền truy cập công khai vào telemetry bảo mật ở mức hạn chế
- Việc chặn AWS bắt đầu từ lưu lượng ping quá mức và phản ứng với crawler/scanner lạm dụng; hiện đang quản lý 53 CIDR trong không gian địa chỉ AWS từng được quan sát là mục tiêu hoặc nguồn abuse
- Nếu các nhà cung cấp đám mây lớn không công khai tốt hơn các thông tin pháp chứng như reverse DNS, whois, namespace DNS và mẫu abuse, sự phân mảnh mà người dùng bên trong đám mây hầu như không cảm thấy bất tiện có thể sẽ mạnh lên
Khả năng phân mảnh do các đám mây lớn tạo ra
- Nếu các nhà cung cấp đám mây lớn trở thành bulletproof infrastructure “too big to fail”, họ có thể trực tiếp gây ra sự phân mảnh Internet
- Đây chưa phải là hiện tượng đã hoàn toàn thành hiện thực, nhưng được xem là trạng thái đã bắt đầu hoặc có thể sớm xuất hiện
- Hệ sinh thái cloud native có hạ tầng tùy biến so với Internet thực tế, và mỗi dịch vụ đám mây được cấu thành quanh các tính năng khác biệt hơn là một kiến trúc chung
- Nhiều dịch vụ hoạt động tự khép kín trong một đám mây cụ thể, và có rào cản đối với khả năng tương tác minh bạch với Internet thông thường
- Cộng đồng cloud native đối xử với Internet thông thường như tài nguyên bên ngoài, và tương tác với hệ sinh thái của một nhà cung cấp đám mây cụ thể nhiều hơn là với chính Internet
Dòng chảy thương mại hóa Internet công cộng
- Trước năm 1989, Internet không có truy cập công khai phổ thông, mà là mạng mang tính riêng tư được các cơ quan chính phủ, quân đội, nghiên cứu và giáo dục sử dụng
- NSF quản lý phần lõi của backbone, và truy cập công khai ban đầu được cho phép với điều kiện là lưu lượng phi thương mại
- Bản thân dịch vụ thương mại không bị cấm, nhưng lưu lượng đi qua backbone NSFNet không được là lưu lượng quảng cáo hoặc dịch vụ trả phí
- Các nhà khai thác thương mại đã xây dựng Internet thương mại riêng, và đến năm 1995 NSFNet vô hiệu hóa truy cập công khai
- Sau đợt đào thải quy mô lớn quanh năm 2000, mô hình quảng cáo dựa trên dữ liệu hành vi người dùng và bán dữ liệu hành vi người dùng là những mô hình sống sót
- Trong làn sóng AI hiện nay, điểm nổi bật là thu thập hàng loạt nội dung có thể truy cập và “rửa” chúng để dùng cho huấn luyện mô hình; việc tuyển chọn và huấn luyện chủ yếu diễn ra trên đám mây, và ngày càng do chính các nhà cung cấp đám mây thực hiện
Chặn kết nối AWS tại dịch vụ on-premises
- Hầu hết truy cập từ AWS vào máy chủ on-premises đang bị vô hiệu hóa
- Về mặt kỹ thuật, mối quan tâm chủ yếu là lưu lượng TCP, và có thể phân biệt client với server qua handshake ban đầu
- Chặn việc client trong AWS cố gắng kết nối đến dịch vụ on-premises
- Cho phép client trong mạng cục bộ kết nối đến dịch vụ được host trên AWS
- Đang vận hành cục bộ nhiều dịch vụ công khai trên Internet
- Dịch vụ web
- Demo Trualias
- Máy chủ DNS
- Máy chủ email SMTP
- Chính sách no crawl đã được duy trì trong nhiều năm, và tài sản được cung cấp chủ yếu nhắm đến người dùng cá nhân trên Internet
- Máy chủ DNS sử dụng UDP và TCP fallback, đồng thời cung cấp telemetry bảo mật công khai ở mức hạn chế
- Truy vấn ví dụ:
dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt - Có thể hữu ích cả với các dịch vụ chạy trên đám mây, nhưng nếu muốn phụ thuộc vào nó trong vận hành thì được kỳ vọng là hãy liên hệ trước
- Truy vấn ví dụ:
Reverse DNS và ngoại lệ SMTP
- Nếu vấn đề chỉ là dịch vụ web, có thể dùng các biện pháp giảm thiểu khác như tra cứu reverse DNS
- Các nhà cung cấp đám mây thường vận hành reverse DNS kém, và điều này khớp với câu chuyện rằng tài nguyên trong đám mây là tạm thời
- AWS làm reverse DNS tốt hơn nhiều nhà cung cấp đám mây khác, và nghe nói có thể thiết lập reverse DNS cho instance, nhưng người viết chưa trực tiếp thử
- Có ngoại lệ cho SMTP
- Nếu vấn đề không đặc biệt nghiêm trọng, thì dù chặn kết nối đến các dịch vụ khác vẫn cho phép kết nối đến máy chủ mail
- Về mặt kỹ thuật có thể vận hành SMTP mà không có reverse DNS chính xác, nhưng trên thực tế nếu không có reverse DNS chính xác thì bên kia sẽ không nhận mail
- Đánh giá reverse DNS cho phép đưa ra phán đoán ban đầu về việc SYN có đến từ một máy chủ mail hợp lệ hay không
- Dịch vụ uy tín có thể chấm điểm reverse DNS
- Có những mẫu thường gặp ở tài nguyên thuê hoặc tạm thời
- Chỉ với sự tồn tại hay hình thức của reverse DNS cũng có thể ước đoán hợp lý liệu địa chỉ có thuộc về một nhà cung cấp đám mây hay không
Vì sao bắt đầu chặn địa chỉ AWS
- Bắt đầu từ việc chặn các netblock có thể nhận diện của một số dịch vụ abusive, rồi sau đó dẫn đến một proof of concept về việc chặn có chọn lọc các nhà cung cấp hosting nhỏ
- Với AWS, điểm khởi đầu là lưu lượng ping quá mức
- Ping là giao thức không kết nối nên có thể giả mạo nguồn gửi
- Phản hồi cho yêu cầu ping bị giả mạo sẽ đi đến vị trí thực bị giả mạo, chứ không phải kẻ tấn công
- Để kìm bớt các phản hồi ping liên tục, cần tạo các quy tắc firewall tạm thời, nhưng quy mô Amazon quá lớn nên số lượng quy tắc tăng lên nhiều
- Bắt đầu thu thập dải địa chỉ AWS, và hiện có 53 CIDR đại diện cho không gian địa chỉ AWS từng được quan sát là mục tiêu hoặc nguồn abuse
- Đôi khi cũng quan sát thấy số quy tắc firewall tạm thời nhiều gấp đôi con số đó
- Việc chặn crawler và scanner abusive thuê từ nhà cung cấp đám mây “too big to fail” là một tác dụng phụ tốt, và cũng không tiếc nếu chúng biến mất khỏi log web
Tác động mà người dùng đám mây gặp phải
- Phần lớn tài nguyên phổ biến hoặc có khả năng được triển khai lên đám mây đều được host trên GitHub
- Người triển khai các tài nguyên khác lên đám mây cần duy trì kho lưu trữ riêng để dùng cho staging
- Nếu kho lưu trữ nằm trên AWS, sẽ không thể kiểm tra cập nhật được nữa
- Phải kiểm tra từ desktop
- Phải kiểm tra từ tài nguyên host riêng
- Có thể thảo luận arrangement riêng
- Khó có thể xem trạng thái chỉ có smartphone, bucket S3 và instance EC2 là “đang ở trên Internet”, nhưng từ smartphone vẫn phải có thể truy cập những tài nguyên như vậy
Giảm thiểu đánh cắp dữ liệu và việc sử dụng ngoài ý muốn
- Đánh cắp dữ liệu, tức việc tài liệu nguồn mở bị chuyển dụng cho mục đích ngoài ý muốn mà không được phép, cũng là một mối đe dọa cần biện pháp giảm thiểu riêng
- Chặn AWS cũng hoạt động như một trong các biện pháp giảm thiểu đó
- Tài liệu liên quan đến cats, bunnies, birds cũng được xử lý cùng trong bối cảnh biện pháp giảm thiểu
- cats và bunnies xuất hiện vì có rất nhiều video liên quan và một số có thể mua được
- birds hiệu quả hơn ở tầng 2 OSI, và được ghi lại trong RFC như một phương pháp truyền IP datagram
Thông tin công khai mà các nhà cung cấp đám mây lớn cần có
- Các nhà cung cấp đám mây lớn cần cung cấp cơ chế phân phối thông tin pháp chứng tốt hơn hiện nay
- DNS và whois có thể là công cụ phân phối thông tin tiềm năng hữu ích
- Nếu là nhà cung cấp lớn, họ phải có khả năng vận hành reverse DNS của riêng mình
- Có thể cần whois cho từng địa chỉ, thông tin bổ sung được mã hóa trong reverse DNS, và thông tin công khai riêng trong namespace DNS
- Storm center blog xử lý các mẫu abuse hiện tại và các block địa chỉ bị ảnh hưởng cũng là một cách khả thi
- Với SMTP, ngoài reverse DNS còn có SPF được công bố dưới dạng bản ghi DNS TXT
- Chỉ với một địa chỉ IP, phải có thể tìm được thông tin trả lời các câu hỏi sau
- Tài nguyên phía sau địa chỉ đó có gửi ping hay không
- Gửi bao nhiêu ping
- Có tạo kết nối TCP outbound hay không
- Kết nối đến dịch vụ nào
- Ai kiểm soát tài nguyên đó
- Tài nguyên đó có đang bị tấn công hay không
- Đó là loại tấn công nào
- Các tài nguyên khác trên Internet muốn được cung cấp kiểu giảm thiểu nào
- Giảm thiểu phù hợp giúp ích cho tất cả mọi người, nhưng giảm thiểu nhắm sai mục tiêu thì không
Hệ quả của Internet phân mảnh
- Nếu cách làm này lan rộng, nó có thể dẫn đến một balkanized internet
- Những người sống đời sống trực tuyến trong bong bóng của các nhà cung cấp đám mây lớn có thể hầu như không nhận ra bất tiện
- Ngay cả bất tiện mà họ nhận ra cũng có thể được xem là do họ đã chọn một nhà cung cấp đám mây cụ thể
1 bình luận
Ý kiến trên Hacker News
Tất cả các nhà cung cấp đám mây lớn đều công bố danh sách dải IP có thể đọc bằng máy
Ví dụ: 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... v.v.
Tôi không định chơi trò kiểu “hãy chặn danh sách JSON khổng lồ của Amazon”, và chỉ có 53 quy tắc thôi. Có thể chấp nhận một mức tác dụng phụ nào đó, và các site nằm trên AWS vẫn truy cập tốt
Trên Internet ngày nay, tốc độ mà lưu lượng có tính tấn công bám vào ngay khi công khai hạ tầng là điên rồ
Gần đây, để cấu hình anycast, tôi đã quảng bá một subnet /23 qua BGP; ngay khi route được đưa lên và lưu lượng bắt đầu chảy về router, tcpdump đã bùng nổ vì các lượt quét cổng tới mọi IP trong dải
Tất nhiên không phải do bản thân route, mà có vẻ nhiều bên đang quét bừa bãi và liên tục mọi dải IP. Dải này đã không được quảng bá trong nhiều năm, nên cũng không phải từng nằm trong danh sách máy chủ đang hoạt động của ai đó
Việc vẫn để lộ nguyên các dịch vụ web nội bộ như GitLab ra Internet thật sự gây sốc. Ít nhất nên có một lớp bảo vệ bổ sung như VPN để dịch vụ không bị phát hiện từ Internet công cộng
Thứ duy nhất có thể truy cập công khai là SSH của một bastion host duy nhất, và sau này tôi cũng muốn thêm lớp VPN để loại bỏ cả cái đó
Giống như ra ngoài vũ trụ thì có bức xạ nền, lên Internet thì có bức xạ nền của Internet. Nếu bạn không chạy các dịch vụ dễ tổn thương, các lượt quét cổng kiểu này có mức rủi ro tương tự như mỗi tháng ăn thêm một quả chuối
Nó chỉ gây khó chịu vì bạn đang nhìn trực tiếp trên console. Giống như mang một máy đếm Geiger quá nhạy lên máy bay thì có thể giật mình, nhưng nếu không biết thì cũng không gây hại
Tôi cũng ngạc nhiên trước việc đưa dịch vụ nội bộ ra Internet, vì hai lý do. Tôi không tin hệ thống xác thực của đa số chương trình, và không muốn cho bên ngoài biết mình dùng những dịch vụ nội bộ nào. Cũng có lý do thiên về quyền riêng tư hơn là bảo mật kỹ thuật thuần túy
Ngược lại, những thứ cần ở trên Internet và có cửa chính đủ mạnh, hoặc được tin là đủ sandbox, thì có thể ở trên Internet cả ngày
Quét cổng là phiên bản Internet của việc đi quanh thành phố ghi lại nhà nào đang bật đèn. Có thể hơi giống stalker, nhưng đó là thông tin công khai
Nhân tiện,
ssh -wtạo giao diện tunnel VPN, nhưng không tự động cấu hình phần còn lại như các sản phẩm VPN thực sựInternet ngày càng có cảm giác như những gì diễn ra phía sau blackwall trong Cyberpunk
Nếu bật log các truy cập bị firewall từ chối, các nỗ lực nhắm vào cả cổng đã biết lẫn cổng không rõ sẽ chảy vào liên tục
Nếu bạn để lộ thứ gì đó, dù là một thành phần web được giấu rất sâu, thì cũng phải bảo đảm nó không trở thành cánh cửa dẫn vào dữ liệu và hạ tầng
Điều hơi khác so với lúc đó là nguồn gốc lưu lượng, và tiêu chí để quyết định nên cho qua hay chặn. Số lượng server/dịch vụ hợp pháp, proxy phía người dùng cuối, nhà cung cấp đám mây và crawler đã tăng mạnh
Thật sự rất đáng tiếc. Làm như vậy thì nội dung của bạn có nguy cơ hoàn toàn không xuất hiện trên công cụ tìm kiếm, cũng không được Marginalia bắt được, và cũng không được lưu vào Wayback Machine
Nếu ngay từ đầu đó là điều bạn muốn thì có lẽ chặn tất cả cloud và trung tâm dữ liệu là hợp lý. Thậm chí tùy một ISP nhỏ nào đó chạy cổng CGNAT ở đâu, bạn còn có thể chặn cả người dùng của ISP đó. Khả năng thấp, nhưng không phải không thể
Thứ được nhắc đến trong bài như hành vi lạm dụng thực tế dường như chỉ là ping với địa chỉ nguồn bị giả mạo. Không thể biết các gói ping bị giả mạo đó có đến từ AWS hay không, vì địa chỉ nguồn là địa chỉ mà kẻ giả mạo muốn phản hồi được gửi tới, chứ không phải địa chỉ của kẻ giả mạo
Một biện pháp giảm thiểu ít xâm lấn hơn nhiều là giới hạn tốc độ ping ở khoảng 10 gói mỗi giây
Internet đúng là đang bị Balkan hóa, nhưng nguyên nhân chính không phải là chặn dải IP, mà là việc mạng xã hội bị silo hóa để kiếm tiền từ quảng cáo/dữ liệu, và xu hướng vắt lợi nhuận từ dữ liệu huấn luyện AI. Những trường hợp như thỏa thuận độc quyền Reddit/Google gần với điều này hơn
Thật khó hiểu lối suy nghĩ vừa chặn một nhà cung cấp cụ thể chỉ vì vài lần ping, vừa phàn nàn rằng kết nối IP đang bị Balkan hóa. Bên tạo ra Balkan hóa chính là bên chặn
Đã khá lâu rồi tôi không thấy blog cá nhân hay trang sở thích nhỏ xuất hiện trong kết quả tìm kiếm
Nếu cần Wikipedia hay Stack Overflow thì có thể tìm trực tiếp trên các trang đó. Ước gì có tùy chọn loại trừ “những ứng viên lúc nào cũng hiện ra” để xem được phần nội dung đuôi dài hơn
Tuy nhiên giọng điệu tổng thể giống cảm giác biến chuyện bị muỗi đốt thành một thiên sử thi hoành tráng hơn
Vận hành cổng CGNAT trên cloud hẳn sẽ có nhiều vấn đề. Người đăng ký sẽ không còn dùng IP dân cư, nên có thể không xem được các dịch vụ như Netflix, và nhiều khả năng sẽ thường xuyên gặp CAPTCHA chống bot hơn từ Cloudflare hoặc Google
Tôi tò mò không biết có trường hợp thực tế nào đã được biết đến không
Hetzner, DigitalOcean, Linode, OVH, Contabo thì tôi đã chặn một thời gian rồi
Có thể làm bằng chặn ASN trong pfBlocker NG, hoặc bằng quy tắc UFW: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...
Ví dụ một tổ chức tự vận hành WireGuard hoặc giải pháp VPN khác trên một nhà cung cấp cloud, và mọi người truy cập qua đó, thì IP đi ra sẽ trông như IP của nhà cung cấp cloud
Thậm chí có thể gắn thêm tự động hóa. Như vậy mới công bằng và mỗi bên đều biết chuyện gì đang xảy ra. Còn không thì thay vì mấy trò nghịch kiểu hộp cát này, dùng súng thật luôn đi
Điều đầu tiên tôi nghĩ đến là các desktop thực sự chạy trên AWS, đặc biệt là các dịch vụ như Amazon Workspaces, có thể bị chặn
Tuy nhiên dường như không gian IP của các dịch vụ đó cũng được công khai trong tài liệu, nên nếu cần thì có thể cho phép riêng các IP đó
Dù vậy, nếu dùng proxy hoặc VPN thì việc vượt qua kiểu chặn này rất dễ
Từ lâu trước đây, hàng chục máy chủ Amazon bắt đầu làm chậm máy chủ on-premises của chúng tôi, nên chúng tôi đã làm như vậy
Có thể đó là thứ gì đó như một nỗ lực SSO nào đó, nhưng rốt cuộc chúng tôi không truy ra hoàn toàn. Chỉ viết một script định kỳ tải danh sách dải IP của Amazon xuống rồi chặn hết và bỏ qua
Tôi hiểu. Nếu tôi muốn dựng tường ngăn một phần lớn Internet khỏi thứ mình tạo ra thì tôi cũng sẽ làm vậy. Không khác mấy so với chặn cả quốc gia
Tôi cũng hiểu mong muốn giảm nhiễu và chỉ cho phép “một nhóm bạn nhỏ”
Tuy nhiên tôi chỉ làm vậy với các dịch vụ cụ thể, chứ không phải toàn bộ domain. Máy chủ Mumble thì tôi chỉ mở cho 3–4 quốc gia nơi bạn bè tôi ở, và loại trừ các nhà cung cấp cloud. Blog kỹ thuật thì tôi để bất kỳ ai trên thế giới cũng có thể xem
Tôi đứng vững ở quan điểm rằng tri thức chia sẻ có lợi cho tất cả mọi người. Nếu ghi chú của tôi về chuỗi khởi tạo modem cho modem C64 300 baud giúp được dù chỉ một người, người đó sẽ không phải lặp lại nỗi khổ tôi đã trải qua, và thế giới sẽ tốt hơn một chút
Tôi hiểu vì nhiều lý do mà mong muốn như vậy xuất hiện. Không sao cả. Mỗi người tự quyết
Amazon quá lớn để có thể phớt lờ. Tôi hiểu rằng phần lớn lưu lượng ICMP và SYN là rác. Tôi cũng muốn giúp chặn, và thực tế mặc định cũng đã có các biện pháp giảm thiểu
Vấn đề là Amazon “ở quy mô lớn” tác động đến các biện pháp giảm thiểu của tôi, nên rất phiền. Amazon không giúp phân biệt thóc với trấu. Kiểu như “hãy gửi PCAP về vấn đề ping”
Nếu gửi tài liệu cho Amazon rồi không nhận được bất kỳ phản hồi nào, thì chẳng học được gì. Tôi không cần lưu lượng tốt, cũng không cần lưu lượng xấu, hay lưu lượng giả mạo tấn công họ
Nếu họ không có ý định giúp tôi giúp họ, thì tôi không cần gì hết. Tôi chỉ đang giữ cho cuộc sống của mình đơn giản thôi
Nhìn những chuyện như thế này lại thấy nhớ Internet ngày xưa. Thật khó giải thích Internet trước khi bị thương mại hóa tuyệt vời đến mức nào
Niềm vui cay đắng vì đã đoán đúng rằng kết cục sẽ thành ra thế này hoàn toàn không đủ để bù đắp cho những gì đã mất
So với những nơi như DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, thậm chí cả Google, AWS chỉ như hướng đạo sinh
Đặc biệt, tôi nghĩ DigitalOcean đã phạm một sai lầm kinh khủng khi marketing tới cộng đồng “an ninh mạng”
Công khai xung đột lợi ích: AWS hiện là chủ lao động của tôi
Có thể tôi đang bỏ sót điều gì đó hiển nhiên, nhưng nếu tác giả tin rằng lưu lượng ping đã bị spoof, thì làm sao biết nguồn là AWS?
Theo kinh nghiệm, tôi đã thấy quá nhiều trường hợp lưu lượng áp đảo đến từ AWS, và trong vài trường hợp đã đi đến cùng một giải pháp: chặn toàn bộ AWS
Tôi không biết là AWS không quan tâm, hay phản ứng chậm. Cũng có thể việc báo cáo quá khó
Điểm hiển nhiên bị bỏ sót là đây. AWS là một nguồn khổng lồ của lưu lượng “xấu”, và việc đình chỉ khách hàng vận hành sai thì quá khó, trong khi kẻ xấu lại quá dễ thuê dung lượng phi lý
Tôi hầu như chưa từng thấy GCP hay Azure trở thành nguồn của lưu lượng điên rồ ở cùng mức đó