Các địa chỉ IP có tầm thường không?

Tôi đã đọc qua một số ghi chú về dịch vụ DNS công cộng mới của Google :

• Hiệu suất lợi ích
• Lợi ích bảo mật

Tôi nhận thấy dưới phần bảo mật đoạn này:

Cho đến khi một giải pháp toàn hệ thống tiêu chuẩn cho các lỗ hổng DNS được triển khai trên toàn cầu, như giao thức DNSSEC2, các trình phân giải DNS mở cần thực hiện một số biện pháp độc lập để giảm thiểu các mối đe dọa đã biết. Nhiều kỹ thuật đã được đề xuất; xem IETF RFC 4542: Các biện pháp làm cho DNS trở nên linh hoạt hơn trước các câu trả lời giả mạo để có cái nhìn tổng quan về hầu hết chúng. Trong Google Public DNS, chúng tôi đã triển khai và chúng tôi khuyên bạn nên sử dụng các phương pháp sau:

• Cung cấp quá mức tài nguyên máy để bảo vệ chống lại các cuộc tấn công DoS trực tiếp vào chính các bộ giải quyết. Vì địa chỉ IP là không đáng kể để kẻ tấn công giả mạo, nên không thể chặn truy vấn dựa trên địa chỉ IP hoặc mạng con; cách hiệu quả duy nhất để xử lý các cuộc tấn công như vậy là chỉ cần hấp thụ tải.

Đó là một nhận thức chán nản; ngay cả trên Stack Overflow / Server Fault / Super User, chúng tôi thường xuyên sử dụng địa chỉ IP làm cơ sở cho các lệnh cấm và các loại.

Nghĩ rằng một kẻ tấn công "tài năng" có thể sử dụng tầm thường bất cứ địa chỉ IP nào họ muốn và tổng hợp nhiều địa chỉ IP giả duy nhất mà họ muốn, thực sự đáng sợ!

Vì vậy, câu hỏi của tôi:

• Là nó thực sự là dễ dàng cho kẻ tấn công giả mạo địa chỉ IP trong tự nhiên?
• Nếu vậy, những gì giảm nhẹ là có thể?

Như nhiều người khác đã nêu, các tiêu đề IP rất nhỏ để giả mạo, miễn là người ta không quan tâm đến việc nhận được phản hồi. Đây là lý do tại sao nó chủ yếu được nhìn thấy với UDP, vì TCP yêu cầu bắt tay 3 bước. Một ngoại lệ đáng chú ý là lũ SYN , sử dụng TCP và cố gắng liên kết tài nguyên trên máy chủ nhận; một lần nữa, khi các câu trả lời bị loại bỏ, địa chỉ nguồn không quan trọng.

Một tác dụng phụ đặc biệt khó chịu về khả năng kẻ tấn công giả mạo địa chỉ nguồn là một cuộc tấn công tán xạ ngược . Có một mô tả xuất sắc ở đây , nhưng ngắn gọn, đó là nghịch đảo của một cuộc tấn công DDoS truyền thống:

1. Giành quyền kiểm soát một mạng botnet.
2. Định cấu hình tất cả các nút của bạn để sử dụng cùng một địa chỉ IP nguồn cho các gói độc hại. Địa chỉ IP này sẽ là nạn nhân cuối cùng của bạn.
3. Gửi các gói từ tất cả các nút được kiểm soát của bạn đến các địa chỉ khác nhau trên internet, nhắm mục tiêu các cổng thường không mở hoặc kết nối với các cổng hợp lệ (TCP / 80) tự nhận là một phần của giao dịch đã tồn tại.

Trong một trong các trường hợp được đề cập trong (3), nhiều máy chủ sẽ phản hồi với ICMP không thể truy cập được hoặc thiết lập lại TCP, nhắm vào địa chỉ nguồn của gói độc hại . Kẻ tấn công hiện có khả năng hàng ngàn máy móc không thỏa hiệp trên mạng thực hiện một cuộc tấn công DDoS vào nạn nhân được chọn của mình, tất cả thông qua việc sử dụng địa chỉ IP nguồn giả mạo.

Về mặt giảm thiểu, rủi ro này thực sự là một rủi ro mà chỉ các ISP (và đặc biệt là các ISP cung cấp quyền truy cập của khách hàng, thay vì quá cảnh) mới có thể giải quyết. Có hai phương pháp chính để làm điều này:

1. Lọc xâm nhập - đảm bảo các gói đến mạng của bạn có nguồn gốc từ các dải địa chỉ nằm ở phía xa của giao diện đến. Nhiều nhà cung cấp bộ định tuyến triển khai các tính năng như chuyển tiếp đường dẫn ngược unicast , sử dụng bảng định tuyến và chuyển tiếp của bộ định tuyến để xác minh rằng bước nhảy tiếp theo của địa chỉ nguồn của gói đến là giao diện đến. Điều này được thực hiện tốt nhất ở lớp 3 hop đầu tiên trong mạng (tức là cổng mặc định của bạn.)

2. Lọc ra - đảm bảo rằng các gói rời khỏi mạng của bạn chỉ có nguồn từ phạm vi địa chỉ mà bạn sở hữu. Đây là phần bổ sung tự nhiên cho quá trình lọc xâm nhập và về cơ bản là một phần của 'hàng xóm tốt'; đảm bảo rằng ngay cả khi mạng của bạn bị xâm phạm bởi lưu lượng độc hại, lưu lượng đó sẽ không được chuyển tiếp đến các mạng mà bạn ngang hàng.

Cả hai kỹ thuật này đều hiệu quả nhất và dễ dàng thực hiện khi được thực hiện trong các mạng 'cạnh' hoặc 'truy cập', nơi giao diện máy khách với nhà cung cấp. Việc thực hiện lọc vào / ra phía trên lớp truy cập trở nên khó khăn hơn, do sự phức tạp của nhiều đường dẫn và định tuyến không đối xứng.

Tôi đã thấy các kỹ thuật này (đặc biệt là lọc xâm nhập) được sử dụng để có hiệu quả lớn trong mạng doanh nghiệp. Có lẽ ai đó có nhiều kinh nghiệm cung cấp dịch vụ hơn có thể cung cấp cái nhìn sâu sắc hơn về những thách thức của việc triển khai lọc / xâm nhập trên internet trên diện rộng. Tôi tưởng tượng hỗ trợ phần cứng / phần sụn là một thách thức lớn, cũng như không thể buộc các nhà cung cấp thượng nguồn ở các quốc gia khác thực hiện các chính sách tương tự ...

Có thực sự dễ dàng cho kẻ tấn công giả mạo địa chỉ IP trong tự nhiên không?

Chắc chắn, nếu tôi không quan tâm đến việc thực sự nhận được bất kỳ phản hồi nào, tôi có thể dễ dàng gửi các gói bằng bất kỳ địa chỉ nguồn nào tôi muốn. Vì nhiều ISP không thực sự có quy tắc đi ra tốt, nên mọi thứ tôi giả mạo thường sẽ được chuyển giao.

Nếu kẻ tấn công thực sự cần giao tiếp hai chiều thì nó trở nên rất khó khăn. Nếu họ cần giao tiếp hai chiều, có xu hướng dễ dàng hơn chỉ đơn giản là sử dụng proxy của một loại nào đó. Điều này rất dễ cài đặt nếu bạn biết bạn đang làm gì.

Cấm mọi người theo địa chỉ IP có hiệu quả vừa phải trên SF / SO / SU do trang web sử dụng http / https yêu cầu giao tiếp hai chiều.

Bằng chứng nhỏ về khái niệm cho câu trả lời của Zordeche (với Ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Sau đó, trong một giao diện điều khiển khác:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Vì vậy, có, tầm thường, nhưng sau đó bạn không nhận được câu trả lời như đã đề cập trước đó trừ khi bạn có quyền truy cập vào 11.10.10.20 hoặc có một trình thám thính ở đâu đó giữa www.google.com và 11.10.10.20 (Và nó sẽ cần ở ngay trước mặt của một trong hai đầu, vì bạn không thể dự đoán lộ trình của các gói). Ngoài ra, cổng giả mạo (ISP) có thể không để gói đó ra khỏi cửa nếu họ có một số loại kiểm tra ip đang diễn ra và thấy rằng nguồn có mùi khó chịu.

Địa chỉ IP rất dễ giả mạo cho lưu lượng UDP một chiều . Đối với các gói TCP, bạn chỉ có thể giả mạo để có được kết nối TCP mở một nửa với các gói SYN. Đây là cơ sở của một loại tấn công DOS là tốt. Nhưng bạn không thể giả mạo kết nối HTTP với một địa chỉ giả mạo (ví dụ: nếu bạn đang lọc các phiên để sử dụng cùng một địa chỉ IP). Mặc dù có, bạn có thể giả mạo một địa chỉ IP trong các gói, nó chỉ hữu ích cho các loại tấn công từ chối dịch vụ nhất định.

Bài viết GOOG đã thảo luận rõ ràng về DNS. DNS sử dụng cả gói UDP và TCP. Những cái UDP có thể được giả mạo, nhưng không phải là TCP. TCP yêu cầu bắt tay 3 bước . Nếu địa chỉ IP cho gói TCP bị giả mạo thì máy tính giả mạo sẽ không nhận được phản hồi và kết nối sẽ không thành công. UDP, như đã đề cập trong các câu trả lời khác, là 'cháy và quên' và không yêu cầu giao tiếp phản hồi. Các cuộc tấn công DoS hầu như chỉ xuất hiện dưới dạng các gói UDP vì lý do này.

Trong bối cảnh Stack Overflow và các trang web gia đình, vấn đề được Takaun Daikon nêu ra là rất hợp lệ. Có nhiều cách để lấy địa chỉ IP mới từ ISP của một người. Thay đổi địa chỉ MAC rõ ràng là dễ nhất và hoạt động đối với nhiều ISP. Ngoài ra, nhiều người có xu hướng mắc bệnh có thể đang sử dụng proxy công cộng hoặc TOR. Rõ ràng việc chặn IP khởi tạo cho các gói đó sẽ chỉ chặn nút chấm dứt proxy hoặc TOR.

Vậy việc chặn địa chỉ IP có hợp lệ không? Đúng rồi Nhưng bạn sẽ kết thúc với lỗi. Bạn sẽ chặn một số IP thực sự không phải là nguồn gốc của vấn đề (ví dụ như proxy) và bạn cũng sẽ có người tránh các khối của mình bằng cách thay đổi IP. Người không may mắn có được IP bị cấm sau đó sẽ không thể truy cập vào trang web của gia đình SO. Nhưng tỷ lệ lỗi nên nhỏ. Trừ khi bạn đang chặn các bộ IP khổng lồ. Nhưng nếu bạn đang chặn một hoặc hai ngày một lần, bạn sẽ ổn thôi.

Bạn có thể muốn giới thiệu một sơ đồ phức tạp hơn một chút nơi bạn chặn, nhưng chỉ trong một khoảng thời gian, như một năm. Nếu mạng của bạn có khả năng điều chỉnh băng thông hoặc giới hạn kết nối, bạn cũng có thể xem xét một sơ đồ trong đó các túi thụt rửa chạy Apache Benchmark trên trang web của bạn chỉ bị đặt trong một cái lồng với băng thông rất hạn chế.

Việc giả mạo IP sẽ tiếp tục vì các ISP lười biếng.

ISP của tôi rất biết rằng tôi đang ở một địa chỉ cụ thể hoặc ít nhất là mạng con tôi đang sử dụng. Tuy nhiên tôi có thể sử dụng bất kỳ địa chỉ nguồn. Tại sao vậy? Đơn giản, chi phí.

Nếu tôi giả mạo một vài địa chỉ ở đây và đó, nó sẽ không mất gì cho ISP của tôi. Nếu mọi người dùng ISP của tôi làm giả một gói trong khoảng thời gian từ 1:00 đến 2:00, thì nó vẫn khó có thể là một đốm sáng trên radar. Tuy nhiên, khi một botnet gửi nhiều gói giả mạo từ nhiều máy chủ trên nhiều ISP, máy hoặc mạng đích sẽ bị đổ.

Thực tế tài chính là trừ khi bạn là người bị tấn công, giả mạo chi phí không có gì. Nó tốn tiền để thực hiện lọc gần khách hàng và người chi tiền nhận được rất ít lợi nhuận ngoài việc biết họ là công dân mạng tốt.

UDP và ICMP dễ giả mạo nhất, nhưng TCP cũng có thể. Nó đòi hỏi một hệ điều hành từ xa không an toàn, sử dụng các số thứ tự dự đoán để khai thác. Đôi khi, đó là máy cân bằng tải làm thay đổi số thứ tự và làm cho chúng có thể dự đoán được. Vì vậy, TCP là có thể - nhưng khó hơn.

Chống giả mạo DNS tập trung chủ yếu vào khía cạnh bảo mật để ngăn người nào đó gửi câu trả lời sai cho người giải quyết đệ quy. Các khía cạnh ngập lụt của UDP không phải là DNS cụ thể ngoài một truy vấn nhỏ (ví dụ: '.') Sẽ gây ra phản hồi khá lớn. Vì vậy, nó làm cho một vector khuếch đại tốt đẹp. Có nhiều giao thức UDP khác hoạt động, nhưng DNS được sử dụng ở mọi nơi và thật dễ dàng tìm thấy các máy sử dụng để khuếch đại các cuộc tấn công.

DNSSEC làm cho điều này thậm chí còn tồi tệ hơn, với các gói UDP có thể đạt kích cỡ 4k.

Các địa chỉ IP là không đáng kể để giả mạo về các cuộc tấn công DOS (D) dựa trên DNS có liên quan, vì chúng thường là một trường hợp của các gói UDP cháy và quên. Đối với lưu lượng HTTP, đó không phải là trường hợp, vì vậy bạn cần phải ở trên cùng một mạng cục bộ với máy chủ web (tất nhiên là có thể, tùy thuộc vào nơi trang web của bạn được lưu trữ) hoặc điều khiển các bộ định tuyến trung gian.

Bạn có thể gửi thư cho bất kỳ ai và nếu bạn không đặt địa chỉ trả lại trên phong bì (hoặc đặt sai), họ có thể thuê tất cả các bộ lọc thư rác trên thế giới và không lọc thư của bạn mà không mở (xử lý ) nó

Tuy nhiên, nếu người gửi muốn có phản hồi, địa chỉ trả lại tốt hơn là chính xác hoặc phải có một cơ chế lớp ứng dụng để nhận địa chỉ chính xác. Vì vậy, tôi có thể khiến bạn nghĩ rằng bạn đang mở một lá thư từ Nana, nhưng ngay cả khi tôi lừa bạn với nội dung của bức thư, bạn sẽ không gửi cho Ngân một tờ séc được gửi tới CASH đến một địa chỉ nào đó ở Nigeria (trừ khi Nana là người Nigeria ). Vì vậy, thách thức / phản ứng là một cách phòng thủ hiệu quả miễn là bạn không phải là Người đàn ông trong Middled.

Tôi có thể đặt bất kỳ địa chỉ IP nguồn nào tôi muốn trong một datagram.
Liệu ISP của tôi có cho phép một gói như vậy ra ngoài tự nhiên hay không là một câu hỏi khác.

Trong khi điều này chắc chắn là một thực tế cần phải được xử lý, vấn đề tiềm ẩn thực sự là phi kỹ thuật: Những người có ý định độc hại cố gắng làm những điều độc hại. Do đó, giải pháp thực sự phải là phi kỹ thuật.

Tôi nghĩ rằng những gì Stackoverflow đã làm là CHÍNH XÁC giải pháp phù hợp để xử lý tuyến phòng thủ thứ hai: Các kỹ thuật hạn chế người dùng spam tiềm năng thông qua các cách khác nhau để hạn chế khả năng tương tác với nền tảng trước khi đạt được mức độ 'tin cậy'.

Những kỹ thuật này không chỉ giúp cải thiện chất lượng tổng thể của trang web, mà chúng còn thực sự khuyến khích người dùng tham gia nhiều hơn và cung cấp các câu trả lời đáng tin cậy / đáng tin cậy hơn.

Từ quan điểm kỹ thuật, điều tốt nhất nên làm sau đó sẽ là như Google gợi ý: chỉ cần hiệu quả trong việc hấp thụ / xử lý tải trọng bổ sung.

Công việc tuyệt vời và tiếp tục cải thiện!

UDP là phần chính của lý do tại sao điều này dễ dàng - trên thực tế, Skype và Slingbox khai thác khả năng giả mạo địa chỉ IP dễ dàng trong UDP để ' đấm ' thông qua NAT và cho phép dễ dàng ngang hàng.

TCP khó hơn vì nó yêu cầu chu trình SYN / ACK đầy đủ, nhưng bạn vẫn có thể làm ngập máy chủ bằng các gói SYN treo đến địa chỉ IP cách xa nhiều bước và về cơ bản buộc một số lượng lớn bộ định tuyến trong quy trình.

Như đã đề cập ở trên, sử dụng proxy là chuyện nhỏ, và có một số lượng rất lớn các proxy ẩn danh mở có sẵn.

Ngay cả khi không sử dụng proxy, tôi có thể đặt địa chỉ MAC trên tường lửa của mình thành bất kỳ giá trị tùy ý mới nào, đặt lại modem cáp và ISP của tôi sẽ gán cho tôi một địa chỉ IP sáng bóng hoàn toàn mới.

Và đó chỉ là cho người mới bắt đầu. Có nhiều cách khác để có được các lệnh cấm IP.

Nếu vậy, những gì giảm nhẹ là có thể?

Không có nhiều bạn có thể làm ở phía nhận.

ISP của trình giả mạo nên lọc lưu lượng ra bên ngoài của họ để khách hàng của họ không thể giả mạo IP từ các mạng khác nhau.

Nó chỉ là một vài dòng trong cấu hình bộ định tuyến nên không có lý do gì để không làm điều đó.

Có một cách để theo dõi kẻ tấn công, nhưng nó đòi hỏi sự hợp tác của các nhà cung cấp thượng nguồn của bạn: http://www.cymru.com/Document/dos-and-vip.html

Như những người khác đã chỉ ra, UDP là khá nhỏ để giả mạo, TCP không quá nhiều.

Phòng thủ ưa thích, nhưng không may không được triển khai trên toàn cầu, là các bộ lọc đi ra.

Đối với các ISP chạy các dịch vụ DSL, v.v., mỗi dòng ảo phải được cấu hình bằng ip verify unicast reverse-path(hoặc bất cứ thứ gì không tương đương với Cisco) để chặn bất kỳ gói tin nào có địa chỉ IP nguồn không nằm trong phạm vi được biết sẽ được chuyển xuống dòng đó.

Tôi có thể nhớ việc thực hiện lập trình socket vào cuối những năm 90 với Visual Basic và chúng tôi có thể đặt IP nguồn trên kết nối của chúng tôi. Tôi nhớ một cách mơ hồ rằng khi chúng tôi thử nó, netstat -an đã hiển thị IP nguồn thực tế, nhưng nhật ký Apache cho thấy IP giả mạo; và tôi nghĩ rằng Apache đã trao IP giả mạo cho các mô-đun perl, v.v.