it-swarm-vi.com

Tại sao hệ thống phòng thủ che giấu hệ điều hành chống lại "Đó là một hệ thống Unix!" không được thực hiện rộng rãi?

Cảnh công viên kỷ Jura được tham chiếu trong tiêu đề là tai tiếng vì nó nghe có vẻ lố bịch đối với những người biết đọc biết viết công nghệ. Nhưng nó cũng minh họa cho những gì dường như là một lỗ hổng lớn về bảo mật web, đặc biệt là các thiết bị IoT - ngay khi những kẻ tấn công phát hiện ra máy chủ hoặc máy ảnh hoặc màn hình bé đang chạy linux, chúng ngay lập tức biết rất nhiều về cách thức hoạt động của nó. Họ biết rằng các lệnh như Sudo là các mục tiêu lớn và họ biết rằng quyền truy cập Shell sẽ mang lại cho nó các công cụ hữu ích như lscat.

Vậy tại sao hệ điều hành không làm phiền nhiều thứ hơn? Tôi không nói về việc chỉ ẩn phiên bản trong các tiêu đề web. Tương tự như thu nhỏ hoặc mã hóa JavaScript, tôi đang nói về việc thay đổi tên của nhị phân và filepath trong chính HĐH. Toàn bộ các lớp tấn công sẽ thực sự vô dụng nếu HĐH có ha7TrUORRI6e29 lệnh thay vì Sudols? Hãy tưởng tượng một hacker bằng cách nào đó có được quyền truy cập root từ xa - họ thậm chí sẽ làm gì nếu họ không biết bất kỳ lệnh nào?

Việc thực hiện sẽ khá dễ dàng cho trình biên dịch. Lấy trường hợp đơn giản nhất là "đổi tên hàm này và tất cả các lệnh gọi đến nó." Bạn có thể cung cấp cho trình biên dịch HĐH và trình biên dịch ứng dụng cùng tên ngẫu nhiên và chúng có thể nói chuyện với nhau. Nhưng ngay cả khi ứng dụng có bảo mật kém và dễ bị bash tiêm, các cuộc tấn công như vậy sẽ không có kết quả.

Rõ ràng kỹ thuật này không thể được sử dụng trong tất cả các kịch bản. Đặt các kịch bản như các máy chủ được duy trì bởi các hệ thống của con người, đối với tôi, dường như bất kỳ thiết bị hoặc máy chủ nào được quản lý bởi tự động hóa đều là ứng cử viên chính cho biện pháp bảo vệ này.

Tôi đoán (các) câu hỏi cần phải cụ thể hơn một chút:

  1. Có phải hệ điều hành obfuscation như được mô tả được sử dụng rộng rãi và tôi không gặp phải nó?
  2. Nếu không được sử dụng rộng rãi, các rào cản thực tế hoặc kỹ thuật đối với việc sử dụng là gì?
156
Indigenuity

Trước khi tôi xé tan ý tưởng của bạn, hãy để tôi nói rằng đó là một ý tưởng thực sự thú vị và thật thú vị khi nghĩ về.

Hãy tiếp tục suy nghĩ bên ngoài hộp và đặt câu hỏi thú vị!

Được rồi, chúng ta hãy làm điều này!


Chúng ta hãy lùi lại một bước và hỏi tại sao màn hình bé đó lại chạy Linux? Điều gì xảy ra nếu không có hệ điều hành và ứng dụng được viết bằng mã vi điều khiển trần (nghĩ mã arduino)? Sau đó, sẽ không có Sudo hoặc ls hoặc thậm chí là Shell để kẻ tấn công sử dụng, phải không?

Tôi không phải là một chuyên gia ở đây, nhưng tôi hy vọng rằng chúng ta, với tư cách là một ngành công nghiệp, đã hướng đến việc đưa Linux lên bất cứ thứ gì đủ lớn để chạy nó phần lớn vì sự thuận tiện của nhà phát triển:

  1. Giảm thời gian phát triển: Khi xây dựng trình whizpopper tự vá đồng bộ trên nền tảng đám mây có khả năng WiFi và bluetooth với người bạn đồng hành Android và ứng dụng iOS, Linux đi kèm với tất cả các thư viện, tiện ích và trình điều khiển bạn cần phải làm điều đó.
  2. Tăng khả năng kiểm tra: Nếu thiết bị đang chạy bash hoặc busybox với cổng SSH, thì việc kết nối và tìm ra lỗi đã xảy ra trong giai đoạn thử nghiệm sản phẩm của bạn là cực kỳ dễ dàng.

Để ý tưởng obfuscation của bạn hoạt động, bạn cần phải xáo trộn không chỉ tên của các tiện ích dòng lệnh như Sudols, mà còn mọi API nhân Linux để ngăn chặn kẻ tấn công thả vào nhị phân được biên dịch riêng của chúng gọi kernel trực tiếp. Vì vậy, hãy xem xét lại ý tưởng của bạn:

Việc thực hiện sẽ khá dễ dàng cho trình biên dịch. Lấy trường hợp đơn giản nhất là "đổi tên hàm này và tất cả các lệnh gọi đến nó." Bạn có thể cung cấp cho trình biên dịch HĐH và trình biên dịch ứng dụng cùng tên ngẫu nhiên và chúng có thể nói chuyện với nhau.

Bạn sẽ cần phải tự thực hiện việc biên dịch ngẫu nhiên này; nếu không thì ai đó có thể tra cứu ánh xạ trên google.

Vì vậy, bạn sẽ cần xây dựng kernel từ nguồn bằng "trình biên dịch che giấu" của mình để chỉ bạn biết ánh xạ của các API kernel bị xáo trộn. (đã bao giờ xây dựng kernel linux từ nguồn chưa? Chắc chắn đó là việc vặt hơn docker pull Alpine, đó là hướng mà văn hóa dev dường như đang đi) .

Nhưng một hệ điều hành không chỉ là kernel. Bạn muốn trình điều khiển cho chip wifi Broadcom BCM2837 đi kèm với thiết bị mini-pc đó? Bạn sẽ cần phải xây dựng trình điều khiển đó dựa trên kernel ofbuscated bằng trình biên dịch của mình, nếu Broadcom thậm chí sẽ cung cấp cho bạn mã nguồn. Hơn bạn sẽ cần phải xây dựng toàn bộ GNU wifi và phần mềm kết nối mạng. Bạn cần bao nhiêu thứ khác để tìm nguồn và thêm đường dẫn xây dựng trước khi bạn có HĐH hoạt động?

Ồ, và nếu các repos ngược dòng của bất kỳ thứ gì trong số đó phát hành một bản vá, thì bây giờ bạn có trách nhiệm xây dựng lại nó (giả sử bạn đã lưu các tệp ánh xạ obfuscation của trình biên dịch khớp với tệp nhị phân kernel của bạn) và đẩy nó ra các thiết bị của bạn bởi vì - theo thiết kế - thiết bị của bạn không thể sử dụng các tệp nhị phân do nhà cung cấp sản xuất.

Ồ, và để chặn các tin tặc, sẽ không có ai trong số này "Đây là tệp nhị phân cho Whizpopper 1.4.7" , ồ không, bạn 'sẽ cần xây dựng một phiên bản bị xáo trộn duy nhất của mọi thứ từ kernel trở lên trên mỗi thiết bị mà bạn gửi.


Vì vậy, câu hỏi của bạn:

  1. Có phải hệ điều hành obfuscation như được mô tả được sử dụng rộng rãi và tôi không gặp phải nó?
  2. Nếu không được sử dụng rộng rãi, các rào cản thực tế hoặc kỹ thuật đối với việc sử dụng là gì?

Tôi nghĩ rằng câu trả lời là những gì bạn mô tả gần như hoàn toàn đánh bại mục đích sử dụng các thành phần phần mềm có sẵn nếu bạn cần tìm và xây dựng mọi thứ từ nguồn. Nó thực sự có thể ít nỗ lực hơn để bỏ hoàn toàn hệ điều hành, giả vờ là năm 1960 và viết ứng dụng của bạn trực tiếp vào vi mã CPU.

Tôi thích bảo mật hơn hầu hết các nhà phát triển, nhưng thích f * that .

235
Mike Ounsworth

Câu trả lời của Mike về cơ bản là tất cả mọi thứ tôi phải cung cấp về lý do tại sao đây là một ý tưởng tồi từ quan điểm phát triển (và, như nhận xét của Ghedipunk nói, một tính năng bảo mật không thể sử dụng không cung cấp bảo mật). Vì vậy, thay vào đó, tôi sẽ nói về lý do tại sao từ góc độ bảo mật , bạn sẽ không bao giờ làm điều này.

Câu trả lời thực sự đơn giản đến ngạc nhiên: thật lãng phí thời gian và có những lựa chọn tốt hơn. Mọi hình tượng trưng ngu ngốc của IoT (hãy nhớ rằng, "s" trong "IoT" là viết tắt của Secure) không bận tâm để thực hiện các tính năng như vậy chắc chắn rằng địa ngục sẽ không đi theo cách tiếp cận như bạn đề xuất.

  1. Toàn bộ ý tưởng sẽ không hoạt động để hạn chế các cuộc gọi hệ thống. Kẻ tấn công chỉ có thể thiết lập một vài thanh ghi và gọi opcode và boom, chúng nằm trong kernel thực thi tòa nhà theo lựa chọn của chúng; Ai quan tâm cái tên tượng trưng của nó là gì? Chắc chắn, bạn có thể can thiệp vào bảng tòa nhà để làm phức tạp điều này (nếu bạn không cần phải biên dịch lại mọi thứ và biến việc gỡ lỗi kernel tùy chỉnh của bạn thành một dạng địa ngục hoàn toàn) nhưng nó giống như làm xáo trộn hệ điều hành đang sử dụng; Tại sao phải bận tâm khi có rất ít ứng cử viên, dù sao đi nữa? Ngay cả khi kẻ tấn công không muốn thiết kế ngược mã hiện có trên hệ thống, thì có thể sử dụng vũ lực trừ khi không gian tìm kiếm của các chỉ số cuộc gọi có thể sử dụng rộng hơn tôi từng thấy trên hệ thống nhúng.
  2. Tại sao obfuscate tên lệnh khi bạn chỉ có thể làm cho chúng hoàn toàn không thể truy cập? A chroot sẽ không hoạt động cho các phần mềm tích hợp Shell nếu bạn đang chạy Shell , nhưng nó hoạt động tốt với mọi thứ khác và thực sự, tại sao ứng dụng đơn mục đích được xây dựng tùy chỉnh của bạn sẽ chạy shell? Ý tôi là, các đơn vị dev sẽ được cài đặt, cho mục đích thử nghiệm và có thể điều đó không bị xóa trong hình ảnh bán lẻ của bạn vì bạn lười biếng hoặc nghĩ rằng bạn sẽ cần nó một lần nữa. Nhưng kẻ tấn công sẽ không thể chạy nó từ bối cảnh mà ứng dụng của nó chạy. Một chroot (hoặc hộp cát/tù/container phức tạp hơn) có thể khiến chương trình không thể chạy - hoặc thậm chí truy cập - bất kỳ tệp nào ngoài những tệp cần thiết cho công việc của nó.
  3. Tại sao làm xáo trộn các API kernel khi bạn chỉ có thể xóa quyền truy cập vào chúng? Có một số hệ thống hộp cát có thể hạn chế những gì gọi là một quá trình (hoặc hậu duệ của nó ... nếu nó thậm chí được phép tạo ra bất kỳ) có thể thực hiện. Xem https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Nếu mục tiêu của bạn là tước đi kẻ tấn công lscat, thì có một cách khác thậm chí tốt hơn để che giấu: chỉ cần không cài đặt các tiện ích đó.

Mặc dù tôi sẽ không nói đây là một cách tiếp cận rộng rãi , nhưng ít nhất nó cũng được thực hiện. Ví dụ, hãy xem xét distroless , một bộ sưu tập các hình ảnh docker với khá nhiều không có gì trong đó. Một số người trong số họ (như người muốn đi) thực sự có không có gì trong đó. Một cuộc tấn công vào một hệ thống đang chạy trong một thùng chứa như vậy không thể có quyền truy cập Shell vì không có Shell nào để chạy.

Cách duy nhất sau đó để có được quyền truy cập Shell bằng cách tấn công một ứng dụng trong một thùng chứa như vậy là phá vỡ thời gian chạy của bộ chứa, được thiết kế để ngăn chặn chính xác điều đó.

Mặc dù tôi đã đưa ra một ví dụ về hình ảnh docker, khái niệm tương tự có thể được áp dụng cho các hệ điều hành nói chung. Ví dụ: lscat là một phần của gói coreutils trong Debian. Bạn có thể chạy apt-get remove coreutils và hãy tự tin rằng kẻ tấn công sẽ không thể sử dụng ls hoặc cat như một phần của cuộc tấn công. Tất nhiên, điều này có nghĩa là bạn cũng không thể sử dụng chúng, và có lẽ có rất nhiều thứ khác phụ thuộc vào coreutils cũng sẽ phải bị xóa, nhưng đối với một thiết bị nhúng hoặc máy chủ chỉ làm một việc điều đó có thể ổn.

Nguyên tắc chung là giảm "bề mặt tấn công": mục tiêu càng có nhiều "công cụ" thì càng dễ thỏa hiệp. Các công cụ có thể là cổng mạng mở, dòng mã hoặc nhị phân được cài đặt. Nếu tăng cường bảo mật là mục tiêu, thì loại bỏ tất cả các "công cụ" không cần thiết là một khởi đầu tốt.

30
Phil Frost

Bởi vì obfuscation không phải là bảo mật và bởi vì obfuscation về cơ bản là vô nghĩa.

Chỉ có rất nhiều hệ điều hành phổ biến và rất nhiều cách để đưa ra những phỏng đoán có giáo dục. Nếu bạn phát hiện ra rằng tôi đang chạy IIS hoặc MSSQL Server, bạn có thể đoán hệ điều hành nào đang chạy bên dưới.

Ngay cả khi tôi bằng cách nào đó quản lý để chạy một ngăn xếp mà không cho bạn biết gì về hệ điều hành cơ bản của tôi và cũng che dấu mọi gợi ý khác về nó (dấu vân tay là một thứ), tôi vẫn không giành được nhiều.

Bảo mật, bạn biết rằng tôi đang chạy Linux, hoặc thậm chí là tôi đang chạy Debian 8, không mang lại cho bạn nhiều thứ để làm việc mà tôi cũng không phải lo lắng nhiều. Nếu tôi cứng và vá đúng cách, bạn có thể biết bất cứ điều gì bạn muốn. Nếu tôi ở cấp độ bản vá đã áp dụng cho bảo tàng phần mềm ngày hôm qua, bộ tấn công của bạn sẽ giúp tôi mở rộng chỉ bằng cách thử tất cả, và làm phiền hệ điều hành của tôi chỉ buộc bạn phải thử một vài cách khai thác vô dụng. Trong một cuộc tấn công tự động, nó sẽ làm bạn chậm lại tất cả vài giây.

Obfuscation không hoạt động. Mọi người có thể quét bạn, lấy dấu vân tay của bạn hoặc chỉ cần ném toàn bộ thư viện khai thác của họ để xem những gì hoạt động.

Nếu bạn lãng phí thời gian cho những gì bạn có thể đã dành cho việc làm cứng thực tế, thì bạn thực sự đang làm tổn hại đến an ninh của bạn.

Làm cứng đúng cách. Tôi đã nói ở trên rằng "bạn có thể biết bất cứ điều gì bạn muốn" . Tôi đã đăng địa chỉ IP của mình và mật khẩu gốc tại các hội nghị bảo mật nơi tôi đã phát biểu. SSH với đăng nhập root từ xa và một loạt các dịch vụ được kích hoạt. Máy làm cứng nghiêm trọng. Không ai từng quản lý để làm gián đoạn bài phát biểu của tôi, mặc dù một người từng quản lý để thả tệp văn bản vào thư mục gốc khi chính sách của tôi chưa hoàn hảo.


Phụ lục: Điểm xuất phát của bạn là một bộ phim. Obfuscation là một thiết bị phim tuyệt vời bởi vì một tiết lộ như thế nói với người xem rằng anh hùng (hoặc nhân vật phản diện) đã tìm thấy một số thông tin và do đó đang tiến bộ. Đó là máy tính tương đương với việc tìm ra nơi an toàn, mặc dù bạn vẫn cần mã. Sẽ không thành vấn đề nếu nó thực sự chính xác, nếu nó truyền tải thông điệp cảm xúc phù hợp đến khán giả.

13
Tom

Đối với một ví dụ cực kỳ phổ biến, Intel Management Engine, có HĐH riêng, thực hiện điều tương tự, khi có cơ chế cập nhật chương trình cơ sở, nhưng phần sụn phải có định dạng rất cụ thể, các chi tiết được bảo mật. Nó xuất hiện liên quan đến mã hóa Huffman với các tham số chưa biết. Tương tự như đề xuất của bạn (về cơ bản là mã hóa đối xứng phần sụn), ME yêu cầu sửa đổi cụ thể tại thời điểm chuẩn bị phần sụn và có độ lệch phù hợp với các cơ chế tiêu chuẩn tại thời điểm thực hiện.

7
Roman Odaisky

Những gì bạn đang mô tả được gọi là "Bảo mật thông qua che khuất" và là một bảo mật được biết đến rộng rãi antipotype . Có nghĩa đó không phải là một ý tưởng mới, thay vào đó là một ý tưởng cũ, tồi tệ, rằng những người không quen thuộc với triết lý bảo mật phải được giáo dục để không rơi vào.

Hãy tưởng tượng bạn đang thiết kế một ngôi nhà để đảm bảo an toàn và nghĩ rằng tối nghĩa là một chiến lược đầy hứa hẹn. Tất cả các ngôi nhà được xây dựng ngoài hành lang và phòng, cửa có tay nắm cửa, công tắc đèn, v.v ... Vì những điều này thường được biết đến, bạn có thể cho rằng điều này là không an toàn vì kẻ đột nhập có thể dễ dàng điều hướng ngôi nhà bởi các yếu tố xây dựng thường được biết đến này. Bạn có thể cố gắng thiết kế lại các nguyên tắc xây dựng từ đầu, thay thế các núm cửa bằng các khối rubik, làm trần nhà bằng một nửa chiều cao để gây nhầm lẫn cho kẻ xâm nhập, v.v. để làm với nó, và điều tồi tệ nhất là không có gì vì bất kỳ kẻ xâm nhập nào, một khi vào bên trong, có thể nhìn xung quanh bằng mắt và sử dụng bộ não của mình để tìm ra nó. Tin tặc là những kẻ nghiện câu đố trong tim.

Giải pháp để bảo vệ ngôi nhà của bạn là không xây dựng không chuẩn, đó là có khóa tốt hơn, cửa sổ an toàn, hệ thống an ninh phù hợp, v.v. Bạn không muốn giấu vàng của mình trong một lối đi bí mật, vì cuối cùng Abbot và Costello sẽ dựa vào chân nến đó và vô tình mở nó ra. Đặt vàng của bạn an toàn với sự kết hợp bí mật tốt và báo động giả mạo. Tương đương máy tính đang bị hạn chế truy cập bằng chứng mã hóa khóa công khai, vai trò truy cập hạn chế của người dùng, hệ thống giám sát, giảm diện tích bề mặt tiếp xúc, giảm thiểu nguy cơ xâm nhập véc tơ, v.v.

Nỗ lực làm cho hệ thống máy tính trở nên tối nghĩa hơn chỉ khiến hệ thống của bạn xa hơn sự hỗ trợ, khó lấy hơn bảo mật bản vá, khó hơn sử dụng một cách an toàn .

Chỉnh sửa: Đôi khi, một số bảo mật thông qua che khuất được chấp nhận, khi được sử dụng ngoài bảo mật thực tế. Một ví dụ phổ biến là chạy SSH trên một cổng cao như 30000 gì đó. SSH được mã hóa và quyền truy cập nằm sau một xác thực được chứng thực, đó là bảo mật thực sự của bạn. Nhưng có nó trên một cổng cao chỉ làm cho nó bắt đầu ít chú ý hơn nếu ai đó thực hiện quét nhanh. Bất cứ điều gì phức tạp hơn thế này, chẳng hạn như cố gắng làm xáo trộn hệ điều hành của bạn, sẽ chỉ khiến nó trở thành một cơn ác mộng hoạt động, khiến cho các biện pháp bảo mật thực tế (như cập nhật trên các bản vá) trở nên khó khăn hơn.

5
user1169420

Hãy suy nghĩ khả năng sử dụng

  • Cố gắng giải thích với sysadmin mới của bạn rằng anh ta phải đánh ha7TrUO nội dung của Sudo, RRI6e29 thay vì ls và cứ thế ... Vâng, có một danh sách các bản dịch bạn chỉ cần học !
  • duyệt mạng cục bộ cũng không thể thực hiện được: bạn phải duy trì danh sách giấy để giữ chế độ xem tổng thể!?

  • Nếu bạn đổi tên tất cả các lệnh quan trọng, bạn sẽ phải lái nó để thực hiện nâng cấp hệ thống!

  • Và như Nick2253 nhận xét , Nếu bạn cố gắng xây dựng hệ thống nhúng, sau đó thực hiện obfuscation trước khi xuất bản sản phẩm cuối cùng, bạn sẽ phải kiểm tra sản phẩm cuối cùng.

    • Bạn phải tạo home made script để ràng buộc mọi thứ cho obfuscation.
    • Nếu có lỗi xảy ra, việc gỡ lỗi sẽ trở nên khó khăn.
    • Bạn phải tạo home made deobfuscation scripts, để có thể thực hiện một số gỡ lỗi.
    • Phản hồi tùy chỉnh (có tệp nhật ký) sẽ phải cũng bị khử.

    Làm như vậy, bạn sẽ thêm một lớp công việc quan trọng với các lỗi tiềm năng mới.

    Đối với rất ít ứng dụng bảo mật, xem thêm

Sự tối nghĩa có thể gây hại cho chính bạn.

Hãy suy nghĩ cấp thấp hơn

  • Ngay cả khi bạn cố gắng đổi tên tệp, chức năng ở cấp ứng dụng và hệ điều hành, tất cả điều này sẽ sử dụng thư viện chuẩn ai sẽ được gọi trực tiếp nếu kẻ tấn công gửi tệp thực thi nhị phân. Bạn thậm chí có thể xem xét làm xáo trộn tất cả các thư viện tiêu chuẩn! (Bao gồm hệ thống tập tin, giao thức mạng ...)

  • Trong khi bạn sử dụng kernel chưa sửa đổi, họ sẽ sử dụng standard biến và không gian tên. Vì vậy, bạn sẽ phải tạo phiên bản bị xáo trộn của kernel ...

... Sau đó, ràng buộc mọi thứ lại với nhau!

Chà, ngay cả khi mọi thứ bị xáo trộn, ứng dụng sẽ phải đối phó với internet. Obfuscation sẽ không ngăn chặn các lỗi khái niệm về điều này!

Tối nghĩa Nếu không ở tất cả các cấp, sẽ không cải thiện bảo mật.

Tối nghĩa hoàn toàn Không thực sự có thể, do nhu cầu sử dụng các giao thức chuẩn để có thể xử lý Internet.

Hãy suy nghĩ giấy phép

Nếu bạn có kế hoạch phân phốiGNU/Linux , bạn phải chia sẻ mã nguồn như được mô tả trong GNU GENITH PUBLIC LICENSE GPLv và/hoặc - GNU LESSER GENUB PICLIC LICENSE LGPLv (tùy thuộc vào ứng dụng và librairies được sử dụng). Điều này sẽ bao gồm xuất bản phương pháp obfuscation cùng với mỗi phân phối sản phẩm.

Trả lời nghiêm túc cho hai câu hỏi của bạn:

Tôi là một chuyên gia, nhưng với một trọng tâm rất nhỏ. Làm việc trên nhiều cơ sở hạ tầng kinh doanh nhỏ khác nhau, tôi đã thực hiện một số lựa chọn vài năm trước. Sự tiến hóa và lịch sử dường như xác nhận sự lựa chọn của tôi, nhưng đó chỉ là quan điểm cá nhân của tôi.

Có phải hệ điều hành obfuscation như được mô tả được sử dụng rộng rãi và tôi không gặp phải nó?

Vì vậy, tôi thực sự không biết trong obfuscation tỷ lệ là rộng rãi được sử dụng, nhưng tôi không sử dụng bảo mật bằng cách che khuất = và giới thiệu và không.

Nếu không được sử dụng rộng rãi, các rào cản thực tế hoặc kỹ thuật đối với việc sử dụng là gì?

Không có rào cản! Chỉ là nó phản tác dụng. Chi phí thời gian nhanh chóng trở nên khổng lồ và cải thiện an ninh là một sự thu hút.

Tất nhiên, một số điều tối thiểu phải làm:

  • Đừng bắt đầu ssh máy chủ nếu không cần thiết
  • Không cài đặt Sudo, sử dụng đúng quyền, nhóm và cấu trúc mạch lạc.
  • Luôn cập nhật cơ sở hạ tầng toàn cầu của bạn !!!

Mẫu nhỏ when light come over obscurity

  • Bảo mật ssh: hai chiều.

    • Di chuyển cổng ssh từ 22 đến 34567

      • nhẹ và nhanh chóng thực hiện, nhưng

      nếu kẻ tấn công tìm thấy chúng, chúng có thể sử dụng lực lượng vũ phu trơn tru chống lại cổng này rất nhiều thời gian cho đến khi người dùng cuối phát hiện ra chúng.

    • cài đặt tường lửa

      • Mạnh hơn, đòi hỏi nhiều kiến ​​thức hơn, nhưng.

      An toàn hơn trong khi cập nhật.

4
F. Hauri

Toàn bộ các lớp tấn công sẽ không thực sự vô dụng nếu HĐH có các lệnh ha7TrUO và RRI6e29 thay vì Sudo và ls? Hãy tưởng tượng một hacker bằng cách nào đó có được quyền truy cập root từ xa - họ thậm chí sẽ làm gì nếu họ không biết bất kỳ lệnh nào?

Một cách khác tốt hơn là đơn giản là không cài đặt các lệnh này ở vị trí đầu tiên. Tôi không tin bạn thực sự cần Shell để chạy kernel Linux, mặc dù điều này ngụ ý rằng quá trình khởi động của bạn là một cái gì đó khác với sysV-init hoặc systemd.

Tuy nhiên, như những người khác đã lưu ý, đó là sự đánh đổi giữa an ninh và dễ phát triển. Thật không may, nhiều nhà sản xuất thiết bị quan tâm nhiều về cái sau hơn cái trước.

Việc thực hiện sẽ khá dễ dàng cho trình biên dịch. Lấy trường hợp đơn giản nhất là "đổi tên hàm này và tất cả các lệnh gọi đến nó." Bạn có thể cung cấp cho trình biên dịch HĐH và trình biên dịch ứng dụng cùng tên ngẫu nhiên và chúng có thể nói chuyện với nhau. Nhưng ngay cả khi ứng dụng có bảo mật kém và dễ bị bash tiêm, các cuộc tấn công như vậy sẽ không có kết quả.

Tôi không chắc bạn cần trình biên dịch giúp đỡ gì cả. Tôi nghĩ rằng bạn hầu hết có thể đạt được điều này bằng cách sửa đổi linker để áp dụng ngẫu nhiên cho tất cả các tên biểu tượng. Có lẽ chỉ cần áp dụng hàm băm với một loại muối chỉ được biết đến bởi nhà sản xuất là đủ. Tôi không chắc bạn thậm chí cần mã nguồn để làm điều này, tức là tôi nghĩ bạn có thể áp dụng xáo trộn cho mã đã được biên dịch.

(Tôi nghĩ đây là một điều dối trá. Bạn có thể cần phải sửa đổi mã đối tượng để thay thế tên biểu tượng, nhưng điều này vẫn giống như cấp độ trình biên dịch, nghĩa là, a) bạn không làm tất cả cứng bit biên dịch C/C++/vv. mã và b) bạn không cần C/C++/bất kỳ mã nguồn nào. OTOH Tôi không chắc bạn có thể làm được điều này hay không nếu mã thiết bị của bạn thay vì giống như Python.)

Tuy nhiên, vẫn có một số khả năng để thiết kế ngược quy trình, tuy nhiên, điều này có thể vi phạm GPL² (đặc biệt là GPLv3) trừ khi bạn cho ra muối, điều này sẽ đánh bại mục đích.

Trên thực tế, "vì GPL" có lẽ là lý do chính khiến bạn không thấy điều này; thật khó để thực hiện theo cách thực sự hữu ích ngoài việc tạo ra mỗi thiết bị khác nha. OTOH, điều đó ít nhất có nghĩa là những kẻ tấn công chỉ có thể nhắm mục tiêu các thiết bị cụ thể thay vì có thể khai thác lỗ hổng trên "any thiết bị chạy Linux x.y.z".

(² Để đơn giản, tôi sẽ chỉ sử dụng "GPL" trong suốt, nhưng lưu ý rằng điều này thường áp dụng ngay cả đối với L công cụ GPL'd.)

Điều đó nói rằng, lưu ý rằng GPL không yêu cầu bạn xuất bản muối vì bạn đã "sửa đổi" các nguồn. Nếu ngẫu nhiên tên biểu tượng xảy ra tại thời điểm biên dịch, bạn chưa đã sửa đổi các nguồn. Lý do bạn cần xuất bản muối là vì GPL yêu cầu người dùng có thể thay thế phiên bản của chính họ của thư viện GPL, điều mà họ không thể làm trừ khi họ biết muối. (Như đã lưu ý, bạn có thể loại bỏ điều này bằng GPLv2, nhưng các hiệu ứng kỹ thuật tương tự như "chỉ chạy phần mềm đã ký", mà GPLv3 được viết riêng để giải quyết.)


Cuối cùng, có thể có một số lợi thế ở đây, nhưng bạn sẽ không tạo ra bất kỳ cụ thể hệ thống nào an toàn hơn đáng kể (nói chung là "bảo mật thông qua che khuất" nói chung là không an ninh cả). Những gì bạn có thể hoàn thành khiến việc nhắm mục tiêu vào nhiều hệ thống thông qua một vectơ khó hơn.

4
Matthew

Tiết lộ công bằng: Tôi là CTO của một công ty xây dựng chỉ này. Không thiên vị cho tất cả những gì bạn muốn.

Nó IS thực sự có thể xây dựng hoàn toàn nhân hệ thống, trình điều khiển thiết bị, gói, toàn bộ ngăn xếp PER Host, nhiều lần mỗi ngày và nó có thể khá hiệu quả. Đó chính xác là những gì chúng tôi làm và chúng tôi giúp khách hàng của chúng tôi làm. Chúng tôi không phải là những người duy nhất - chúng tôi có thể suy luận rằng ít nhất Google cũng làm điều này cho tất cả các máy của họ (sắp có tài liệu tham khảo.)

Bây giờ nếu bạn có khả năng xây dựng lại mỗi máy từ đầu, một số điều bạn có thể thay đổi là gì?

Dự án tự bảo vệ hạt nhân đã cho phép điều này thông qua việc sắp xếp lại ngẫu nhiên các cấu trúc hạt nhân: https://lwn.net/Articles/722293/ . Bài viết này cũng chỉ ra cuộc trao đổi nổi tiếng nơi Linus Torvalds gọi đó là nhà hát bảo mật, nhưng tác giả của dự án (người làm việc tại Google) nhận xét, "Chà, Facebook và Google không xuất bản các bản dựng kernel của họ. :)"

Điều này dẫn đến sự tin tưởng rằng ít nhất Google thực hiện điều này và coi nó hữu ích. Chúng ta có thể làm THÊM các kiểu tranh giành trong một tập đóng không? Ở cấp độ cơ bản nhất tại sao virus Windows không chạy trên Linux hoặc Mac? Bởi vì các định dạng là khác nhau. Đó là tất cả x86 bên dưới, nhưng nó không giống nhau. Chà, nếu hai Linux khác nhau theo cách tương tự thì sao? Windows vs Linux không phải là "obfuscation" chỉ vì chúng ta không có nhiều cách để làm cho Linux khác với Windows như với Linux. Nhưng nó không phải là không thể, và nó thậm chí không khó lắm. Thực hiện phương pháp của KSPP và áp dụng nó cho các tòa nhà cao tầng, sau đó biên dịch lại mọi thứ trên đỉnh so với các tòa nhà đó. Điều đó sẽ rất khó phá vỡ - ít nhất là không theo kiểu bay bổng.

Câu hỏi của bạn là về việc đổi tên biểu tượng (tên của các tệp thực thi, thư viện, v.v.) Điều này có hai khía cạnh: (a) nó có hữu ích không? (b) Nó có thể được thực hiện đáng tin cậy?

Chúng tôi đang tìm cách giải quyết PHP tiêm mã một lần và mãi mãi. Mặc dù vậy HackerNews sẽ khiến bạn tin , PHP tiêm mã không phải là một vấn đề được giải quyết bên ngoài bảng tin internet. Cuộc sống thực PHP nhà phát triển, quản trị viên và người dùng phải tiếp xúc với số lần tiêm mã liên tục.

Vì vậy, chúng tôi đã bắt đầu thử Polyscripting (Nguồn mở được cấp phép MIT): https://github.com/polyverse/polyscripted-php

Chúng tôi chia sẻ công khai điều này để thu hút phản hồi và chúng tôi điều hành hai trang web, polyscripted.comnonpolyscripted.com , thực hiện chính xác những gì bạn mong đợi dựa trên tên của họ. Chúng tôi cũng đã thuê các pentesters để cố gắng phá vỡ nó.

Và tôi mới bắt đầu thử nghiệm các thư viện dùng chung, có thể thực hiện được và đổi tên biểu tượng xuất khẩu trên một tập đóng (ví dụ trong bộ chứa docker). Cá nhân tôi không nghĩ rằng điều này làm tăng thêm giá trị, nhưng nó sẽ thêm một chút chứ? Tôi nghĩ vậy. Vì vậy, nó đi xuống chi phí. Nếu bạn có thể nhận được ít giá trị cho chi phí thậm chí littler, tại sao không làm điều đó? Đó chính xác là lý do tại sao tất cả chúng ta đều có ASLR - nó không thực sự là biện pháp bảo vệ tốt nhất kể từ bánh mì cắt lát, nhưng nếu bạn đã có mã có thể di chuyển được và dù sao bạn cũng sẽ sắp xếp lại nó, tại sao KHÔNG đẩy nó đến giới hạn và ngẫu nhiên hóa nó?

Nói tóm lại, cách tiếp cận mà bạn mô tả đang được nhiều người cố gắng (bao gồm Google, Facebook, nhân Linux, v.v.), cùng với nhiều học giả thuộc lĩnh vực Move Target Defense, và một số công ty như chúng tôi, những người như chúng tôi ' đang cố gắng để làm cho nó tiêu thụ tầm thường như ASLR.

2
Archis Gore

Tôi sẽ nói làm thế nào tôi nhìn thấy điều này từ quan điểm của hacker.

Chắc chắn, nếu bạn sẽ đổi tên tất cả các tiện ích - nó sẽ khiến mọi thứ trở nên khó khăn hơn và ít thoải mái hơn với tôi, nhưng tôi có thể làm gì?

  1. Nếu tôi đã có quyền truy cập vào Shell trên hệ thống, tôi sẽ chỉ tải lên busybox (tất cả các tiện ích cơ bản trong một nhị phân) hoặc toàn bộ nhị phân tôi cần cho các hoạt động cơ bản.

  2. Để leo thang các đặc quyền hơn nữa, tôi có thể cần phải tìm kiếm các nhị phân gốc suid, và chỉ có một vài trong số chúng (Sudo, mount, v.v.). Hacker không thể tải lên các tệp như vậy (trừ khi anh ta đã root). Hệ thống linux nhỏ đơn giản của tôi chỉ có 24 mã nhị phân. Rất dễ dàng để thử từng cái một cách thủ công.

Nhưng dù sao, tôi đồng ý, điều này sẽ làm cho việc hack hộp này trở nên khó khăn hơn. Sẽ rất đau khi sử dụng (hack) hệ thống này, nhưng có thể. Và hacker hoạt động trên hệ thống hàng giờ hoặc ngày hoặc tháng ... nhưng quản trị viên/người dùng có thể làm việc trên hệ thống trong nhiều năm và không thể nhớ tên ha7TrUO và RRI6e29. Có thể thậm chí không ai sẽ cố gắng hack hệ thống, nhưng quản trị viên sẽ phải chịu đựng mỗi ngày.

Nhưng ... nếu bạn bảo mật quá cao nhưng không thoải mái cho người dùng/quản trị viên - thực tế thì bạn thường làm cho bảo mật thấp hơn. Giống như nếu bạn thực thi các mật khẩu phức tạp với hơn 20 ký tự - rất có thể mật khẩu sẽ được ghi trên các ghi chú sau trên màn hình. Nếu bạn sẽ làm cho hệ thống bị xáo trộn như vậy - sẽ rất khó để làm việc trên nó cho người dùng tốt. Và họ sẽ phải làm một số điều để làm cho cuộc sống của họ dễ dàng hơn. Ví dụ, họ có thể tải lên tệp nhị phân busybox của họ. Tạm thời. Và họ sẽ quên nó hoặc sẽ để nó ở đó một cách có chủ ý (vì họ dự định sẽ sử dụng nó sau này).

1
yaroslaff

Nó thực sự xảy ra, bởi vì các kết nối ssh được mã hóa. Thay đổi tên của một số nhị phân cốt lõi không thực hiện được gì nhiều hơn thế này. Ngoài ra, nó sẽ gây ra rất nhiều hỗn loạn: ví dụ: bất kỳ tập lệnh nào dựa trên các tiện ích này đều được hiển thị không sử dụng được, hoặc bạn sẽ cần phải có một loại "trình khử rung" proxy nào đó, chắc chắn sẽ trở thành một vectơ tấn công. Tuy nhiên, tôi đã thấy một số máy chủ trong tự nhiên không cho phép đăng nhập root, buộc phải sử dụng Sudo thay thế. Tên người dùng của sudoers vẫn còn hơi bí mật. Tôi không chắc nó an toàn đến mức nào, nhưng tôi không phải là chuyên gia.

0
galaktycznyseba

Tại sao tất cả các cửa không có mười lỗ khóa, chỉ một trong số đó thực sự hoạt động cho chìa khóa hoặc khóa chọn? Trả lời: chủ yếu là sự phiền phức không đáng giá thêm mười giây thời gian của một tên trộm.

Nếu có hàng triệu duy nhấtđược tạo riêng rẽ hệ điều hành mã nguồn, việc che khuất có thể là phổ biến. Mặc dù là một vấn đề thực tế, chúng tôi có khoảng bốn cơ sở mã duy nhất được sử dụng phổ biến - tất cả thông tin rò rỉ về bản thân theo thời gian sự kiện và đối với một số chức năng HĐH cấp thấp nơi các nhà sản xuất chip cung cấp trình tự bitcode máy được quy định để kích hoạt hoặc truy cập một số tính năng cpu nhất định, chúng tất cả có khả năng có các chuỗi ngắn chứa chính xác cùng một mã.

0
Dusty