thái

trong bài trước, tôi có nói, có nhiều trường hợp vì ràng buộc của các mục tiêu kinh doanh, chúng ta không thể vá lỗi , dù lỗi đó có nguy hiểm đến đâu đi chăng nữa. điều này thoạt nghe thì thấy hết sức nguy hiểm, nhưng nếu suy nghĩ kỹ, chúng ta sẽ thấy, sự thực là chúng ta đã, đang và sẽ sống với những hệ thống có lỗi nghiêm trọng. khi một hệ thống nào đó bị tấn công, các *chuyên gia bảo mật* sẽ thường đổ lỗi sẽ cho đám sysadmin không chịu vá lỗi. "đã có bảng vá từ vài tháng trước, nhưng họ không chịu vá, để rồi bây giờ bị tấn công là phải rồi". đúng là việc vá lỗi là việc nên làm, nhưng lỗi không phải ở đám sysadmin. một sự thật đáng buồn là có quá nhiều lỗ hổng bảo mật. mỗi tuần tôi nhận được một bản báo cáo từ US-CERT về số lỗ hổng bảo mật đã được phát hiện trong tuần. đây là danh sách trong tuần vừa rồi , chỉ tính riêng lỗi critical thôi là đã 25, còn tổng số là 52 lỗi tất cả. để an toàn, sysadmin phải vá tất cả lỗi. để tấn công thành công, attacker chỉ cần khai thác thàn...

trong vụ lỗi của máy chủ DNS , tôi thấy nhiều bạn cứ thắc mắc tại sao tôi nói tự vì kiểm tra là phải kiểm tra xem có người sử dụng dịch vụ của máy chủ DNS có được bảo vệ an toàn hay không, còn việc vá hay không vá là việc tính sau. . cái ý tưởng "có lỗi thì phải vá" thường xuất hiện ở một số bạn nghĩ là mình hiểu về bảo mật nhưng sự thật thì kô hiểu được bao nhiêu. bản thân tôi cũng đã phải mất một thời gian dài mới ngộ được ra vấn đề này, thôi thì hôm nay chia sẻ ở đây. "có lỗi trong phần mềm tôi đang sử dụng, nên tôi cập nhật nó", một lý lẽ xem ra rất thuyết phục, nếu như không có các ràng buộc từ phía business. mục tiêu cốt lõi và cuối cùng của một hệ thống không phải là để vá hết lỗi, mà là để phục vụ những yêu cầu của người sử dụng, như họ mong đợi, theo đúng thiết kế ban đầu của hệ thống. đôi khi, chính cái ràng buộc, chính cái yêu cầu cốt lõi này, làm cho chúng ta phải chấp nhận vận hành một hệ thống, mà trong đó, chúng ta biết là có lỗi có thể bị khai thác. ...

tranh luận một hồi với các bác ở bkis, tôi phát hiện ra được vài chỗ mà tool của các bác bkis sẽ làm sai , false negative hay false positive: 1. client --> A --> B --> Authorative DNS servers * A là dns cache thuộc quyền kiểm soát của sysadmin, được cấu hình để forward recursive query đến B, một dns cache nằm ngoài tầm của sysadmin. * false negative sẽ xảy ra khi A đã vá, nhưng B chưa vá. Công cụ của bkis sẽ báo là an toàn, nhưng thực tế tất cả client sử dụng A đều đứng trước nguy cơ bị tấn công. * false positive sẽ xảy ra khi A không vá, nhưng B đã vá. Công cụ của bkis sẽ báo là không an toàn, yêu cầu vá (không phải lúc nào cũng muốn vá là vá :-p), nhưng thực tế tất cả client sử dụng A đều an toàn trước loại tấn công này. Trong cả hai trường hợp, cách làm của tôi đưa ra đều thông báo chính xác là bạn có đang an toàn hay không an toàn (lưu ý là nó quan tâm đến người sử dụng, bất kể DNS có được vá hay chưa vá). Và nó áp dụng được cả cho người dùng bình thường lẫn sysadmi...

If you read Dan Kaminsky's researchs over the past few years, you'd probably know that Dan knows many DNS tricks. One of these is the CNAME trick that Dan mentioned in the Wired interview . He has talked about this trick back to 2007 as below: 1. CNAME Records: DNS Aliases - Instead of returning an address, return what the "Canonical", or Official Name was, and then the address of that Canonical Name - If you are allowed to be the resolver for that canonical name, your additional record overrides whatever's already in the cache, even if the TTL hasn't expired yet * It's not a bug. * Works against most, but not actually all name servers 2. Demo $ dig 1.foo.notmallory.com ;; ANSWER SECTION: 1.foo.notmallory.com . 120 IN CNAME bar.foo.notmallory.com bar.foo.notmallory.com . 120 IN A 10.0.0.0 $ dig bar.foo.notmallory.com bar.foo.notmallory.com . 111 IN A 10.0.0.0 $ dig 2.foo.notmallory.com...

Gửi các bạn của tôi, mới đây một lỗ hổng bảo mật cực kỳ nghiêm trọng được phát hiện trong hệ thống DNS, xương sống của toàn bộ Internet. Tận dụng lỗ hổng này, kẻ xấu có thể tấn công để đánh cắp tất cả thông tin trên Internet của bạn, chẳng hạn như chiếm quyền điều khiển blog của bạn, chôm mật khẩu để đọc trộm email hay giả danh bạn để chat trên Yahoo! Messenger. Tôi nhắc lại, khi khai thác thành công lỗ hổng này, kẻ xấu hoàn toàn có thể chiếm quyền điều khiển cuộc sống online của bạn. Entry này được viết để cung cấp thêm cho các bạn những thông tin cần biết về lỗ hổng này, cũng như các phương pháp phòng chống tạm thời, cho đến khi có giải pháp triệt để từ phía các ISP ở VN. --- Giới thiệu về DNS DNS viết tắt của Domain Name System, là hệ thống quản lý việc ánh xạ giữa địa chỉ của máy tính trên Internet với tên của chúng. Trên Internet, mỗi máy tính đều được cấp một địa chỉ riêng biệt, thường được gọi là IP address, tạm dịch là địa chỉ IP (IP viết tắt của Internet Protocol, giao thức...

See these links for details: http://www.kb.cert.org/vuls/id/800113 http://isc.sans.org/diary.html?storyid=4687

(entry được viết trong một đêm mưa gió bão bùng, sau khi khổ chủ đã bị rớt ví và mất hết tiền trong đó ) Nếu xem x là đơn vị đo cảm xúc của con người, cộng thêm x nghĩa là vui hơn, trừ đi x nghĩa là buồn hơn, thì mất một số tiền bao giờ cũng trừ nhiều x hơn số x được cộng khi tự nhiên được đúng số tiền đó. Các nhà tâm lý học thấy rằng, với cùng một số tiền, nếu rớt mất, người ta sẽ buồn gấp 2 đến 2.5 lần niềm vui mà họ có được, nếu họ nhặt được số tiền đó. Nói cách khác, nếu làm rớt 10 triệu, thì để bù lại nỗi đau này, người ta phải lượm được 20-25 triệu. Thực tế cũng cho thấy, đối với một người, việc làm ra được 1 tỉ sẽ hạnh phúc hơn rất nhiều so với làm ra 10 tỉ, rồi thua lỗ 9 tỉ, mặc dù tài sản cuối cùng của hai trường hợp là như nhau. Bởi lẽ cái hạnh phúc làm ra 9 tỉ chẳng thể bù lại được cho cái cảm giác đau đớn bị thua lỗ 9 tỉ. Điều này cũng giải thích tại sao trong các trò đỏ đen, người thua bao giờ cũng *máu me* hơn người thắng. Người thua thường có xu hướng ngày càng đặt cược ...