Messages posted by: manthang

CBC (Cipher-block chaining) mode trong SSL/TLS là vấn đề được khai thác trong vài kiểu tấn công trước giờ như padding oracle [1], BEAST [2], Lucky 13 [3]. Kể từ đó thì RC4 là loại mã dòng (stream cipher) được khuyến cáo sử dụng để thay thế CBC-mode. RC4 trong giao thức WEP (Wired Equivalent Privacy) đã bị phá vỡ cách đây khá lâu [4] nhưng cách này không có hiệu quả với cách áp dụng RC4 trong TLS. Thực ra an toàn của RC4 trong TLS đã được cảnh báo từ trước nhưng tới giờ mới có một nhóm nghiên cứu hiện thực hóa nguy cơ này một cách rõ nét hơn [5].

Thông tin được cung cấp ở liên kết [5] là về một tấn công mới (chưa được đặt tên) phá vỡ RC4, là thuật toán hiện bảo vệ cho khoảng 50% lưu lượng TLS. Theo đó thì:

* Về phạm vi ảnh hưởng: bao gồm tất cả các phiên bản của SSL và TLS, tất cả các ciphersuite smilie

mà có sử dụng RC4, tất cả các thư viện triển khai TLS (ví dụ, OpenSSL, GnuSSL, NSS,..) mà hỗ trợ RC4.

* Về mức độ nguy hại: giúp kẻ thi triển tấn công này có thể khôi phục một lượng giới hạn plain-text trong toàn bộ cipher-text stream. Mặt khác, kẻ tấn công cần có đủ thời gian và tài nguyên để khiến máy nạn nhân tạo ra được một lượng session cần thiết. Nói như vậy không có nghĩa là tấn công này không đáng để lưu tâm vì theo các tác giả thì qua thời gian tấn công này sẽ được cải thiện thêm.

* Các biện pháp đối phó được đưa ra là:
- Trở lại CBC-mode ciphersuite đã được vá để chống lại BEAST, Lucky 13. Nhiều thư viện triển khai TLS 1.0/1.1 đã cập nhật bản vá này.
- Chờ RC4 được điều chỉnh lại.
- Chỉnh sửa phản ứng của web browser.
- Chuyển sang sử dụng AEAD ciphersuites như AES-GCM tuy hiện chưa được áp dụng rộng rãi nhưng đây là phương án được khuyến cáo cao nhất.

Mọi người có thể xem thêm bài nói về tấn công này tại đây [6] và đây [7].

Tham khảo:
[1] http://en.wikipedia.org/wiki/Padding_oracle_attack
[2] http://vnhacker.blogspot.com/2011/09/beast.html
[3] http://www.isg.rhul.ac.uk/tls/Lucky13.html
[4] http://eprint.iacr.org/2007/471.pdf
[5] http://www.isg.rhul.ac.uk/tls/
[6] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html
[7] http://cr.yp.to/talks/2013.03.12/slides.pdf
smilie

http://en.wikipedia.org/wiki/Cipher_suite

manthang - HVA News

Comment này bị trùng lắp với cái trên. Mình click 1 lần "gửi đi" mà dưng thành 2 bản copy. Nhờ mod xóa giúp. smilie

Cái homomorphic encryption này có lợi điểm mà người ta cho rằng nếu hiện thực được (practical) thì sẽ là lời giải cho nhiều vấn đề liên quan tới privacy, trong đó có việc xử lý dữ liệu trên cloud.

Hiện tại thì để đảm bảo privacy cho data được store trên cloud thì user có thể áp dụng encryption với key để decrypt thì chỉ có mình user đó biết. Nhưng giờ nếu muốn data đó không chỉ được store mà còn được processing/computing thì cloud provider cần biết được decryption key và như thế tính privacy đã không còn được đảm bảo nữa. Với FHE thì yêu cầu này được đáp ứng vì nó có thể giúp provider nhận vào encrypted input, tính toán trực tiếp trên input này mà không decrypt, sau đó kết quả trả về cũng là dạng encrypted nhưng chỉ có mình user có key là có thể đọc được.

Các trở ngại lớn khi muốn implement FHE trong thực tế mà người ta đang cố khắc phục là việc kích thước của data sau khi encrypt lớn hơn rất nhiều plaintext, chiều dài của key cũng lên tới hàng GB, việc decrypt cũng tốn rất nhiều thời gian. Giải đáp cho vấn đề xây dựng một hệ thống FHE hiệu quả, an toàn đã được khai thông với luận văn Ph.D của Craig Gentry vào năm 2009 [1] và thú vị là GS Dan Boneh chính là người hướng dẫn cho Gentry.

[1]: http://crypto.stanford.edu/craig/craig-thesis.pdf

heroandtn3 wrote:

Chào anh manthang,

Đúng là em đã bỏ qua từ khóa quan trọng "theoretical". Tuy nhiên, giả sử người ta triển khai được và nếu giải quyết được bài toán thời gian tính thì vẫn còn một vấn đề là không thể sử dụng E[query] để thu thập thông tin tìm kiếm được. Như vậy thì vẫn vô lý vì Google sao lại bỏ qua thông tin béo bở như vậy được?

Một giả sử khác là trong trường hợp không cần thu thập thông tin tìm kiếm (thì giáo sư phải minh họa bằng một trường hợp khác Google) thì phương pháp này có những lợi ích gì? Em nghĩ lợi ích đầu tiên là bỏ qua được giai đoạn trao đổi khóa.

-sh

Mình cũng không rõ Giáo sư lấy Google Search ra làm ví dụ là có dụng ý gì. Theo mình thì lợi điểm của POC là ở chỗ giúp đảm bảo tính privacy của thông tin/yêu cầu mà người dùng gửi cho nhà cung cấp. Mình có gửi thảo luận này lên trang TinSang.net thì mới biết thực ra POC có tên gọi chính thức đẩy đủ là Fully Homomorphic Encryption (FHE) hay ngắn gọn hơn là Homomorphic Encryption. Ý tưởng về FHE thì không hề mới nhưng 2-3 năm trở lại đây thì mới có những nghiên cứu đột phá hơn nhằm hiện thực và tối ưu hóa ý tưởng này.

Bạn có thể đọc thêm bài sau hay google cũng ra rất nhiều bài liên quan tới FHE:
http://www.americanscientist.org/issues/pub/2012/5/alice-and-bob-in-cipherspace

Đây là video chứa nội dung mà heroandtn3 đang đề cập:
https://www.youtube.com/watch?feature=player_embedded&v=zSUfNMC7ajQ

Mình có đọc lại transcript/subtitle của video này thì có đoạn như sau:

"
Okay so, these are magical kind of encryption schemes. Their fairly recent, this is only a new development from about two or three years ago, that allows us to compute unencrypted data, even though we don't really know what's inside the encryption. Now, before you rush off and think about implementing this, I should warn you that this is really at this point just theoretical, in the sense that running a Google search on encryption data probably would take a billion years.
"
Vậy nên mình nghĩ hiện tại thì cơ chế Privately Outsourcing Computation chưa được triển khai trong Google Search mà ý của giáo sư Dan Doneh ở đây chỉ là lấy ví dụ về khả năng ứng dụng thực tế của POC trong tương lai.

nhiepnhuphong wrote:

Em thấy mỗi lần đăng nhập vào diễn đàn thì có 2 lựa chọn là http/https. Vậy thì mình nên chọn cách đăng nhập nào?
Xin cám ơn.

Nếu coi trọng áp dụng HTTPS cho các site phổ biến và quan trọng thì bạn thử add-on này (cho FF, Chrome):
https://www.eff.org/https-everywhere

Nó làm việc bằng cách chứa sẵn 1 list (hiện tới gần 1500) các site có support HTTPS. Khi bạn ghé các site nằm trong list thì dù không gõ đằng trước URL thì add-on này cũng tự động rewrite request để connect tới site đó qua HTTPS cho bạn.

Chúc mừng anh mrro và đồng nghiệp Rizzo, em thắc mắc không biết CRIME là viết tắt của cụm từ nào nhỉ?

Hai nhà nghiên cứu về an toàn thông tin là Juliano Rizzo và Dương Ngọc Thái (thaidn) đang chuẩn bị để trình bày tại hội thảo Ekoparty ở Argentina vào cuối tháng này một kiểu tấn công mới có tên là CRIME nhằm vào SSL/TLS. Đây cũng là nhóm tác giả của BEAST, một kiểu tấn công nữa chống lại SSL/TLS được công bố vào cuối năm ngoái.

CRIME khai thác điểm yếu có trong một tính năng của TLS 1.0 nhưng thông tin về tính năng này hiện chưa được tiết lộ. Họ nói rằng tất cả các phiên bản của SSL/TLS – bao gồm cả TLS 1.2 đều chịu ảnh hưởng. Một khi nằm giữa kết nối của người dùng tới máy chủ Web thì họ có thể tóm các lưu lượng HTTPS được trao đổi và thực hiện giải mã cookie để chiếm phiên làm việc của người dùng. Cách mà họ chọn để có thể nằm tại vị trí chắn giữa này là nạp và thực thi đoạn mã JavaScript trong trình duyệt Web của người dùng nhưng không nhất thiết phải là JavaScript hay bất cứ plug-in nào khác vì họ nói có thể dùng mã HTML tĩnh để làm chuyện này.

Một biện pháp để khắc chế BEAST là đổi cipher suite (dùng RC4 thay cho AES) nhưng điều này không có tác dụng đối với CRIME. Các tác giả còn nói thêm rằng tính năng trong SSL/TLS mà CRIME đang khai thác chưa phải là chủ đề chính của các nghiên cứu bảo mật trong quá khứ: “Rủi ro khi triển khai tính năng này đã được thảo luận trước đây. Tuy nhiên, chúng tôi không tìm thấy bất kỳ nghiên cứu nào chỉ ra một kiểu tấn công khả dĩ hay những cố gắng để khắc phục điểm yếu này từ những người phát triển các giao thức bảo mật”, Rizzo nói.

Hiện tại, cả Firefox và Chrome đều là các trình duyệt Web chịu ảnh hưởng bởi tấn công CRIME nhưng theo các nhà nghiên cứu thì trong một vài tuần tới Mozilla và Google sẽ cung cấp các bản vá tới người dùng để khắc phục vấn đề này.

manthang – HVA News

Tham khảo:
[1] http://www.h-online.com/security/news/item/BEAST-creators-develop-new-SSL-attack-1702136.html
[2] http://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512

4 Xác định vị trí đặt chứng chỉ của Web server

Việc lựa chọn vị trí triển khai chứng chỉ cho Web server phụ thuộc vào cấu hình mạng của bạn. Dưới đây là hai trường hợp thường gặp.

Với một Web server
Nếu chỉ có một Web server hoạt động thì hiển nhiên chứng chỉ phải được đặt tại Web server đó như được thể hiện trong Hình dưới đây:

Với một nhóm các Web server
Ở cấu hình gom nhóm này, website có thể nằm trên ổ đĩa dùng chung bởi nhiều máy chủ hoặc mỗi máy chủ có ổ đĩa riêng để lưu trữ bản sao của website. Trong mỗi trường hợp thì khi người dùng kết nối tới một URL nào đó thì họ được chuyển hướng tới bất kỳ máy chủ nào trong cụm các máy chủ (cluster). Đây là cơ chế căn bằng tải cho lưu lượng mạng (Network Load Balancing) như được thể hiện trong Hình dưới đây:

Khi đó mỗi Web server trong cluster sẽ phải có một chứng chỉ SSL của riêng nó. Yêu cầu duy nhất là trường subject name của chứng chỉ cần trùng với tên miền mà Web client sử dụng để kết nối tới website.

Một sự hiểu nhầm thường gặp là cho rằng các Web server trong cluster phải có một chứng chỉ SSL cùng với khóa bí mật giống nhau. Thực ra nếu mua các chứng chỉ cho từ các tổ chức thương mại như VeriSign hay RSA thì rất có thể họ yêu cầu khách hàng cần các chứng chỉ khác nhau cho mỗi Web server.

Web Server được bảo vệ bởi ISA Server với cấu hình Server Publishing
Khi áp dụng cấu hình Server Publishing trong ISA Server thì tất cả các lưu lượng kết nối tới cổng TCP 443 mà ISA Server đang lắng nghe trên đó sẽ được chuyển hướng tới Web server nằm đằng sau firewall này (xem Hình dưới đây):

Trong cấu hình này, chứng chỉ SSL phải được cài đặt tại Web server. Tên miền trong trường Subject của chứng chỉ phải khớp với tên miền mà Web client dùng để kết nối tới giao tiếp mạng ngoài (external interface) của ISA Server. Nói cách khác, tên miền này phải được phân giải thành địa chỉ IP được gán cho card giao tiếp mạng ngoài của ISA Server. Dạng cấu hình này được cũng được hỗ trợ bởi nhiều firewall phổ biến khác của Cisco hay Checkpoint. Như vậy, yêu cầu được thỏa mãn là triển khai mã hóa dữ liệu được truyền giữa giữa hai điểm đầu cuối là Web server và Web client.

Web Server được bảo vệ bởi ISA Server với cấu hình Web Publishing
Khi áp dụng cấu hình Web Publishing, dữ liệu mà ISA Server tiếp nhận từ Web client sẽ được giải mã và kiểm duyệt bằng các bộ lọc ở tầng ứng dụng (ví dụ, URL Scanning) để phát hiện những lưu lượng Web có thể là mã độc hoặc các dạng tấn công Web khác. Có hai lựa chọn để sử dụng SSL với cấu hình Web Publishing là:

a. Triển khai SSL cho kết nối giữa hai điểm đầu cuối (End-to-End SSL)

Ở đây, SSL được thực hiện giữa Web client và ISA Server cũng như là giữa ISA Server và Web server (xem Hình dưới đây).

Hai chứng chỉ SSL khác nhau phải được cài đặt ở cả ISA Server và Web server và hai kết nối SSL tách biệt được thiết lập là:

- Kết nối SSL đầu tiên xảy ra giữa Web client và ISA Server. Trường Subject của chứng chỉ được cài tại ISA Server phải chứa tên miền mà Web client sử dụng để kết nối tới Web server, và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.

- Kết nối SSL thứ hai xảy ra giữa ISA Server và Web server. Trường Subject của chứng chỉ được cài tại Web server phải chứa tên miền hoặc địa chỉ IP giống với thiết lập Web Publishing tại ISA Server.

b. Triển khai SSL giữa Web client và ISA Server

Kết nối SSL chỉ được thực hiện giữa Web client và ISA Server (xem Hình dưới đây).

Chỉ cần một chứng chỉ SSL được cài đặt tại ISA Server. Lưu lượng HTTPS từ Web client sau khi được giải mã và kiểm duyệt bởi bộ lọc tầng ứng dụng của ISA Server sẽ được chuyển tới Web server dưới dạng HTTP (không được mã hóa) thông thường.

Ở đây, trường Subject của chứng chỉ của Web server phải chứa tên miền mà Web client dùng để kết nối tới Web server và tên miền này phải được phân giải thành địa chỉ IP mặt ngoài của ISA Server.

5 Demo cài đặt chứng chỉ SSL trên IIS 7.5 Webserver

Nếu trong mạng nội có triển khai private CA trên nền Windows Server thì các lựa chọn để cấp chứng chỉ từ CA đó là:

-- Cấp chứng chỉ cho các máy chủ web chạy IIS nằm trong domain.
-- Cấp chứng chỉ cho các máy chủ web chạy IIS không nằm trong domain.
-- Cấp chứng chỉ cho các máy chủ web không phải IIS như Apache, Lighthttpd, v.v..

Phần này sẽ trình bày 5 bước để cài đặt chứng chỉ SSL cho IIS Webserver không nằm trong Active Directory domain, bao gồm:

1. Thêm mẫu chứng chỉ Web Server tại máy Issuing CA.
2. Tạo yêu cấu cấp chứng chỉ cho website https://secure.uit.vn tại máy chủ web.
3. Gửi yêu cầu cấp chứng chỉ trên tới Issuing CA.
4. Cài đặt chứng chỉ được cấp tại máy chủ web.
5. Cấu hình máy chủ web để bật mã hóa SSL cho website.

Tải về video sau để xem hướng dẫn chi tiết các bước thực hiện:
http://www.mediafire.com/?6da17akiz1q1ez6

Nếu muốn thực hiện cài đặt chứng chỉ SSL được cấp từ các commercial CA như Verisign thì chỉ cần tham khảo các bước 4 và 5.

--manthang

Duyệt Web trên Internet và mạng nội bộ là một trong những tác vụ phổ biến nhất trong hoạt động của tổ chức và các cá nhân. Mặc định thì giao thức HTTP không thực hiện mã hóa dữ liệu truyền giữa Web server và Web client.

Tuy nhiên khi cài đặt chứng chỉ dành cho Web server thì nó sẽ triển khai giao thức SSL để đạt được hai mục đích sau:

- Web browser trên client xác minh nhận dạng của Web server bằng cách kiểm tra tính chính xác, hiệu lực của chứng chỉ của Web server.

- Mã hóa dữ liệu được truyền qua lại giữa Web server và Web browser.

Loạt bài viết gồm 2 phần này sẽ trình bày các chi tiết để triển khai chứng chỉ SSL cho Web server IIS 7.5 trên nền Windows Server 2008.

1 Giao thức SSL làm việc như thế nào

Khi một Web client kết nối tới một Web server được bảo vệ bởi SSL thì về cơ bản, quá trình xác minh nhận dạng của Web server và mã hóa dữ liệu diễn ra như sau:

1. Một kết nối SSL được khởi tạo khi người dùng gõ hoặc nhấn vào một URL mà bắt đầu bằng cụm HTTPS.

2 Khi kết nối được thiết lập, Web server sẽ gửi chứng chỉ của nó cho Web browser.

3. Để xác thực Web server, Web browser thực hiện xác minh chứng chỉ thông qua các bước kiểm tra sau:

a. Kiểm tra chuỗi chứng chỉ từ Web server lên tới Trusted Root CA.
b. Đảm bảo rằng tên trong trường Subject của chứng chỉ khớp với tên miền trong URL.
c. Đảm bảo rằng chứng chỉ của Web server vẫn còn thời gian hiệu lực.
d. Đảm bảo rằng chứng chỉ của Web server chưa bị thu hồi (không có trong CRL).

4. Nếu một trong 4 bước kiểm tra ở trên gặp thất bại thì thường Web browser sẽ hiện cảnh báo cho người dùng không nên tin tưởng Web server và có thể thêm một tùy chọn cho phép người dùng vẫn tiếp tục kết nối và trao đổi dữ liệu với Web server.

5. Nếu chứng chỉ của Web server vượt qua cả 4 bước kiểm tra trên thì Web browser sẽ trích ra khóa công khai được lưu trong chứng chỉ.

6. Web browser tạo một khóa bí mật gọi là pre-master có giá trị ngẫu nhiên với chiều dài do 2 bên thỏa thuận.

7. Web browser sử dụng khóa công khai của Web server để mã hóa khóa pre-master rồi gửi tới Web server.

8. Web server sử dụng khóa bí mật của nó để giãi mã ra khóa pre-master.

9. Phụ thuộc vào CSP được cài đặt trên Web server mà Web server và Web client sẽ sử dụng thuật toán Diffie-Hellman hoặc RSA cùng với khóa pre-master để tạo một khóa phiên đối xứng.

10. Khóa phiên đối xứng được Web server và Web client sử dụng để mã hóa dữ liệu được truyền giữa hai bên. Khóa phiên này tồn tại cho tới khi Web client hoặc Web server hủy phiên HTTPS.

Các bước Web server và Web client liên lạc thông qua SSL (hình từ Internet)

2 Các loại chứng chỉ dùng cho SSL

Khi triển khai SSL, có hai loại chứng chỉ có thể được dùng là:

Chứng chỉ cho Web server: một Web server muốn áp dụng SSL thì bắt buộc phải có loại chứng chỉ này. Nó được dùng để mã hóa khóa pre-master được Web client gửi cho Web server và đồng thời giúp xác minh nhận dạng của Web server để Web client có thể tin tưởng rằng đó không phải là Web server giả mạo được kẻ tấn công dựng lên. Chứng chỉ của Web server phải bao gồm Server Authentication OID trong extension Enhanced Key Usage.

Chứng chỉ cho Web client: Khi một Website yêu cầu người dùng kết nối tới nó phải được xác thực thì Web client có thể sử dụng loại chứng chỉ này. Tuy các kết nối SSL không ép buộc điều này nhưng nó giúp tăng độ an toàn cho Web server trong trường hợp chỉ cho phép những người dùng được xác thực (Web client của họ được cài loại chứng chỉ này) kết nối tới nó. Chứng chỉ của Web client phải bao gồm Client Authentication OID trong extension Enhanced Key Usage.

3 Chọn nhà cung cấp chứng chỉ SSL cho Web server

Việc lựa chọn sẽ nhận chứng chỉ cho Web server từ đâu (CA nào) thường dựa trên việc xem xét các Web client thuộc nội bộ hay bên ngoài tổ chức. Các client nội bộ là nhân viên hoặc đối tác mà có thể có hoặc không được cấp các tài khoản dùng trong mạng của tổ chức. Các client bên ngoài thường là các khách hàng mà không được cấp các tài khoản dùng trong mạng của tổ chức.

Thường một CA riêng tư (private CA) được xây dựng để cấp chứng chỉ cho các Web server nội bộ khi:

- Tổ chức phải tuân thủ các chính sách an ninh và chính sách chứng chỉ do họ đề ra. Trong khi đó, một chứng chỉ do một CA thương mại (như Verisign) cấp yêu cầu tổ chức phải tuân theo tập các chỉ dẫn trong CPS của CA đó.
- Tổ chức muốn giảm chi phí mua chứng chỉ từ các CA thương mại vì các Web server chỉ cần chấp nhận các kết nối từ các nhân viên và những đối tác được tin cậy khác là đủ. Trong trường hợp này, các nhân viên và đối tác được yêu cầu phải tin cậy và cài đặt chứng chỉ của các CA của tổ chức.

Thường một CA thương mại (commercial CA) được chọn để cấp chứng chỉ cho các Web server của tổ chức khi:

- Tổ chức không muốn triển khai một hạ tầng PKI nội bộ để giảm chi phí cho việc thiết kế, triển khai và quản lý CA và các chứng chỉ.
- Tổ chức sử dụng Website để bán hàng hóa và cung cấp các dịch vụ qua Internet cho nhiều đối tượng khách hàng khác nhau, và các CA thương mại mặc định đã được tin cậy bởi hầu hết các Web client. Điều này vì vậy mang lại sự thuận tiện và đảm bảo cho các giao dịch điện tử.
- Tổ chức muốn triển khai chứng chỉ EV (Extended Validation) để thanh địa chỉ của Web browser sẽ chuyển sang màu xanh và có tên của tổ chức ở bên trái. Điều này nói lên rằng CA thương mại đã bỏ thêm tài nguyên và thời gian để xác minh người sở hữu chứng chỉ SSL của website thực sự là đại diện của tổ chức. Cũng vì vậy mà chứng chỉ EV luôn mắc hơn các chứng chỉ loại thông thường.

Thanh địa chỉ của các Web browser cho biết Website sử dụng một EV certificate (hình từ Internet)

--manthang

1. File và inode

Một file là một khối dữ liệu được lưu trữ liên tục hoặc không liên tục (tình trạng dữ liệu bị phân mảnh) trên thiết bị lưu trữ như ổ cứng, ổ mềm, ổ flash,… Người dùng bình thường sẽ nhận dạng một file dựa trên tên của nó (file name).

Mỗi file được liên kết với một inode mà chứa các thuộc tính của file đó như là định dạng (text, binary,…), kích thước, ngày khởi tạo, vị trí trên thiết bị lưu trữ, chủ sở hữu, quyền truy cập,… Thông tin về file mà inode nắm giữ thường được gọi là metadata, đặc biệt inode không chứa tên file và nội dung thật sự của file.

Mỗi inode được xác định bởi một con số (inode number) , có một bảng chỉ mục (inode table) gồm inode number – vị trí inode trên thiết bị lưu trữ. Với inode number có được kernel sẽ tìm trong bảng chỉ mục này và truy cập tới nội dung của inode, bao gồm con trỏ dữ liệu từ đó truy cập tới nội dung của file mà liên kết với inode đó.

Khi một file được tạo, nó được gán một file name + một inode number là số nguyên duy nhất trong một file system. Các file name và inode number tương ứng được lưu trữ thành các mục (entry) trong thư mục, tức là thư mục thực ra chỉ là danh sách các liên kết giữa file name và inode number mà thôi.

Khi người dùng hoặc chương trình sử dụng file name để tham khảo tới một file, hệ điều hành sẽ sử dụng tên này để tìm kiếm inode tương ứng bằng cách tra cứu trong inode table rồi từ đó biết được thông tin và vị trí của file trên thiết bị lưu trữ để phục vụ cho các thao tác về sau (như chỉnh sửa nội dung của file, cung cấp thuộc tính của file,…).

Sử dụng lệnh ls -i để biết inode number của 1 file, và ls -l để biết metadata của file chứa trong inode.

Trên nhiều kiểu file system thì số lượng các inode có thể sử dụng được cố định tại thời điểm khởi tạo file system, dẫn tới việc giới hạn số lượng file mà hệ thống file có thể nắm giữ, quản lý.

2. Directory

Directory (hay folder – thư mục) trong *nix là một loại file đặc biệt, chứa danh sách các liên kết giữa tên đối tượng (file, folder, soft/hard link…) và inode number tương ứng với đối tượng đó.

Current Directory
Hay working directory (thư mục hiện hành) là thư mục mà hiện tại người dùng, chương trình đang “đứng”, tham khảo, làm việc tại đó.

Mọi user luôn luôn đang làm việc bên trong một thư mục nào đó. Chính xác hơn thì mỗi tiến trình (process) có một WK được liên kết linh động với nó. Trong Windows thì process gọi hàm GetCurrentDirectory để xác định vị trí của WK và gọi hàm SetCurrentDirectory để thay đổi WK.

Khi user hoặc process chỉ định một file mà đơn giản chỉ sử dụng tên file hoặc đường dẫn tương đối (relative path) của file thì việc tìm kiếm tới file này bắt đầu từ WK. Ví dụ trong Linux, khi mới mở Shell CLI lên để gõ lệnh thường thì ta đang đứng ở thư mục có đường dẫn tuyệt đối là
/home/user_name thì thư mục user_name là WK. Khi gõ vào

Code:

# rm foo.txt

thì lệnh này sẽ thực hiện việc xóa file foo.txt trong thư mục chủ của người dùng.

Thường có 2 cách để thể xác định WK.

Một là nhìn vào dấu nhắc lệnh (command prompt). Với bash thì dấu nhắc lệnh chứa tên người dùng, máy tính và thư mục hiện hành, ví dụ:

[uit@localhost bluesky]#

thì uit là user name, localhost là computer name và bluesky là working directory, # chỉ ra rằng đây là user root.

Cách thứ hai là sử dụng lệnh pwd (present working directory), lệnh này không có tùy chọn hay đối số để hiện đường dẫn đầy đủ của thư mục hiện hành.

WK thường được biểu thị bởi 1 dấu chấm “.” , còn 2 dấu chấm liên tiếp “..” thay cho thư mục cha của WK. Ta sẽ luôn thấy 2 mục bị ẩn này tồn tại trong mọi thư mục trên *nix bằng cách sử dụng lệnh ls -a

Directory Tree
Gọi là cây thư mục, là hệ thống các thư mục được phân cấp và trong đó có duy nhất một thư mục được gọi là thư mục cha và tất cả các mức độ thư mục con của nó. Bất kỳ thư mục nào cũng có thể là điểm bắt đầu cho 1 cây thư mục của riêng nó nếu nó chứa ít nhất 1 thư mục con.

Hầu hết các hệ điều hành ngày nay đều sử dụng cấu trúc cây thư mục cho việc tổ chức file. Với các hệ *nix chỉ có duy nhất một thư mục gốc (root directory, ký hiệu là /) mà từ đó các cây thư mục khác sinh ra từ đây. Con các hệ Microsoft Windows thì có nhiều thư mục gốc độc lập với nhau có các tên như C: , D: , E: ,…

Lệnh du (disk usage) trong Linux là một tiện ích thu thập thông tin về các cây thư mục, bao gồm tổng không gian đĩa mà một cây chiếm dụng, tên và kích thước mỗi nhánh hoặc file trong cây đó.

3. Hard Link

Hard link (HL) là tên gọi khác cho một file đang tồn tại trên file system.

Một file có thể có nhiều HL và mỗi HL cũng có thể có nhiều HL cho nó. Tuy nhiên, không thể tạo cho HL cho thư mục và cũng không thể tạo ra HL cho một file không nằm cùng phân vùng với HL. Ví dụ, không thể tạo HL trên phân vùng A cho một file nằm trên phân vùng B.

Hệ điều hành không phân biệt giữa file name ban đầu của file với các HL được tạo ra sau này cho file đó. Cả file name và các HL này đều trỏ tới cùng một inode, và vì mỗi inode có một số inode number là duy nhất trong một file system nên HL không thể làm việc chéo qua các phân vùng khác nhau.

Sử dụng lệnh ln để tạo HL. Ví dụ dưới đây sẽ tạo một HL có tên hlink1 cho một file có tên file1, cả 2 file này đều nằm trong cùng thư mục hiện hành.

Code:

$ ln file1 hlink1

File name ban đầu và tất cả các HL tới file đều chia sẻ chung inode, có thể thấy rõ điều này bằng cách sử dụng lệnh ls –i. Câu lệnh dưới đây sẽ cho thấy inode number của file1 và hlink1 là giống nhau:

Code:

$ ls -i file1 hlink1

Số lượng các HL cho 1 file được thể hiện trong cột thứ 2 trong output của lệnh ls –l. Con số này là tổng của filename ban đầu và HL và số này giống nhau cho target file và mỗi HL, ví dụ:

Code:

$ ls -l file1 hlink1

Sử dụng lệnh sau để tìm các file có nhiều hơn một HL

Code:

$ find -type f -links +1

Thử chỉnh sửa nội dung của target file và lưu lại. Sau đó mở HL của target file đó lên sẽ những thay đổi được giữ nguyên.

Lệnh rm thực sự làm gì?
Khi sử dụng lệnh rm để xóa file thì thực chất là làm giảm đi một HL. Khi số lượng HL giảm còn 0 thì không thể truy cập tới nội dung của file được nữa (mặc dù nội dung đó vẫn tồn tại trên thiết bị lưu trữ) vì hệ điều hành không còn cách nào để tham khảo tới file này. Dữ liệu của file chỉ thực sự bị mất khi vị trí của nó bị ghi đè bởi các file mới. Điều này giải thích tại sao ta vẫn có thể khôi phục dữ liệu vừa bị xóa và không có dữ liệu nào được tạo ra trên vị trí của dữ liệu cũ.

HL cũng như shortcut trong Windows là cho phép truy cập tới file, chương trình, script từ một vị trí khác thuận tiện hơn.

4. Symbolic link

SL thì hơi khác chút so với HL đó là có thể tạo SL cho 1 thư mục cũng như là tạo SL các file và thư mục trên các phân vùng khác. Tuy nhiên, hạn chế của SL so với HL là khi xóa target file thì SL không có tác dụng nữa. Sử dụng cú pháp lệnh sau để tạo SL

Code:

$ ln -s target_file SL_name

–manthang

quanghoacmd wrote:

CHo mình hỏi có phải nếu chỉ có nhu cầu cài đặt server giao diện dòng lệnh ( ko cần đồ hoạ ) thì chỉ cần tải CentOS-6.3-x86_64-bin-DVD1.iso ( 4GB) ghi ra đĩa là OK phải ko ?
Vì em thấy nếu ghi đủ thì phải tải thêm CentOS-6.3-x86_64-bin-DVD2.iso (1G) .
Có phiên bản nào nhỏ gọn hơn ko ạ ? e nhớ ngày trước có loại Single Server CD gọn lắm, giờ thì ko thấy Centos nó ra nữa.

Vào đây http://mirror-fpt-telecom.fpt.net/centos/6.3/isos/i386/
và tải bản minimal là nhỏ gọn nhất.

phuongnvt wrote:

SMS giới hạn bao nhiêu ký tự vậy anh/em ?

Trích từ link này: http://wammu.eu/docs/manual/gammu/

- Send text message up to standard 160 chars:
Code:

echo "All your base are belong to us" | gammu sendsms TEXT 123456

- Send long text message:
Code:

echo "All your base are belong to us" | gammu sendsms TEXT 123456 -len 400

p.n.t wrote:

Hi all !

Mình có 1 website bán hàng qua mạng sử dụng php với webserver là apache. Hiện nay mình muốn tích hợp https cho phần thanh toán, tuy nhiên mình chưa biết cách làm như thế nào, mong muốn của mình là chỉ khi khách hàng
login thanh toán thì mới sử dụng https, còn các trang khác thì vẫn sài http (giống phần thanh toán của trang www.lazada.vn )
Mong mọi người chỉ giúp

Thanks.

bạn google với từ khoá: force SSL URL Apache

ví dụ:
https://www.google.com/#hl=en&safe=off&sclient=psy-ab&q=apache+force+ssl+url&oq=apache+ssl+url&gs_l=hp.1.3.0i30l2j0i8i30l2.2461.5411.2.13620.4.4.0.0.0.0.246.576.2j1j1.4.0.les%3B..0.0...1c.-dz2lw5wNK4&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&fp=b6fbdf4e16b0ea8&biw=1241&bih=615

tham khảo:
http://stackoverflow.com/questions/3307025/force-https-on-certain-urls-and-force-http-for-all-others

thuank51cc wrote:

Dear!

Thanks bạn! Đúng là do mình dùng centos5.x nên usb ko thể nhận được như vậy.
Cho mình hỏi một chút bạn đã thử test phần time repeat của report nagios khi có lỗi chưa?

không hiểu time repeat trong Nagios bạn nói ở trên là gì?
nhân tiện, nhờ mod/admin xoá giúp em mấy comment bị trùng lắp (#15 -> #17) ở trên. smilie

Ngày tàn của giao thức MS-CHAPv2

Tại hội thảo Defcon 20 đang diễn ra tại Las Vegas, hai nhà nghiên cứu Moxie Marlinspike và David Hulton đã có bài thuyết trình về kỹ thuật tấn công MS-CHAPv2 với tỉ lệ thành công lên tới 100%. Giao thức xác thực này hiện vẫn còn được dùng nhiều trong các kết nối PPTP VPN và môi trường WPA2 Enterprise.

Dưới đây là các khuyến cáo của Moxie [1]:

1. Tất cả người dùng và nhà cung cấp các giải pháp PPTP VPN cần lập tức chuyển sang sử dụng các giao thức khác thay cho PPTP.
2. Các tổ chức, doanh nghiệp đang sử dụng MS-CHAPv2 làm phương thức xác thực hai chiều cho các kết nối tới các máy chủ WPA2 RADIUS cần lập tức chuyển sang sử dụng giao thức khác.

MS-CHAPv2 giờ đã bị phá vỡ, có hai lựa chọn thay thế được đề nghị là cấu hình OpenVPN hoặc IPSec sử dụng chứng chỉ số (thay vì IPSec-PSK).

Mã nguồn của ChapCrack, công cụ dùng để thi triển tấn công này hiện có trên GitHub [2].

(Theo isc.sans.edu)
http://isc.sans.edu/diary/End+of+Days+for+MS-CHAPv2/13807

Tham khảo:
[1] https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/
[2] https://github.com/moxie0/chapcrack

thuank51cc wrote:

Hi ca nha`!

E sử dụng máy ảo connect đến usb 3g. Nhưng nó chỉ nhận ở dạng storage mà không hề chuyển sang chế độ
modem. E đã cài đặt các gói modem-switch.
tuy nhiên khi check lại: dmesg | grep GSM
output chỉ hiện ra:
USB Serial support registered for GSM modem (1-port)
USB version v0.7
không thông báo :
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Có bác nào biết hoặc đã gặp lỗi này không ạ. e search hoài không thấy. thanks for help!

1. phiên bản kernel của distro bạn đang dùng? ở bài này mình dùng CentOS 6.2 với kernel version = 2.6.32. với kernel cũ quá như 2.6.18 mà mình từng test với CentOS 5.5 thì không nhận được USB 3G.
2. nếu trong USB có gói driver cho Linux thì cài thêm thử
3. model USB 3G của bạn? mình test OK với hàng của Huewei (3G Viettel) và ZTE.

thuank51cc wrote:

Hi ca nha`!

E sử dụng máy ảo connect đến usb 3g. Nhưng nó chỉ nhận ở dạng storage mà không hề chuyển sang chế độ
modem. E đã cài đặt các gói modem-switch.
tuy nhiên khi check lại: dmesg | grep GSM
output chỉ hiện ra:
USB Serial support registered for GSM modem (1-port)
USB version v0.7
không thông báo :
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Có bác nào biết hoặc đã gặp lỗi này không ạ. e search hoài không thấy. thanks for help!

1. phiên bản kernel của distro bạn đang dùng? ở bài này mình dùng CentOS 6.2 với kernel version = 2.6.32. với kernel cũ quá như 2.6.18 mà mình từng test với CentOS 5.5 thì không nhận được USB 3G.
2. nếu trong USB có gói driver cho Linux thì cài thêm thử
3. model USB 3G của bạn? mình test OK với hàng của Huewei (3G Viettel) và ZTE.

thuank51cc wrote:

Hi ca nha`!

E sử dụng máy ảo connect đến usb 3g. Nhưng nó chỉ nhận ở dạng storage mà không hề chuyển sang chế độ
modem. E đã cài đặt các gói modem-switch.
tuy nhiên khi check lại: dmesg | grep GSM
output chỉ hiện ra:
USB Serial support registered for GSM modem (1-port)
USB version v0.7
không thông báo :
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Có bác nào biết hoặc đã gặp lỗi này không ạ. e search hoài không thấy. thanks for help!

1. phiên bản kernel của distro bạn đang dùng? ở bài này mình dùng CentOS 6.2 với kernel version = 2.6.32. với kernel cũ quá như 2.6.18 mà mình từng test với CentOS 5.5 thì không nhận được USB 3G.
2. nếu trong USB có gói driver cho Linux thì cài thêm thử
3. model USB 3G của bạn? mình test OK với hàng của Huewei (3G Viettel) và ZTE.

thuank51cc wrote:

Hi ca nha`!

E sử dụng máy ảo connect đến usb 3g. Nhưng nó chỉ nhận ở dạng storage mà không hề chuyển sang chế độ
modem. E đã cài đặt các gói modem-switch.
tuy nhiên khi check lại: dmesg | grep GSM
output chỉ hiện ra:
USB Serial support registered for GSM modem (1-port)
USB version v0.7
không thông báo :
option 1-1:1.0: GSM modem (1-port) converter detected
usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Có bác nào biết hoặc đã gặp lỗi này không ạ. e search hoài không thấy. thanks for help!

1. phiên bản kernel của distro bạn đang dùng? ở bài này mình dùng CentOS 6.2 với kernel version = 2.6.32. với kernel cũ quá như 2.6.18 mà mình từng test với CentOS 5.5 thì không nhận được USB 3G.
2. nếu trong USB có gói driver cho Linux thì cài thêm thử
3. model USB 3G của bạn? mình test OK với hàng của Huewei (3G Viettel) và ZTE.

Nếu sử dụng thiết Android hoặc iOS để kết nối tới máy chủ Microsoft Exchange qua môi trường Wi-Fi thì dữ liệu và các thiết lập trên thiết bị của bạn có thể bị phá hủy hoặc thậm chí tài khoản email của bạn có thể bị đánh cắp. Nhà nghiên cứu Peter Hannay đến từ Viện Nghiên cứu An toàn Thông tin thuộc trường Đại học Edith Cowan của Úc đã mô tả và chứng minh phương thức tấn công chống lại các máy chủ Exchange này tại Hội thảo Bảo mật Black Hat ở Las Vegas vào hôm qua.

Các thiết bị Android và iOS khi khởi tạo kết nối tới các máy chủ Exchange có sử dụng một chứng chỉ SSL tự ký thì vẫn sẽ chấp nhận truyền thông với các máy chủ đó ngay cả khi các chứng chỉ SSL của chúng là giả mạo.
“Điểm chính yếu ở đây là cách mà các thiết bị này xử lý quy trình mã hóa và xác minh chứng chỉ, vì vậy mà đây là lỗi thuộc về các hàm hiện thực giao thức SSL được cài đặt trên các thiết bị này.”, Hanney nói với website Ars trước khi trình diễn kỹ thuật này tại Black Hat vào hôm thứ 5. “Nhẽ ra những thiết bị này nên phản ứng rằng chứng chỉ SSL thực sự không hợp lệ, không có chi tiết nào là xác thực. Và “tôi” sẽ không kết nối tới máy chủ đó đâu.”

Hannay đã phát triển một phương thức tấn công mà sử dụng mạng Wi-Fi để xây dựng một máy chủ Exchange giả mạo với một chứng chỉ tự ký (self-signed certificate) thay vì chứng chỉ được cấp phát bởi một CA đáng tin cậy như Verisign. Các thiết bị là đích nhắm của cuộc tấn công này hiện diện trên cùng mạng với kẻ tấn công sẽ gặp thất baị khi cố gắng kết nối tới máy chủ Exchange mà nó thường dùng. Thay vào đó, nó sẽ khởi tạo phiên truyền thông với máy chủ mạo danh của Hannay.

Sử dụng một chứng chỉ SSL cho máy chủ Exchange là nhằm bảo vệ nó trước kiểu tấn công Man-in-the-Middle. Các thiết bị được mong đợi là chỉ nên kết nối khi chứng chỉ của máy chủ mang một khóa công khai được xác thực. Nhưng điều này không phải lúc này cũng xảy ra, nhà nghiên cứu Hannay nói.

Cụ thể, các thiết bị Android luôn chấp nhận kết nối tới máy chủ Exchange với một chứng chỉ tự ký ngay cả khi chứng chỉ SSL của nó bị làm giả hoặc chứa các thông tin không có hiệu lực. Các thiết bị iOS thì xử lý khôn ngoan hơn tí trước bài kiểm tra của Hannay: chúng đưa ra thông điệp cảnh báo nhưng vẫn cho phép người dùng bỏ qua và tiếp tục kết nối. Ngược lại, các thiết bị chạy Microsoft Windows Phone đưa ra thông báo lỗi và đồng thời từ chối kết nối của người dùng.

Sau khi thiết bị kết nối tới máy chủ giả mạo được sử dụng trong thí nghiệm của Hannay thì một tập tin script được viết để thi hành từ xa một câu lệnh nhằm xóa nội dung và khôi phục các thiết lập mặc định trên thiết bị. Kẻ tấn công cũng có thể lấy được các tài khoản của người dùng để đăng nhập trái phép về sau.
“Điều quá đơn giản, dễ làm này thực sự làm tôi lo lắng,” Hannay nói. Toàn bộ cuộc tấn công chỉ cần tới 40 dòng mã Python và tập trung vào việc điều khiển kết nối của người dùng.

Như đã nói ở trên, tấn công này chỉ nhắm vào các điện thoại kết nối tới máy chủ Exchange được bảo vệ bởi một chứng chỉ SSL tự ký. Hannay nói rằng hầu hết các tổ chức có số lượng nhân viên ít hơn 50 người thường sử dụng một chứng chỉ tự ký như vậy thay vì bỏ tiền được cấp một chứng chỉ được ký bởi một CA có uy tín.
Google và Apple vẫn chưa có phản hồi nào qua e-mail cho vấn đề này. Một đại diện của Microsoft nói rằng các thành viên trong nhóm Exchange của công ty đang xem xét bản báo cáo này của Hannay.

manthang – HVA News
(Theo Arstechnica.com)

Tham khảo:
http://arstechnica.com/security/2012/07/spoofing-microsoft-exchange-server-how-to/

traunui wrote:

Đúng như bác Quanta nói, trước em có test cái sms này trên Zabbix + Gnokii bị nhận sms hoài. Khi 1 service die, nó sms liên tục.

Còn việc build server để làm việc này em thấy lựa chọn Ubuntu là hợp lý

Mình cũng đã thử qua Ubuntu Server nhưng rồi lại quay lại CentOS bản minimal.

traunui wrote:

Đúng như bác Quanta nói, trước em có test cái sms này trên Zabbix + Gnokii bị nhận sms hoài. Khi 1 service die, nó sms liên tục.

Còn việc build server để làm việc này em thấy lựa chọn Ubuntu là hợp lý

Ngoài việc chọn những state nào thực sự cần kíp mới notify qua SMS thì có thể chỉnh lại số lần thử check, khoảng thời gian giữa 2 lần check, sau bao lâu mới re-send notifications để hạn chế việc bị nhận SMS liên tục.

quanta wrote:

Nếu dùng `check_tcp` sao không check luôn từ Nagios server, cần gì phải check trên Oracle server rồi lại gọi qua NRPE:
Code:
define service{
use generic-service
host_name oracle-db
service_description Oracle Listener Port
check_command check_tcp!1521
}
manthang wrote:

-- Sử dụng plugin check_oracle có sẵn trong Nagios để kiểm tra thông qua một thao tác đăng nhập từ xa thực sự vào database. Cách này không những xác định được port đang mở hay không mà có cho biết một thực thể (instance) của Orace đang chạy và có thể đăng nhập vào.

Yêu cầu ở đây là máy Nagios cần được cài chương trình Oracle client hoặc tối thiểu là bộ thư viện Oracle instantclient và câu lệnh sqlplus. Ngoài ra, cũng cần tạo thêm trong Oracle một tài khoản dành riêng với các quyền bị giới hạn chặt chẽ chỉ đủ để kiểm tra đăng nhập vào database.

Không cần. Bạn có thể viết một plugin gọi sqlplus để check trên chính Oracle server rồi truyền kết quả qua NRPE cho Nagios.

Em sẽ coi lại và tuỳ chỉnh 2 chỗ này, cảm ơn anh quanta đã góp ý.