Messages posted by: manthang

lỗ hổng này đã được nhóm PHP khắc phục.
người dùng cần nâng cấp lên các phiên bản mới nhất là PHP 5.4.3 và PHP 5.3.13

Chi tiết xem tại: http://www.php.net/archive/2012.php#id2012-05-08-1

Các nhà nghiên cứu vừa phát hành hai mã khai thác mới cực kỳ nguy hiểm, nhắm vào các lỗ hổng thiết kế của PLC (programmable logic controller – bộ điều khiển logic lập trình được), một thành phần máy tính thường được sử dụng để điều khiển các hạ tầng quan trọng của nền công nghiệp như các nhà máy tinh chế hóa dầu.

Các mã khai thác này sẽ cho phép kẻ xấu xâm nhập vào hệ thống theo hình thức tương tự như cách mà sâu Stuxnet đã tấn công vào các máy ly tâm hạt nhân ở Iran - một cuộc tấn công từng gây xôn xao trong cộng đồng bảo mật thế giới bởi sự tinh vi của nó và khả năng sử dụng mã độc được ký số.

Cụ thể, các mã khai thác này sẽ tấn công vào bộ điều khiển logic lập trình được Modicon Quantum được chế tạo bởi hãng Schneider-Electric, là một thành phần chính được dùng để điều khiển các chức năng trong các hạ tầng công nghiệp quan trọng trên khắp thế giới, bao gồm các cơ sở chế tạo, nhà máy nước và xử lý chất thải, nhà máy tinh chế dầu và khí ga, các đường ống dẫn dầu, nhà máy sản xuất hóa học. Thiết bị PLC của Schneider là một hệ thống mắc tiền có chi phí gần 10 nghìn đô la Mỹ.

Một trong hai mã khai thác cho phép kẻ tấn công đơn giản là gửi một lệnh “stop” tới PLC (làm ngưng trệ hoạt động của các hạ tầng công nghiệp). Mã khai thác còn lại có nhiệm vụ thay thế thành phần ladder logic [1] trong Modicon Quantum PLC để kẻ tấn công có thể nắm quyền điều khiển PLC.

Module đầu tiên sẽ tải về ladder logic hiện tại trên PLC để kẻ tấn công có thể hiểu được PLC đang làm gì. Sau đó nó tải lên PLC một ladder logic khác được tự động ghi đè lên ladder logic ban đầu trên PLC. Trong trường hợp này, các nhà nghiên cứu sẽ thực hiện ghi đè bằng một ladder logic “trắng” với mục đích chứng minh rằng kẻ tấn công có thể dễ dàng thay thế ladder logic ban đầu bằng các câu lệnh nguy hại mà không thực sự làm hỏng thiết bị PLC.

Các mã khai thác lợi dụng sơ hở là Modicon Quantum PLC không yêu cầu một máy tính có xác thực quyền truy cập khi muốn liên lạc và gửi câu lệnh tới PLC – nói cách khác, PLC tin tưởng bất kỳ máy tính nào có thể giao tiếp với nó. Và như vậy, kẻ xấu với quyền truy cập vào mạng có thể gửi tới PLC các câu lệnh nguy hại để chiếm quyền kiểm soát thiết bị hoặc đơn giản là gửi đi một câu lệnh “stop” để tạm dừng hệ thống đang hoạt động.

Mã tấn công được tạo bởi Reid Wightman, một nhà nghiên cứu bảo mật cho các hệ thống điều khiển công nghiệp (ICS) cùng với Digital Bond, một công ty tư vấn bảo mật máy tính có chuyên môn trong lĩnh vực này. Digital Bond nói rằng họ phát hành các mã khai thác để chứng minh cho các đơn vị sở hữu và vận hành các hạ tầng quan trọng kể trên thấy rằng “họ cần thiết phải đảm bảo an toàn cho các PLC từ các nhà cung cấp và phát triển một kế hoạch ngắn hạn để nâng cấp hoặc thay thế các PLC của họ”.

Các mã khai thác này cũng đã được đưa vào làm module trong Metasploit, một công cụ kiểm thử xâm nhập của công ty Rapid 7 được dùng rộng rãi bởi các chuyên gia bảo mật nhằm kiểm tra nhanh chóng và dễ dàng các lỗ hổng an ninh có thể có trong hệ thống mạng của họ.

Như đã nói, các mã khai thác được thiết kế để chứng minh “sự dễ dàng bị tổn hại và tác động to lớn” của các lỗ hổng trong PLC và làm cho các đơn vị sở hữu và vận hành các hạ tầng quan trọng “thấy và hiểu được sự mỏng manh và mất an toàn của các thiết bị như PLC”, Dale Peterson, CEO của Digital Bond nói.

Nhưng mặt khác, Metasploit cũng được dùng bởi những kẻ xấu để dò tìm và lấy được quyền truy cập vào các hệ thống tồn tại lỗ hổng. Peterson bảo vệ cho việc công ty của ông đã phát hành các mã khai thác là để gây sức ép lên các công ty như Schneider cần sửa chữa các lỗ hổng trong thiết kế mà họ đã biết đến từ lâu nhưng lại bỏ bê việc khắc phục.

Peterson và các nhà nghiên cứu bảo mật khác đã từng cảnh báo trong suốt nhiều năm rằng các hệ thống điều khiển công nghiệp ẩn chứa các vấn đề gây mất an toàn và có khả năng bị tổn thương. Nhưng chỉ đến khi sâu Stuxnet tấn công vào các nhà máy hạt nhân của Iran vào năm 2010 thì các hệ thống điều khiển công nghiệp mới nhận được sự chú ý rộng rãi hơn. Tuy nhiên, các nhà sản xuất PLC đã thực hiện vài bước để đảm bảo an toàn cho hệ thống của họ.

“Sự kiện Stuxnet xảy ra sau hơn 500 ngày nhưng Siemens S7 vẫn chưa được sửa lỗi, và Schneider cùng nhiều nhà cung cấp ICS khác cũng đã phớt lờ vấn đề này”, Peterson nói.

Cũng giống với trường hợp của hãng Schneider, Stuxnet (là sâu đã tấn công một mẫu PLC của hãng Siemens để ngầm phá hoại các máy ly tâm được dùng trong các chương trình làm giàu uranium của Iran) đã khai thác điểm yếu trong Siemens PLC là thiết bị này không yêu cầu bất kỳ sự xác thực nào cho việc tải lên ladder logic. Điều này làm cho kẻ tấn công dễ dàng chèn thêm các mã độc vào hệ thống.

Peterson đã khởi chạy một dự án nghiên cứu vào năm ngoái có tên Project Basecamp, để khám phá các lỗ hổng an ninh trong các PLC của nhiều nhà sản xuất.

Ở Nhật Bản, nhóm nghiên cứu đã công bố một vài lỗ hổng được tìm thấy trong hệ thống Modicon Quantum, bao gồm thiếu bước xác thực và sự hiện diện của khoảng 12 tài khoản (có tác dụng làm “backdoor”) đã được tạo sẵn (hard coded) và chúng đều có quyền đọc, ghi. Hệ thống cũng có một mật khẩu quản trị máy chủ web được lưu dưới dạng không mã hóa và có thể tải về thông qua một FTP backdoor.

Tại thời điểm mà họ thông báo vấn đề này vào tháng 1, nhóm cũng đã phát hành các module khai thác các lỗ hổng trong một số sản phẩm khác.

(Theo Wired)

Tham khảo:
http://www.wired.com/threatlevel/2012/04/exploit-for-quantum-plc/?utm_source=Contextly&utm_medium=RelatedLinks&utm_campaign=Previous

Chú giải:
[1] Ladder logic: có thể tạm hiểu là phần software giống như trong máy tính điện toán vậy

Apple vừa mới phát hành iOS 5.1.1 vào ngày 7/5/2012. Đây là bản nâng cấp mới nhất cho hệ điều hành chạy trên các thiết bị iPhone, iPad và iPod Touch nhằm khắc phục các lỗ hổng bảo mật nghiêm trọng và sửa lỗi, cải tiến một số chức năng.

Có tất cả 3 lỗ hổng đã được vá, một lỗi ảnh hưởng tới trình duyệt Safari, hai lỗi còn lại ảnh hưởng tới Webkit engine.

Lỗ hổng trong Safari là vấn đề giả mạo địa chỉ trang web (URL Spoofing) được các website độc hại dùng để chuyển người dùng tới một website giả mạo trong khi hiển thị một tên miền khác với tên miền của website thật tại thanh địa chỉ của Safari.

Một lỗ hổng của WebKit liên quan tới tấn công XSS (cross-site scripting) mà cho phép kẻ xấu chèn script vào các trang web được hiển thị trong trình duyệt. Và lỗi còn lại có thể được khai thác để làm treo các ứng dụng và thực thi mã độc nhằm chiếm quyền kiểm soát thiết bị iOS.

Các thiết bị bị ảnh hưởng là iPhone 3GS, iPhone 4 và 4S, iPod Touch thế hệ thứ 3 hoặc cao hơn, iPad và iPad 2.
Bản nâng cấp 5.1.1 này cũng khắc phục các vấn đề như nâng cao độ tin cậy khi sử dụng tùy chọn HDR cho các tấm hình được chụp từ Lock Screen, chuyển qua lại giữa mạng 2G và 3G tốt hơn trên The new iPad, sửa lỗi cho Airplay và cảnh báo “Unable to purchase” từ iTunes sau khi đã đặt mua thành công.

Người dùng cần cập nhật ngay khi có thể cho thiết bị iOS của mình. Phiên bản 5.1.1 có trên iTunes cho các máy iPhone và iPad chưa được nâng cấp lên iOS 5. Các thiết bị iOS 5.x có thể nâng cấp bằng cách truy cập vào Settings --> General --> Software Update, dung lượng khoảng 50MB.

Mặt khác, thành viên cốt cán của nhóm Dev-team chuyên jailbreak các thiết bị sử dụng iOS đã có xác nhận trên cập nhật Twitter của anh ta về việc jailbreak tethered vẫn có hiệu lực trên iOS 5.1.1.

(Theo Forbes, H-Online)

Tham khảo:
http://www.h-online.com/security/news/item/iOS-5-1-1-closes-iPhone-holes-1569932.html
http://www.forbes.com/sites/adriankingsleyhughes/2012/05/08/ios-5-1-1-update-includes-important-security-fixes/

phuongnvt wrote:

toend2008 wrote:

Mình đang cần xem các port trên SWITCH đang được kết nối với các pc tương ứng với địa chỉ IP là nhiêu, có lệnh nào để xem được yêu cầu trên không các bạn. Mình cám ơn!
P/S: con SWITCH này mình toàn quyền config.

Switch có thể management được ko?
@manthang: hình như bác vừa mới thăng chức hả ?

Nếu switch "không management" được chắc phải dùng phần mềm cài trên máy tính (vd, SolarWinds) thôi.

@phuongnvt: tớ làm phóng viên cho mục Tin tức của HVA. Hiện chuyên mục mới được khởi động, chắc BQT sẽ sớm có thông báo chính thức về chuyện này smilie

.

tarzanvip wrote:

huynhdanglong wrote:

Em đang làm freeradius, em start dịch vụ bằng lệnh radiusd-X sau đó chương trình radius chạy dòng lệnh

ready to process request.

em muốn gõ lệnh để test dịch vụ này nhưng không biết gõ ở đâu, nếu nhấn Ctrl C thì dịch vụ sẽ stop

vậy em phải làm sao để trở về dòng lệnh để test dịch vụ này mà không nhấn Ctrl C ? xin mọi người giúp dùm ? cám ơn !

- Cách 1: Mở một terminal khác và test trên đó.
- Cách 2: Chạy lệnh đó ở chế độ nền (background) bằng cách dùng dấu & ở cuối lệnh.
Ví dụ:
Code:
command1 &
Góp ý: Bạn nên tìm hiểu kiến thức căn bản về Linux. Những cái ở trên có liên quan đến khái niệm "background process" và "foreground process"

bổ sung cho đoạn màu vàng ở trên là:

-- nếu không dùng GUI thì có thể chuyển qua lại giữa các tty bằng cách nhấn tổ hợp phím Alt + [F1 -> F6]
(từ tty1 --> tty6)
-- nếu dùng GUI thì tìm mục New tab.

toend2008 wrote:

Mình đang cần xem các port trên SWITCH đang được kết nối với các pc tương ứng với địa chỉ IP là nhiêu, có lệnh nào để xem được yêu cầu trên không các bạn. Mình cám ơn!
P/S: con SWITCH này mình toàn quyền config.

nếu là switch của Cisco thì bạn tham khảo hướng giải quyết tại đây:
https://supportforums.cisco.com/thread/2100703

trích:

You can get to know the IP address of the host connected to any switch port by using the ARP table feature.
Please follow like below to know the end system ip address whcih is connected to the switch port.

#sh mac-address-table interface GigabitEthernet1/0/3
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
594 0001.6c58.486e DYNAMIC Gi1/0/3
594 0001.6c58.596e DYNAMIC Gi1/0/3

#sh mac-address-table address 0001.6c58.486e
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
594 0001.6c58.486e DYNAMIC Gi1/0/3
Total Mac Addresses for this criterion: 1

#sh ip arp 0001.6c58.486e
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.13.xx.xxx 5 0001.6c58.486e ARPA Vlan594

hero111135 wrote:

thanks nhìu nha. Nhưng cho em hỏi nếu xài angry birds bản hack cho symbian thi có bị ko ạ.

Vì được thiết kế để khai thác lỗ hổng GingerBreak có trong Android nên Symbian thì không bị ảnh hưởng bởi LeNa, nhưng bạn vẫn nên dè chừng vì còn nhiều loại mã độc khác có thể hoạt động trên Symbian.

Chú ý thêm tới các hành vi bất thường như tài khoản bị trừ tiền, lưu lượng mạng, SMS tăng lên vì đó có thể là dấu hiệu cho biết thiết bị đã bị nhiễm mã độc.

LeNa - loại mã độc “bình cũ rượu mới” đang đe dọa các điện thoại và máy tính bảng chạy hệ điều hành của Google bằng cách ẩn mình bên trong một trò chơi nổi tiếng.

Các nhà nghiên cứu tại hãng bảo mật di động Lookout đã phát hiện một biến thể mới của mã độc Legacy Native (LeNa) giả dạng làm một ứng dụng thông thường để cố gắng tăng đặc quyền trái phép trên các thiết bị Android.

Với giao diện của một ứng dụng chính đáng, LeNa đánh lừa người dùng để cấp phép cho nó truy cập tới các thông tin trên thiết bị. “Gần đây chúng tôi đã nhận dạng được một biến thể mới của LeNa, nó sử dụng mã khai thác lỗ hổng trong GingerBreak để đoạt quyền hạn của tài khoản root trên thiết bị mà không phụ thuộc vào sự tác động từ người dùng. Nguy cơ ảnh hưởng lan rộng đối với các thiết bị chưa được cập nhật bản vá cho lỗ hổng này (các phiên bản trước 2.3.4 của Android không có một bản vá back-ported).”, trích từ một bài viết trên blog của Lookout [1].

Trong tháng 3/2012, một trojan khác đã xuất hiện dưới dạng một trò chơi của Trung Quốc có tên The Roar of the Pharaoh, ứng dụng độc hại này đã có mặt trên Google Play nhằm mục đích đánh cắp dữ liệu và tiền của người dùng bằng cách gửi đi các tin nhắn SMS tới các đầu số dịch vụ có tính phí (premium-rate numbers) mà người dùng không hề hay biết.

Biến thể mới này của LeNa ẩn dấu payload của nó tại phần cuối của một tập tin JPEG, payload này gồm một tập tin nhị phân có tác dụng khai thác lỗ hổng GingerBreak để thực thi tập tin nhị phân còn lại (là một bản cập nhật của LeNa). Payload này sẽ âm thầm kết nối với một máy chủ C&C (Command & Control) và nhận các chỉ lệnh từ đó để cài đặt các gói bổ sung và đẩy các URL cần được hiển thị trong trình duyệt web, nó cũng âm thầm gửi đi các thông tin riêng tư và cài đặt các phần mềm độc hại khác trên thiết bị. Biến thể mới này của LeNa thường được giấu trong một bản sao đầy đủ chức năng của các ứng dụng phổ biến như Angy Birds Space.

Để phòng tránh nguy cơ này thì trước khi tải về bất kỳ ứng dụng nào, người dùng cần kiểm tra kỹ các quyền hạn, tên nhà phân phối ứng dụng, những đánh giá phản hồi, nếu cảm thấy không minh bạch thì đừng tải nó về. Hiện tại, người dùng Android chỉ nên tải về các ứng dụng từ Google Play để an toàn hơn so với các nguồn khác.

(Theo TheHackerNews)[2]

Tham khảo:

[1] http://blog.mylookout.com/blog/2012/04/03/security-alert-new-variants-of-legacy-native-lena-identified/
[2] http://thehackernews.com/2012/04/legacy-native-malware-in-angry-birds.html

Xem lại:

Giới thiệu về hạ tầng khóa công khai – PKI (1)
/hvaonline/posts/list/41925.html

Các mô hình hạ tầng khóa công khai – PKI (2)
/hvaonline/posts/list/41926.html

——————————-

Certificate Validation với CRL và OCSP – PKI (3)

Certificate Revocation

Mỗi một certificate được tạo ra đều có một khoảng thời gian hiệu lực (validity period) nhất định và thường từ 1 hoặc 2 năm. Khi vượt ra khỏi khoảng thời gian này thì nó bị hết hạn và không còn giá trị nữa. Thông tin này được chứa trong bản thân certificate (giá trị valid from và valid to) và cần được kiểm tra trước khi quyết định có nên tin dùng nó hay không.

Tuy nhiên, có những trường hợp mà một certificate cũng cần bị thu hồi (revoke) dù rằng thời gian hiệu lực vẫn còn như:

-- Người sở hữu certificate không còn làm trong tổ chức nữa.
-- CA phát hiện ra là đã cấp phát sai certificate. Sự cố liên quan tới các CA Comodo, DigiNotar xảy ra gần đây là một ví dụ.
-- Private key bị lộ hoặc thiết bị chứa private key bị mất hoặc bị đánh cắp.

Công việc thu hồi certificate này được gọi là certificate revocation và do CA thực hiện.

Có 2 trạng thái revocation được quy định trong RFC 3280 là:

Revoked: một khi certificate đã bị thu hồi thì không thể khôi phục lại và sử dụng tiếp được nữa.

Hold: certificate chỉ tạm thời bị mất hiệu lực. Ví dụ, nếu người dùng không chắc là private key đã bị mất hay chưa thì CA có thể đưa certificate vào trạng thái hold. Nếu sau đó tìm thấy private key và chắc rằng không ai đã đọc được nó thì trạng thái hold được gỡ bỏ và certificate có hiệu lực trở lại.

Theo RFC 5280 thì khi thu hồi một certificate phải chỉ định một trong 11 lý do sau:

unspecified (0)
keyCompromise (1)
cACompromise (2)
affiliationChanged (3)
superseded (4)
cessationOfOperation (5)
certificateHold (6)
(value 7 is not used)
removeFromCRL (8)
privilegeWithdrawn (9)
aACompromise (10)

Certificate Revocation List (CRL)

Là danh sách các certificate bị thu hồi và không còn được tin dùng nữa. Mỗi một mục (entry) trong CRL tương ứng với một certificate và thường gồm 3 thông tin sau:

-- Serial number của certificate
-- Thời điểm bị thu hồi
-- Lý do thu hồi (là 1 trong 11 lý do kể trên)

Một CRL được tạo và phát hành (publish) định kỳ sau 1 khoảng thời gian nào đó do người quản trị CA chỉ định, ví dụ: 1 giờ, 1 ngày, 1 tuần, v.v. Một CRL cũng có thể được cập nhật và phát hành ngay sau khi một certificate nào đó bị thu hồi. Các CA sẽ đẩy CRL chứa các certificate do nó cấp phát và quản lý tới kho chứa là LDAP server hoặc Web server.

Để ngăn chặn nguy cơ CRL có thể bị làm giả dẫn đến certificate nào đó bị cố ý đưa vào hoặc bị loại bỏ khỏi CRL, các CRL đều có một chữ ký số được ký bởi CA đã phát hành nó. Và để xác thực chữ ký này trước khi có thể tin dùng CRL thì cần đến certificate của CA đã thực hiện việc ký trên. Thông thường certificate của các CA phổ biến đều được nạp sẵn bên trong các ứng dụng có hỗ trợ PKI như các trình duyệt web, đọc email hay hệ điều hành.

Khi ứng dụng PKI nhận được một certificate, thì bản thân certificate không chứa nội dung của CRL mà nó có một extension là CRL Distribution Points (CDP), cho biết địa chỉ URL của CRL (là file có đuôi .crl) mà nó cần tải về. Sau đó ứng dụng PKI phải phân tích (parse) file .crl này để xác định xem certificate đã bị thu hồi hay chưa, nói cách khác nếu serial number không có trong CRL thì certificate đó có thể được tin dùng.

Có thể thấy, CRL mắc phải một số hạn chế sau:

-- Nếu nhiều client cùng để tải về CRL từ kho chứa thì có nguy cơ làm tắc nghẽn, giảm hiệu suất mạng. Và nếu không thể kết nối tới kho chứa CRL do thì client không thể kiểm tra tính hiệu lực của certificate, dẫn đến certificate không được tin dùng.

-- Qua thời gian, khi số lượng các certificate được cấp phát cũng như thu hồi ngày một tăng dần, thì kích thước của file .crl cũng tăng theo (thường từ 200KB đến 20MB). Ứng dụng PKI phải tốn thời gian tải về và phân tích file .crl thường chứa một lượng rất lớn các certificate bị thu hồi, trong khi nó chỉ cần xác định trạng thái revocation của một (vài) certificate mà thôi.

-- Nếu certificate mà client cần kiểm tra đã bị thu hồi nhưng chưa được cập nhật vào CRL thì khi phân tích file .crl xong client vẫn chấp nhận certificate không còn hiệu lực đó!

-- Mặc định, các máy Windows có timeout là 15 giây khi cố gắng tải về CRL.

Ngoài ra, còn có các delta CRL chứa thông tin revocation cho các certificate bị thu hồi kể từ khi base CRL mới nhất được phát hành. Nhưng để kiểm tra trạng thái revocation, ứng dụng PKI vẫn cần phải có đủ cả base CRL và các delta CRL gần đây nhất. Dẫu vậy, cách này cũng sẽ giúp tiết kiệm thời gian và băng thông mạng vì nếu client đã có sẵn base CRL rồi thì nó chỉ cần tải thêm các delta CRL thôi.

Vậy có phương thức nào hiệu quả hơn CRL trong việc kiểm tra xem certificate có bị thu hồi chưa không? Câu trả lời đến từ OCSP.

Online Certificate Status Protocol (OCSP)

Như được mô tả trong RFC 2560, OCSP là một giao thức được sử dụng để nhận về trạng thái revocation của một certificate có chuẩn định dạng là X.509. Hoạt động theo mô hình client/server, các thông điệp OCSP (request, response) được mã hóa theo chuẩn ANS.1 và được truyền qua giao thức HTTP. Server cũng thường được gọi là OCSP responder. Cơ bản nó làm việc như sau:

1. Client gửi một request chứa serial number của certificate mà nó cần kiểm tra tới server.

2. Nếu có sẵn một response được cache cho request trên thì server sẽ gửi ngay cho client. Còn không thì server sẽ kiểm tra xem có sẵn một CRL được cache chưa, nếu có thì nó sẽ dò tìm trong CRL cho serial number của certifcate rồi trả về kết quả cho client. Nếu chưa có file CRL, server sẽ tải về từ các vị trí CDP đã được cấu hình trước.

3. Response trả về cho client cho biết 1 trong 3 trạng thái có thể của certificate là:

-- “good”: không có trong CRL
-- “revoked”: bị thu hồi vĩnh viễn hoặc tạm thời (hold)
-- “unknown”: server không biết tới serial number có trong request

Response cũng được ký số bởi server sử dụng private key của một trong các thành phần:

-- CA đã cấp phát certificate có trong request.
-- Trusted Responder mà public key của nó đã được client tin tưởng
-- CA Designated Responder (Authorized Responder) có certificate được cấp bởi CA mà OCSP server đang phục vụ cho nó.

4. Client nhận được kết quả và cache lại để lần sau không cần gửi request lên server để kiểm tra certificate đó nữa.

5. Nếu server không thể xử lý request, client sẽ nhận được response không được ký, chứa thông báo lỗi.

Rõ ràng, OCSP đã giải quyết được các vấn đề gặp phải với CRL là:

-- Tiết kiệm băng thông do các request và response có kích thước nhỏ hơn nhiều (thường chỉ 4KB) so với file .crl.

-- Tiết kiệm thời gian vì chỉ phải kiểm tra trạng thái của 1 certificate thay vì phải phân tích file .crl.
Nếu thông tin revocation có sẵn trong cache tại client và server thì tiết kiệm được được cả thời gian lẫn băng thông.

-- Hệ thống certificate validation với OCSP có thể dễ dàng được mở rộng, độ sẵn sàng cao khi cần xử lý một lượng lớn các request.

-- OCSP responder đảm bảo luôn sử dụng các phiên bản CRL mới nhất làm cơ sở cho việc kiểm tra tính hiệu lực của certificate cũng như là khả năng phản hồi gần như lập tức (real-time) khi nó nhận được yêu cầu từ client.
Một OCSP server có thể phục vụ công tác certificate validation cho nhiều CA. Điều này giúp client tránh phải lưu nhiều CRL.

Tuy nhiên, trong an toàn thông tin thì không có một giải pháp nào giải quyết được mọi khía cạnh rủi ro cả. OCSP không nằm ngoài quy luật đó, nó không phải là “viên đạn bạc” cho vấn đề certificate validation, bản thân nó cũng phải đối mặt với các nguy cơ khác nhau như:

-- Availability: Nếu vì lý do nào đó mà client không thể liên lạc với OCSP server thì quá trình validation bị đổ vỡ, khi đó client có thể được cấu hình để quay lại cơ chế CRL.

-- Replay attack: kẻ tấn công chụp lại các good response, chờ đến khi certificate bị thu hồi nhưng validity period vẫn còn hiệu lực thì hắn gửi lại response đó cho client.

-- DoS/DDoS attack: kẻ tấn công cố gắng làm đầy khả năng xử lý của OCSP server tần suất các request rất lớn và liên tục. Việc server phải mất thời gian và năng lực để ký số cho mỗi response cũng khiến tình huống này thêm trầm trọng. Ngoài ra, việc các thông báo lỗi không được ký số cũng bị lợi dụng, kẻ tấn công sẽ gửi các thông báo lỗi giả này cho client và ngăn chặn các good response đến từ server khiến cho client không thể dùng được certificate này.

-- Privacy: các thông điệp OCSP đều không được mã hóa nên việc phải gửi request tới OCSP server để kiểm tra certificate cho một domain nào đó khiến bộc lộ địa chỉ IP của client cũng như website mà client muốn ghé thăm.

-- Compatibility: Một số ứng dụng và hệ điều hành cũ như Windows XP không hỗ trợ giao thức OCSP.

Kết luận

Việc cần sử dụng các certificate còn hiệu lực để đảm bảo an toàn, tin cậy cho truyền thông luôn là yêu cầu căn bản và cần thiết. Và chìa khóa cho sự thành công của một hệ thống PKI nằm ở chỗ việc cấp phát, thu hồi, kiểm tra hiệu lực certificate phải được tiến hành một cách chính xác và nhanh chóng.

CRL có thể phục vụ cho một môi trường nhỏ dưới 1000 certificate nhưng nếu số lượng certificate bị thu hồi lên tới hàng chục ngàn thì việc triển khai OCSP với độ sẵn sàng và tin cậy cao là điều nên làm. Xem thêm các tính năng cần có cho một hệ thống OCSP ở đây:

http://www.ascertia.com/blogs/OCSP_Responder_-_the_must_have_features.aspx

CRL và OCSP đều là các phương thức kiểm tra certificate qua mạng (online certificate check), Google đang có ý định thực hiện việc này một cách offline bằng cách cho phép trình duyệt Chrome tải về và cập nhật các CRL từ các CA khác nhau mà không cần tới OCSP hay dựa vào CDP trong certificate. Xem thêm ở đây:

http://www.imperialviolet.org/2012/02/05/crlsets.html

Tham khảo

[1] http://tools.ietf.org/html/rfc5280

[2] http://tools.ietf.org/html/rfc2560

[3] http://blogs.technet.com/b/askds/archive/2009/06/24/implementing-an-ocsp-responder-part-i-introducing-ocsp.aspx

[4] http://technet.microsoft.com/en-us/library/ee619754(v=ws.10).aspx

[5] http://en.wikipedia.org/wiki/Revocation_list

[6] http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

[7] http://www.chosensecurity.com/online-certificate-status-protocol

–manthang.

Bài này được viết nhân việc đọc được entry sau Google Security blog:
http://googleonlinesecurity.blogspot.com/2011/11/protecting-data-for-long-term-with.html

Trên blog của Adam Langley, tác giả của entry trên, cũng có một bài nói về forward secrecy:
http://www.imperialviolet.org/2011/11/22/forwardsecret.html

Theo đó, từ năm 2010, Google đã mặc định áp dụng HTTPS cho các dịch vụ như Gmail, Search, Docs, Calendar nhằm bảo vệ tính riêng tư cho các thông tin quan trọng của người dùng. Vào cuối tháng 11/2011, Google trở thành một trong những “ông lớn” đầu tiên triển khai ”forward secrecy” cho các dịch vụ trên.

Một cách gọi khác là “perfect foward secrecy”:
http://en.wikipedia.org/wiki/Perfect_forward_secrecy

Và để hiểu tại sao việc sử dụng nó lại cần thiết đến như vậy, ta cần biết HTTPS làm việc ra sao, xem thêm:
http://en.wikipedia.org/wiki/HTTP_Secure

Về cơ bản, client và server sẽ dùng chung một session key để mã hóa các request và response mà chúng gửi cho nhau để những bên thứ 3 như ISP hay kẻ nghe lén nằm cùng mạng LAN với chúng không thể giải mã và đọc được các thông điệp đó. Mỗi server có một private key, và chỉ những ai nắm giữ private key này mới có thể giải mã được session key và từ đó đọc được thông điệp.

Hầu hết các website có hỗ trợ HTTPS đều hoạt động dưới hình thức non-forward secret (không áp dụng forward secrecy), điều này dẫn đến một rủi ro gọi là “retrospective decryption”. Tức là, attacker sẽ ghi nhận và lưu trữ lại các traffic (request, response) được mã hóa, sau đó tìm cách để biết được private key như tập kết các siêu máy tính để thực hiện bẻ khóa private key trong nhiều năm hay dò trong ổ cứng chứa private key bị giục đi chẳng hạn. Khi đó, các traffic cũ này hoàn toàn có thể bị giải mã.

May thay, với forward secrecy, ta có thể giải quyết mối đe dọa trên. Khi nó được áp dụng thì một vài “thông tin cần thiết” để giải mã traffic được tạo ra ngẫu nhiên, khác nhau cho mỗi session và chúng bị hủy bỏ (không được lưu trữ lại) sau khi session giữa client và server chấm dứt. Đặc biệt, “thông tin cần thiết” này không liên quan tới các key được lưu trữ dài lâu là public key và private key nên nếu private key có bị “compromise” thì attacker cũng không thể nào giải mã được các thông điệp được mã hóa mà hắn đã thu thập trước đó.

Có chăng là khi private key bị lộ, tính xác thực của các “thông tin cần thiết” đó không còn được đảm bảo và gây rủi ro cho các traffic mới được tạo ra sau đó. Lúc này, certificate mà cấp cho server phải sớm bị thu hồi (revoke). Tuy nhiên, forward secrecy vẫn thực sự làm tăng tính privacy cho dữ liệu cần được bảo mật dài lâu.

Vậy thì, “thông tin cần thiết” thực chất là gì, được tạo ra như thế nào và sử dụng ra sao? Bài viết sau phân tích forward secrecy làm việc trong SSL/TLS:
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

Theo đó thì, private key chỉ được sử dụng cho mục đích authentication và signing, còn thuật toán Diffie-Hellman sẽ được dùng để trao đổi shared secret (hay session key) qua một kênh truyền thông không an toàn như Internet. Key này sau đó được dùng để mã hóa traffic giữa client và server dùng thuật toán bất đối xứng như AES, RC4. Cipher suite được thỏa thuận ở đây có thể là DHE-RSA-AES128-SHA, ECDHE-RSA-RC4-SHA, v.v…
trong đó:

+ DHE (hay EDH) = Ephemeral Diffie-Hellman

+ ECDHE = Elliptic Curve, Ephemeral Diffie-Hellman

Nên dùng stream cipher RC4 thay cho block cipher AES_CBC để ngăn chặn tấn công BEAST:
http://vnhacker.blogspot.com/2011/09/beast.html

Ngoài SSL/TLS, kỹ thuật này hiện đã được áp dụng trong các giao thức, IPSec, SSH hay Off-the-Record Messaging.
http://www.cypherpunks.ca/otr/

Do gặp phải vấn đề là tiêu tốn CPU của server nhiều hơn HTTP và HTTPS bình thường nên các hầu như các site khác đều chưa mạnh dạn triển khai forward secrecy. Nikos Mavrogiannopoulos có làm một bài test nho nhỏ ở đây:
http://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html

Để khắc phục vấn đề hiệu suất này, Google đã thực hiện các cải tiến cho thư viện mã nguồn mở OpenSSL: http://cvs.openssl.org/fileview?f=openssl/CHANGES&v=1.1481.2.56.2.57

Forward secrecy là một bước tiến quan trọng cho vấn đề web privacy nói riêng và data security nói chung. Tài liệu sau nghiên cứu khá kỹ về nó:
http://www.cs.bu.edu/~itkis/pap/forward-secure-survey.pdf

--manthang.

Xem lại:

Giới thiệu về hạ tầng khóa công khai – PKI (1)
/hvaonline/posts/list/41925.html

—————-

Các mô hình hạ tầng khóa công khai – PKI (2)

Tùy vào các yêu cầu, quy mô và khả năng của từng tổ chức mà có thể chọn triển khai một trong 3 mô hình PKI phổ biến sau:

Hierarchical PKI

Mesh PKI

Single CA

Single CA

Đây là mô hình PKI cơ bản nhất phù hợp với các tổ chức nhỏ trong đó chỉ có một CA cung cấp dịch vụ cho toàn hệ thống và tất cả người dùng đặt sự tin cậy vào CA này. Mọi thực thể muốn tham gia vào PKI và xin cấp chứng chỉ đều phải thông qua CA duy nhất này. Mô hình này dễ thiết kế và triển khai nhưng cũng có các hạn chế riêng. Thứ nhất là ở khả năng co giãn – khi quy mô tổ chức được mở rộng, chỉ một CA thì khó mà quản lý và đáp ứng tốt các dịch vụ. Hạn chế thứ hai là CA này sẽ là điểm chịu lỗi duy nhất, nếu nó ngưng hoạt động thì dịch vụ bị ngưng trệ. Cuối cùng, nếu nó bị xâm hại thì nguy hại tới độ tin cậy của toàn bộ hệ thống và tất cả các chứng chỉ số phải được cấp lại một khi CA này được phục hồi.

Trust List

Nếu có nhiều CA đơn lẻ trong tổ chức nhưng lại không có các trust relationship giữa các CA được tạo ra thì bằng cách sử dụng trust list người dùng vẫn có thể tương tác với tất cả các CA. Lúc này các người dùng sẽ duy trì một danh sách các CA mà họ tin cậy. Các CA mới về sau có thể dễ dàng được thêm vào danh sách. Phương thức này tuy đơn giản nhưng cũng sẽ tốn thời gian để cập nhật hết các CA cho một lượng lớn người dùng, mặt khác nếu một CA nào đó bị thỏa hiệp thì không có một hệ thống cảnh báo nào báo cho những người dùng mà tin cậy CA đó biết được sự cố này.

Hierarchical PKI

Đây là mô hình PKI được áp dụng rộng rãi trong các tổ chức lớn. Có một CA nằm ở cấp trên cùng gọi là root CA, tất cả các CA còn lại là các Subordinate CA (gọi tắt là sub. CA) và hoạt động bên dưới root CA. Ngoại trừ root CA thì các CA còn lại trong đều có duy nhất một CA khác là cấp trên của nó. Hệ thống tên miền DNS trên Internet cũng có cấu trúc tương tự mô hình này.

Tất cả các thực thể (như người dùng, máy tính) trong tổ chức đều phải tin cậy cùng một root CA. Sau đó các trust relationship được thiết lập giữa các sub. CA và cấp trên của chúng thông qua việc CA cấp trên sẽ cấp các chứng chỉ cho các sub. CA ngay bên dưới nó. Lưu ý, root CA không trực tiếp cấp chứng chỉ số cho các thực thể mà chúng sẽ được cấp bởi các sub. CA. Các CA mới có thể được thêm ngay dưới root CA hoặc các sub. CA cấp thấp hơn để phù hợp với sự thay đổi trong cấu trúc của tổ chức. Sẽ có các mức độ tổn thương khác nhau nếu một CA nào đó trong mô hình này bị xâm hại.

Trường hợp một sub. CA bị thỏa hiệp thì CA cấp trên của nó sẽ thu hồi chứng chỉ đã cấp cho nó và chỉ khi sub. CA đó được khôi phục thì nó mới có thể cấp lại các chứng chỉ mới cho người dùng của nó. Cuối cùng, CA cấp trên sẽ cấp lại cho nó một chứng chỉ mới.

Nếu root CA bị xâm hại thì đó là một vấn đề hoàn toàn khác, toàn bộ hệ thống PKI sẽ chịu ảnh hưởng. Khi đó tất cả các thực thể cần được thông báo về sự cố và cho đến khi root CA được phục hồi và các chứng chỉ mới được cấp lại thì không một phiên truyền thông nào là an toàn cả. Vì thế, cũng như single CA, root CA phải được bảo vệ an toàn ở mức cao nhất để đảm bảo điều đó không xảy ra và thường root CA có thể ở trạng thái offline – bị tắt và không được kết nối vào mạng.

Mesh PKI

Nổi lên như một sự thay thế chính cho mô hình Hierarchical PKI truyền thống, thiết kế của Mesh PKI giống với kiến trúc Web-of-Trust trong đó không có một CA nào làm root CA và các CA sẽ có vai trò ngang nhau trong việc cung cấp dịch vụ. Tất cả người dùng trong mạng lưới có thể tin cậy chỉ một CA bất kỳ, không nhất thiết hai hay nhiều người dùng phải cùng tin một CA nào đó và người dùng tin cậy CA nào thì sẽ nhận chứng chỉ do CA đó cấp

Các CA trong mô hình này sau đó sẽ cấp các chứng chỉ cho nhau. Khi hai CA cấp chứng chỉ cho nhau thì một sự tin cậy hai chiều được thiết lập giữa hai CA đó. Các CA mới có thể được thêm vào bằng cách tạo các mối tin cậy hai chiều giữa chúng với các CA còn lại trong mạng lưới.

Vì không có một CA duy nhất làm cấp cao nhất nên sự tổn hại khi tấn công vào mô hình này có khác so với hai mô hình trước đó. Hệ thống PKI không thể bị đánh sập khi chỉ một CA bị thỏa hiệp. Các CA còn lại sẽ thu hồi chứng chỉ mà chúng đã cấp cho CA bị xâm hại và chỉ khi CA đó khôi phục hoạt động thì nó mới có khả năng cấp mới các chứng chỉ cho người dùng rồi thiết lập trust với các CA còn lại trong mạng lưới.

Trong phần tiếp theo sẽ tiếp tục tìm hiểu về các khái niệm, thành phần và hoạt động của PKI như: certificate formats, certification path, certificate revocation, certificate polices v.v...

–manthang.

Giới thiệu về hạ tầng khóa công khai – PKI (1)

0. Dẫn nhập

Mật mã

Đây là thành phần có vai trò rất quan trọng, là trái tim của bất cứ mạng tin cậy nào. Nó giúp đảm bảo bảo mật và toàn vẹn cho các thông điệp, cũng như nhận dạng và xác thực các đối tượng tham gia vào phiên truyền thông. Về cơ bản, mật mã được phân làm 2 loại chính: mã hóa đối xứng và mã hóa bất đối xứng.

Loại mã hóa đối xứng thường được gọi là mật mã khóa bí mật và cả hai bên đều sử dụng cùng một khóa để mã hóa và giải mã thông tin. Các thuật toán mã hóa đối xứng phổ biến như 3DES, AES, RC5.

Còn loại mã hóa bất đối xứng còn được gọi là mật mã khóa công khai và cần sử dụng một cặp khóa để mã hóa và giải mã. Nếu mã hóa bằng khóa thứ nhất (gọi là khóa công khai) thì chỉ có thể giải mã bằng khóa thứ hai (gọi là khóa bí mật) và ngược lại. DSA, RSA, Diffie-Hellman là ví dụ về các thuật toán mã hóa bất đối xứng nổi tiếng.

Ngoài ra trong mật mã còn có kỹ thuật băm một chiều (one-way hash) là một hàm nhận vào một thông điệp có chiều dài bất kỳ và tạo ra một chuỗi có chiều dài cố định được gọi là giá trị băm. Ví dụ, giá trị mà giải thuật băm MD5 tạo ra luôn là 128-bit, với SHA-1 là 160-bit. Hàm băm một chiều làm việc mà không cần sử dụng bất kỳ khóa nào và đặc biệt, từ kết quả băm cuối cùng thì rất khó (thường không thể) lần ngược lại thông điệp gốc ban đầu. Nó thường được dùng để kiểm tra tính toàn vẹn của thông điệp, tập tin.

Chữ ký số

Được tạo ra sử dụng kết hợp giữa hàm băm và mật mã khóa công khai để đảm bảo tính toàn vẹn, giúp xác thực nguồn gốc của thông điệp và đồng thời bên gửi không thể chối từ việc đã tạo ra thông điệp đó. Nó là một giá trị băm của thông điệp được mã hóa bằng khóa bí mật của bên gửi rồi được đính kèm với thông điệp gốc. Bên nhận sẽ dùng khóa công khai của bên gửi để giải mã phần chữ ký ra được giá trị băm của thông điệp rồi đối chiếu với giá trị mà nó thu được từ việc thực hiện lại hàm băm trên thông điệp gốc. Nếu hai giá trị đó giống nhau thì bên nhận có thể tin cậy được rằng thông điệp không bị thay đổi và nó chỉ được gửi từ bên sở hữu khóa công khai ở trên.

Chứng chỉ số

Là một tập tin giúp chắc chắn rằng khóa công khai thuộc về một thực thể nào đó như người dùng, tổ chức, máy tính và điều này được xác minh bởi một bên thứ ba đáng tin cậy thường gọi là CA (Certificate Authorities). Chứng chỉ số chứa các thông tin nhận dạng về thực thể như tên, địa chỉ, khóa công khai (cùng nhiều thông tin khác) và được ký số bởi khóa bí mật của CA.

1. Giới thiệu về PKI

Dựa trên nền tảng của mật mã khóa công khai, PKI là một hệ thống bao gồm phần mềm, dịch vụ, chuẩn định dạng, giao thức, quy trình, chính sách để giúp đảm bảo an toàn, tin cậy cho các phiên truyền thông.

PKI đáp ứng các yêu cầu về xác thực, bảo mật, toàn vẹn, chống chối từ cho các thông điệp được trao đổi.

Các thành phần của PKI

Ngoài các thành phần cơ bản chứng chỉ số, chữ ký số và mật mã. PKI còn được tạo nên bởi các thành phần chức năng chuyên biệt sau:

Certificate Authority

Registration Authority

Certificate Repository và Archive

Security Server

PKI-enabled applications và PKI users

Certificate Authority (CA): là một bên thứ được tin cậy có trách nhiệm tạo, quản lý, phân phối, lưu trữ và thu hồi các chứng chỉ số. CA sẽ nhận các yêu cầu cấp chứng chỉ số và chỉ cấp cho những ai đã xác minh được nhận dạng của họ.

Registration Authority (RA): đóng vai trò trung gian giữa CA và người dùng. Khi người dùng cần chứng chỉ số mới, họ gửi yêu cầu tới RA và RA sẽ xác nhận tất cả các thông tin nhận dạng cần thiết trước khi chuyển tiếp yêu cầu đó tới CA để CA thực hiện tạo và ký số lên chứng chỉ rồi gửi về cho RA hoặc gửi trực tiếp cho người dùng.

Certificate Repository và Archive: có 2 kho chứa quan trọng trong kiến trúc của PKI. Đầu tiên là kho công khai lưu trữ và phân phối các chứng chỉ và CRL (chứa danh sách các chứng chỉ không còn hiệu lực). Cái thứ 2 là một cơ sở dữ liệu được CA dùng để sao lưu các khóa hiện đang sử dụng và lưu trữ các khóa hết hạn, kho này cần được bảo vệ an toàn như chính CA.

Security Server: là một máy chủ cung cấp các dịch vụ quản lý tập trung tất cả các tài khoản người dùng, các chính sách bảo mật chứng chỉ số, các mối quan hệ tin cậy (trusted relationship) giữa các CA trong PKI, lập báo cáo và nhiều dịch vụ khác.

PKI-enabled applications và PKI users: bao gồm các người dùng sử dụng các dịch vụ của PKI và các phần mềm có hỗ trợ cài đặt và sử dụng các chứng chỉ số như các trình duyệt web, các ứng dụng email chạy phía máy khách.

Phần 2 sẽ giới thiệu 3 kiến trúc PKI phổ biến được áp dụng triển khai trong thực tế.

--manthang.

mrtyonline wrote:

Ngoài các vấn đề bảo mật "bên trong" SQL server về login user, database user , cấp phát quyền cho các user, bảng ảo thì còn vấn để bảo mật gì nữa ở trong thực tế ạ?
Có thể phác thảo cho em tổng quan về bảo mật liên quan đến SQL server được không ạ?

tham khảo thêm cuốn này:
http://www.amazon.com/Securing-SQL-Server-Protecting-Attackers/dp/1597496251/ref=sr_1_1?ie=UTF8&qid=1332826912&sr=8-1

quanta wrote:

Subject wrote:

Nhờ mọi người định hướng giúp!

Trước tiên là nên học cách đặt lại tiêu đề. Box này đã là định hướng rồi, tiêu đề này không giúp người đọc hình dung thêm được gì cả.

badboy2108 wrote:

Hiện tại mình đang theo đuổi ngành CNTT , định hướng khi ra trường sẽ theo mảng Quản trị hệ thống và Bảo mật.Tuy nhiên mình còn cảm thấy chưa rõ ràng lắm về công việc đó là như thế nào.Vì vậy mong được các bậc đàn anh đi trước chỉ bảo những khúc mắc của mình như sau:
1-Theo đuổi hệ thống nào?:
Windown or Linux.Đây chính là điều mình suy nghĩ đầu tiên, ở trường mình đã được học Windown nhưng khi theo dõi các forum mình thấy Linux là 1 hệ thống tốt hơn cho các máy chủ Server

Học cả 2. Lưu ý là Windows chứ không phải Windown.

badboy2108 wrote:

2-Ngoài trang bị các kiến thức về các giao thức mạng(như TCP/IP),các ngôn ngữ ứng dụng viết script(Perl...),cũng như hiểu được sự vận hành của các OS thì mình còn nghĩ đến các Tool khác nữa.Các anh chị thường dùng tool nào vậy?(Mình có nghe nói về WireShark và đang tìm hiểu nó)

Bạn cứ "vọc" nhiều vào, dần dần nó sẽ "vỡ" ra, và đôi khi sẽ có những câu hỏi tự đến với mình:

- Làm cách nào để đồng bộ 2 webserver chạy load balancing?
- Muốn chạy load balancing thì dựng thêm một con load balancer đứng trước, nhưng nếu con load balancer này chết thì sao? (Single Point Of Failure)
- Một user vừa mới nghỉ việc, làm cách nào delete (disable) account của họ trên 10 server một cách nhanh nhất?
- Làm cách nào deploy một ứng dụng lên hàng loạt servers?
- Liệu có ai đó đang "chọc ngoáy" hệ thống của mình không?
- ...

badboy2108 wrote:

3-Những công việc thường ngày của 1 Systermadmin là gì??

Xây dựng -> Vận hành, Quản trị -> Tối ưu -> Bảo mật hệ thống.

--> Đoạn màu vàng trên của anh quanta cho thấy quy trình theo từng bước (có sự trước - sau) trong công việc của người sysadmin. Và em thấy các chi tiết trong bước Bảo mật cho hệ thống phải được vạch ra/thực hiện ngay tại giai đoạn lập kế hoạch/xây dựng hệ thống đó (còn như trong chu trình trên thì em hiểu là bước Bảo mật lại được thực hiện sau bước Tối ưu).

em có góp ý nho nhỏ vậy thôi smilie

.

Dưới đây là phần tìm hiểu của manthang về chủ đề này. Mong được mọi người bổ sung, góp ý thêm.

-----

Để nắm rõ hơn cơ chế làm việc của giao thức HTTPS được mô tả trong bài viết này, những kiến thức cơ bản sẵn có về một số khái niệm liên quan sau là cần thiết:

_ Symmetric/Asymmetric encryption, Hashing function.
_ Tác dụng của SSL Certificate cũng như là các thông tin có trong nó.
_ Vai trò của Central Authority (CA).

Các bạn có thể dễ dàng tìm kiếm thông tin về các vấn đề trên trên Internet.

1. Giới thiệu

Giao thức HTTPS sử dụng port 443, và cung cấp các dịch vụ hay đảm bảo tính chất sau của thông tin:

+ Confidentiality: sử dụng phương thức encryption để đảm bảo rằng các thông điệp được trao đổi giữa client và server không bị kẻ khác đọc được.

+ Integrity: sử dụng phương thức hashing để cả client và server đều có thể tin tưởng rằng thông điệp mà chúng nhận được có không bị mất mát hay chỉnh sửa.

+ Authenticity: sử dụng digital certificate để giúp client có thể tin tưởng rằng server/website mà họ đang truy cập thực sự là server/website mà họ mong muốn vào, chứ không phải bị giả mạo.

2. Sử dụng HTTPS như thế nào?

Trước hết, muốn áp dụng HTTPS thì trong quá trình cấu hình Webserver, bạn có thể dễ dàng tự tạo ra một SSL certificate dành riêng cho website của mình và nó được gọi là self-signed SSL certificate.

SSL certificate tự cấp này vẫn mang lại tính Confidentiality và Integrity cho quá trình truyền thông giữa server và client. Nhưng rõ ràng là không đạt được tính Authenticity bởi vì không có bên thứ 3 đáng tin cậy nào (hay CA) đứng ra kiểm chứng sự tính xác thực của certificate tự gán này. Điều này cũng giống như việc một người tự làm chứng minh nhân dân (CMND) cho mình rồi tự họ ký tên, đóng dấu luôn vậy!

Vì vậy, đối với các website quan trọng như E-Commerce, Online Payment, Web Mail,… thì họ sẽ mua một SSL certificate từ một Trusted Root CA nổi tiếng như VeriSign, Thawte, và ít tên tuổi hơn thì có GoDaddy, DynDNS… Ở đây, các CA có nhiệm vụ chính là cấp phát và quản lý SSL certificate cho server/website.

Thực chất thì SSL certificate cũng là một loại digitial certificate (một loại file trên máy tính). Vì giao thức HTTPS có dính tới giao thức SSL nên người ta mới đặt tên cho nó là SSL certificate để phân biệt với các loại digital certificate khác như Personal Certificate, Server Certificate, Software Publisher Certificate, Certificate Authority Certificate, v.v...

Dưới đây là một số thông tin quan trọng được chứa trong SSL certificate mà bất cứ client nào cũng có thể xem được bằng cách click vào biểu tượng padlock trên thanh Address của Web browser:

_ Thông tin về owner của certificate (như tên tổ chức, tên cá nhân hoặc domain name của website).

_ Tên và digital signature của CA mà cấp certificate này.

_ Khoảng thời gian mà certificate còn hiệu lực sử dụng.

_ Public key của server/website. Còn private key được lưu trữ trên chính server (không có trong certificate) và tuyệt đối không thể để lộ cho bất cứ client nào.

_ Một số thông tin phụ khác như: loại SSL certificate, các thuật toán dùng để encryption và hashing, chiều dài (tính bằng bit) của key, cơ chế trao đổi key (như RSA, DSA).

v.v…

Ngoài self-signed SSL cert thì trên thị trường hiện nay tuỳ vào CA mà có vài loại SSL certificate khác nhau như: domain validated SSL cert, fully authenticated SSL cert, wildcard SSL cert, EV SSL cert, v.v...

3. Quá trình giao tiếp giữa client và server thông qua HTTPS

1. Client gửi request cho một secure page (có URL bắt đầu với https://)

2. Server gửi lại cho client certificate của nó.

3. Client (web browser) tiến hành xác thực certificate này bằng cách kiểm tra (verify) tính hợp lệ của chữ ký số của CA được kèm theo certificate.

Giả sử certificate đã được xác thực và còn hạn sử dụng hoặc client vẫn cố tình truy cập mặc dù Web browser đã cảnh báo rằng không thể tin cậy được certificate này (do là dạng self-signed SSL certificate hoặc certificate hết hiệu lực, thông tin trong certificate không đúng…) thì mới xảy ra bước 4 sau.

4. Client tự tạo ra ngẫu nhiên một symmetric encryption key, rồi sử dụng public key (trong certificate) để mã hóa symmetric key này và gửi về cho server.

5. Server sử dụng private key (tương ứng với public key trong certificate ở trên) để giải mã ra symmetric key ở trên.

6. Sau đó, cả server và client đều sử dụng symmetric key đó để mã hóa/giải mã các thông điệp trong suốt phiên truyền thông.

Và tất nhiên, các symmetric key sẽ được tạo ra ngẫu nhiên và có thể khác nhau trong mỗi phiên làm việc với server. Ngoài encryption thì cơ chế hashing sẽ được sử dụng để đảm bảo tính Integrity cho các thông điệp được trao đổi.

4. Tạm kết

HTTPS là một giao thức phổ biến trên Internet và rất cần thiết để đảm bảo an toàn cho môi trường Web. Tuy nhiên, vẫn có vài cách thức mà hacker có thể sử dụng để qua mặt cơ chế bảo vệ của HTTPS như ssl-strip (của tác giả Moxie Marlinspike), BEAST (của 2 tác giả là anh mrro và Juliano).

Để kết thúc bài viết và cũng để các khái niệm liên quan tới HTTPS trở nên gần gũi và dễ hiểu hơn, dươi đây là tình huống thực tế minh hoạ:

CMND của người A do Công an ở địa phương B cấp. Người A này muốn thực hiện một công việc gì đó rất quan trọng với tổ chức C chẳng hạn. Và giả sử CMND của A là thứ duy nhất mà C có thể dựa vào để tin tưởng được các thông tin về A như khuôn mặt, tên, tuổi, nơi ở… Vì C thấy CMND cũng có thể bị làm giả và để chắc rằng các thông tin về A được ghi trong CMND là thực thì cách tốt nhất là C đem CMND của A đến nhờ bên B xác thực giùm.

Như vậy, có thể coi:

Bên A là website
Bên B là CA
CMND của A chính là SSL Certificate do B cấp
Bên C là Web client

--manthang.

Tiếp đoạn còn dang dở smilie

-----

4. Tấn công Man-in-the-Middle (MITM)

Nhiều người trong số chúng ta có thể đã là mục tiêu của các cuộc tấn công MITM. MITM xảy ra khi attacker bằng cách nào lừa gạt máy user thiết lập một kênh liên lạc với một máy server hoặc dịch vụ nào đó xuyên qua một “rogue entity”.

Ở đây, rogue entity chính là hệ thống do hacker điều khiển. Nó được dựng lên để chặn đứng việc liên lạc giữa user và server mà không để cho user nhận thấy được rằng tấn công đang diễn ra.

Bàn thêm

Trong tấn công kiểu MITM, hacker đảm nhận việc trung chuyển luồng thông tin giữa user và server. Và user vẫn truyền thông với server bình thường nhưng toàn bộ thông tin trao đổi qua lại đều bị máy hacker tóm được.

Để thực hiện thành công MITM thì hacker phải bằng cách nào đó đánh lừa được user chuyển hướng luồng thông tin tới rogue entity do hacker điều khiển. Ttức là thay vì gửi trực tiếp gói tin tới server thì user lại gửi tới rogue entity và sau đó rogue entity sao chép lại gói tin đó trước khi chuyển cho server.

MITM có thể đơn giản như kiểu tấn công “phishing e-mail” (sử dụng e-mail để lừa đảo) mà trong đó hacker gửi cho user một e-mail có chứa một URL dẫn tới rogue entity thay vì trang web thực sự mà user muốn tới. Rogue entity có giao diện trông giống như của trang web thực nhằm đánh lừa user cung cấp các thông tin đăng nhập (credential).

Sau đó, credential này được hacker sao chép lại trước khi chuyển cho website thực sự mà user cần liên lạc. Sau hành động đáng tiếc trên thì user vẫn kết nối thành công với website, nhưng không biết được truyền thông giữa họ và website đã bị hacker nghe trộm được và hacker có thể bóp méo nội dung của cuộc “nói chuyện” này (khiến cho user và website nhận về những thông tin sai lệch).

MITM cũng có thể được thực hiện bằng cách sử dụng các phương thức phức tạp hơn như ARP poisoning, router table poisoning, DNS query poisoning, DNS hijacking, rogue DNS server, HOSTS file alteration, local DNS cache poisoning, proxy re-routing… Và những phương thức này không hề dính dáng đến vấn đề mã hóa hoặc các thủ thuật dùng để ẩn dấu đi các đường link độc hại (URL Obfuscation).

Để tự bảo vệ bản thân trước các cuộc tấn công kiểu MITM, bạn cần tránh nhấn vào các URL lạ có trong các e-mail. Bạn cũng nên luôn xác minh các URL đó trỏ tới các trang web có domain đáng tin cậy hoặc có sử dụng SSL certificate còn hiệu lực hay không. Ngoài ra, nếu có thể bạn nên triển khai các hệ thống H-IDS/N-IDS để giám sát các lưu lượng mạng cũng như những thay đổi trên hệ thống cục bộ của bạn (như HOSTS file, ARP cache, routing table, DNS cache…).

5. Tấn công các mạng không dây

Các mạng không dây (wireless network) hấp dẫn người dùng hơn mạng có dây (wired) ở tính tiện dụng và linh hoạt của nó. Ngoài ra, triển khai các mạng không dây thì khá rẻ và cũng dễ dàng cài đặt.

Nhưng bên cạnh những lợi ích đó thì mạng không dây cũng bộc lộ những nguy cơ mà làm tiêu tốn không ít thời gian, nỗ lực và chi phí để giữ an toàn cho chúng. Jamming (gây nhiễu tín hiệu), DoS, Hijacking, MiTM, Sniffing (nghe trộm),… và nhiều kiểu tấn công khác mà hacker có thể sử dụng để quậy phá các mạng không dây.

Đó là chưa kể tới các vấn đề về tốc độ, phạm vi phủ sóng bị hạn chế của từng chuẩn mạng không dây. Tuy nhiên, ngay cả khi tổ chức của bạn không chính thức chấp thuận việc triển khai một mạng không dây thì bạn vẫn còn một số vấn đề mà bạn cần quan tâm.

Ví dụ, nhiều tổ chức đã phát hiện ra rằng các nhân viên đã bí mật tự ý thiết lập mạng không dây của riêng họ bằng cách mang vào tổ chức thiết bị WAP (wireless access point), và cắm cáp mạng mà tổ chức cấp xuống cho các phòng ban vào WAP, sau đó họ kết nối laptop/desktop của mình tới WAP bằng cáp mạng hoặc sóng radio.

Điều này bổ sung thêm tùy chọn kết nối không dây, thông qua WAP, tới mạng nội bộ của tổ chức. Như thế, mức độ rủi ro mà tổ chức có thể phải gánh chịu do bị hacker tấn công (sử dụng các kỹ thuật ở trên) sẽ càng tăng cao khi các nhân viên này triển khai WAP với chuẩn bảo mật yếu (như WEP) hoặc thậm chí không hề sử dụng cơ chế bảo mật nào cho mạng không dây.

Vì vậy, một thiết bị WAP có giá 50 USD có thể dễ dàng tạo ra các rủi ro cho một mạng có dây trị giá hàng triệu đô la được bảo vệ kỹ càng.

Để ngăn chặn với các WAP không được phê duyệt để triển khai này, cần thực hiện một cuộc khảo sát định kỳ khu vực hoạt động của tổ chức bằng cách sử dụng các các công cụ giúp phát hiện các mạng không dây như NetStumbler hoặc với một thiết bị cầm tay chuyên dụng.

6. Do thám hệ thống mục tiêu

Các hacker, đặc biệt là các external hacker (kẻ tấn công không phải là người trong nội bộ tổ chức) biết cách làm sao để vượt qua các hàng rào an ninh bằng cách tìm kiếm, thu thập các thông tin về tổ chức và hệ thống CNTT của bạn. Quá trình này được gọi là reconnaissance (do thám), hoặc footprinting. Sau cùng, hacker tập trung vào nghiên cứu tất cả thông tin hiện có về tổ chức của bạn từ các nguồn được phát tán rộng rãi (public) và các tài nguyên lưu hành nội bộ (non-public).

Nếu có tìm hiểu về binh pháp, bạn sẽ ý thức được rằng vũ khí quan trọng nhất mà bạn có chính là thông tin. Hacker biết rõ điều này và dùng nhiều thì giờ và sức lực để có được “kho vũ khí” đầy đủ nhất. Trớ trêu thay là nhiều tổ chức vẫn còn để lộ và dâng nộp “vũ khí thông tin” của mình vào “kho đạn” của hacker.

Tình trạng rò rỉ và thất thoát dữ liệu đang diễn ra ở công ty, họ thoải mái cung cấp nhiều thông tin mà có thể được sử dụng trong nhiều kiểu tấn công vào hệ thống của họ. Dưới đây là một vài ví dụ về những thông tin về tổ chức của bạn mà hacker có thể biết được:

_ Việc đăng ký tên miền yêu cầu cung cấp địa chỉ, số điện thoại, email…. của chủ sở hữu tên miền đó.

_ Thông qua DNS lookup và traceroute sẽ biết được thông tin về ISP của bạn.

_Thông tin về các nhân viên như địa chỉ, số điện thoại, lịch sử công tác,…

_Các hệ điều hành, các chương trình quan trọng, các ngôn ngữ lập trình, các thiết bị mạng, những nền tảng và dịch vụ… mà tổ chức đang sử dụng.

_Các điểm yếu, điểm mạnh, lối vào, các đường truy cập bí mật… và nhiều thông tin quan trọng khác về hệ thống của bạn.

_ Sử dụng kỹ thuật Google hacking để tìm được các tài liệu mật được lưu trữ trên máy chủ Web của tổ chức.

v.v...

Như bạn thấy, có rất nhiều thông tin mà một hacker có thể có được từ các nguồn mở, công cộng và danh sách ở trên chưa thể liệt kê hết các thông tin này. Một hacker thường bỏ ra khoảng 90% thời gian cho các hoạt động thu thập thông tin vì càng hiểu rõ về mục tiêu thì khả năng tấn công thành công càng cao.

--manthang.

chủ topic thử cài bản 64-bit của các distro khác như RHEL, Debian xem còn bị tình trạng không nhận đủ dung lượng RAM như với CentOS không?

tanviet12 wrote:

Em nghĩ tuỳ theo đặt điểm của từng website.
Nếu website cần bảo mật thông tin của người dùng (như thông tin đăng nhập, thông tin giao dịch...) thì dùng HTTPS, còn chỉ đăng tin tức bình thường thì dùng HTTP để có được những ưu điểm như anh đã nêu (tốc độ, chi phí...)

Giả dụ không có các thông tin về credential, về transaction nhưng nếu có các thông báo quan trọng cần được đăng lên, chẳng hạn, như các chương trình khuyến mãi thì cũng cần có cách nào đó để user có thể tin cậy được rằng họ đang vào đúng website mong muốn (chứ không phải 1 trang giả mạo nào đó đăng lên một thông báo tào lao), lúc này HTTPS có thể giúp đảm bảo tính authenticity đó.

maithangbs wrote:

bolzano_1989 wrote:

Đã được nửa năm rồi, em hi vọng diễn đàn sẽ sớm có chức năng tìm kiếm bài viết theo tên tài khoản (đặc biệt là các bài viết của anh conmale ).

Thực ra là có rồi chứ nhỉ? Bạn click vào tên nickname sẽ có thông tin các bài viết, các chủ đề của nickname đó tạo mà.

Ví dụ về bolzano_1989

Ngày đăng ký: 30/01/2007 12:49:15
Tổng số bài gởi: [1134] Bài viết của bolzano_1989
Các chủ đề đã tạo: [6] Các chủ đề của bolzano_1989
Bảng đánh dấu: Thành viên này chưa đánh dấu chủ đề nào cả.

vụ tìm trong profile của nickname đó thì bác bolzano_1989 đã có nhắc ở post #1. nhưng cách này sẽ cho ra toàn bộ các topic/comment về nhiều nội dung khác nhau mà nickname đó đã tạo ra.

chắc ở đây, ý bác bolzano_1989 là giả dụ tìm kiếm với 1 từ khoá là "tấn công DDoS" chẳng hạn, với tiêu chí tìm kiếm là theo nickname conmale thì sẽ ra các topic/comment của bác conmale có dính dáng tới từ DDoS.

mình cũng thấy chức năng này cũng khá tiện lợi.

nguyenga86 wrote:

Mình có share internet với một người khác , nhưng hắn rẩt hay download , mỗi lần download cả chục cửa sổ IDM làm mình ko làm gì đc , mình đã lock port 80 , 8080 , 3128 trên modem , set ULR filter block toàn bộ link có chứa http , nhưng chẳng hiểu hắn dùng cái gì vẫn download được . nói chuyện với hắn thì hắn cứ ừ xong lại đâu đóng đấy , ko share nữa thì hoá đơn internet hơi nặng ... có ai biết cách vẫn vào đc mạng hay download khi modem bị config như trên ko ? làm sao để ngăn chặn ?

tìm hiểu xem con router ADSL của bạn có hỗ trợ bandwidth limit/management không? cấu hình nó để có thể:

- giới hạn download/upload speed cho từng protocol (HTTP, FTP,...) hoặc port cụ thể.

- định mức dung lượng (quota) download/upload cho từng địa chỉ MAC, IP, service (Web, VoIP,...).

- giới hạn số lượng connection đến từ địa chỉ MAC, IP nào đó trong LAN.

Eagle007 wrote:

cám ơn các anh admin, mod và xsecure đã quan tâm tới topic em đã tìm ra đc giải pháp rồi, cám ơn mọi người rất nhiều

thử chia sẻ các giải pháp mà bạn tìm được đi, để anh em học hỏi thêm.

sungak wrote:

Hehe, thế quái nào ở đây lại liên quan đến bản khai ngược nhỉ
Khi gõ nslookup nó báo như trên tức là DNS có địa chỉ IP nhưng chưa có tên -> chỉ cần khai báo 1 bản khai A ứng với tên DNS trỏ về IP là 192.168.1.2

Liên quan tới reverse DNS lookup (PTR record) là bởi vì:

hoinongdan wrote:

Mình cài đặt dns xong và đã tạo tên miền là ttdt.com, khi tạo thì không thấy báo lỗi nhưng khi hoàn thành đánh lệnh nslookup xem thế nào thì báo lỗi sau:
DNS request timed out.
timeout was 2 seconds
*** Can't find server name for addrress 192.168.1.2: Time out
Default Server: UnKnow
Address: 192.168.1.2
Bạn nào biết lỗi có thể chỉ giúp và sửa hộ, cám ơn

--> chủ topic gõ vào IP (192.168.1.2) để truy ra domain name tương ứng --> cần có PTR record trong DNS.

--> lý giải về dòng UnKnow này thì như Cuc.Sat đã giải thích đích xác ở dưới:

Cuc.Sat wrote:

hoinongdan wrote:

Mình đã tạo một cái Record A có địa chỉ như bạn nói. "Thiếu Reverse" DNS bạn có thể nói rõ hơn được không, mình đang học về dns

Hihi, em nhầm. Anh tạo PTR record (trong Reverse Lookup Zones).
Sở dĩ default server là unknown do trong IP configuration anh chỉ khai báo IP của DNS server mà không khai báo tên. Khi chạy nslookup, hệ thống sẽ query DNS server để lấy tên của chính DNS server từ IP. Do trên DNS server của anh thiếu PTR record nên không thể phân giải IP thành tên được --> hiện ra là Unknown.
Nhiều khi sách vở không nói hết mọi vấn đề, nhiều cái vẫn phải suy luận

nhiều khi source cài Win2k3 bị lỗi cũng tạo ra thông báo lỗi kia trên máy client khi join vào domain. bữa có 2 người bạn của mình cũng gặp phải lỗi đó, dù đã rà soát kỹ lại cấu hình của DNS tại server và cài lại DC, cũng đã gõ đúng domain và điền đúng Preferred DNS server tại client cũng vẫn bị lỗi vậy.

chủ topic down source Win2k3 khác về làm lại xem.

shuichi_akai wrote:

Why so serious?

Nếu mà bắt bẻ ra ngô ra khoai thì phải goi là CPU Intel 80386 thế hệ thứ n mới chính xác. x86 nói chung là cách gọi các CPU (Intel, AMD, VIA) nói chung trên nền tảng x86 chứ không phải là SPARC hay PowerPC hay cái gì khác. AMD x86_64 là tập lệnh thêm vào sau này trong các CPU x86 để gia tăng không gian địa chỉ bộ nhớ lớn hơn. Nói vậy chắc bạn hiểu rồi chứ?

Xin lỗi vì hơi OT.

Mình hiểu,

mình cũng quá cứng nhắc và bắt bẻ không đâu.

với cấu hình con Dell đó thì myquartz chỉ muốn hướng mọi người tập trung vào OS cho nền x86 thôi, thế cũng đúng. còn các anh em khác thì đang bàn rộng ra các kiến trúc khác, OS khác để mở rộng thêm cho tiêu đề: "Giải pháp hệ điều hành cho server ngân hàng", cũng không sao.

smilie

shuichi_akai wrote:

Bây giờ nói x86 thì nên hiểu là đã bao gồm x86_64, có phải là thời Pentium 4 nữa đâu mà CPU không hỗ trợ 64bit rồi cãi nhau.

Làm việc với Oracle DB mà bảo chọn Windows Server thì có vẻ não hơi thiếu máu.

--> Nếu myquartz nói rõ là "cần OS cho x86_64 architecture" (CPU Intel Xeon mà chủ topic đang có là dạng kiến trúc này) thì mình không reply lại làm gì. Nói x86 thì mình hiểu là 32-bit processor thôi, còn chỉ rõ ra là x86_64 (một extension của x86) thì mới thể hiện được là CPU hỗ trợ 64-bit và tương thích ngược với cả code 32-bit. Mình thì cần sự chính xác như vậy, không như các bro khác là có thể hiểu ngầm, bao hàm này kia được.

myquartz wrote:

Chủ topic đang nói cần OS cho nền tảng x86 mà cứ IBM AIX với HP-UX, Solaris chạy Sparc thì nói làm gì. Giá bọn đó thì cứ gọi là cắt cổ.

Quan trọng là: OS nào cho máy chủ x86 (ví dụ mua máy Dell, chỉ có mỗi cái loại này, như bác chủ Topic đang có).
Nói ngắn gọn chỉ có 2 lựa chọn ở VN và đảm bảo được cho enterprise:
- Windows Server hoặc
- RedHat Enterprise Linux thôi.

--> post #1 của chủ topic đâu có dòng nào nói "cần OS cho nền tảng x86" đâu.

theo mình biết thì các x86 (32-bit) processor ở non-PAE mode thì chỉ support không quá 4GB RAM
http://en.wikipedia.org/wiki/RAM_limit#32-bit_x86_RAM_limit

vậy với 8GB RAM + CPU Intel® Xeon® Processor E5620 của con Dell mà chủ topic đang có thì phải chọn OS nào support x64 architecture chứ.

--> ở trường hợp này, với yêu cầu này của chủ topic thì không chơi với Windows Server làm gì. bạn lại đi lạc đề.

Thêm 1 bài tham khảo khác cho vấn đề bạn hỏi:
http://www.facebook.com/groups/vietlug/doc/227702817250604/

tuanmd wrote:

Em có vài câu hỏi về Linux muốn mọi người có thể trả lời dùm em, để em (các bạn) có thể hiểu hơn về HDH Linux. Từ đây có thể định hướng minh bắt đầu học từ đâu, học về cái gì ?

1. Các phiên bản được dùng nhiều nhất hiện tại ? Nó giống nhau và khác nhau chỗ nào ?
2. Các phiên bản sử dụng khác nhau những gì ? (giống và khác nhau)
3. Các phiên bản ra cùng thời điểm có gì giống nhau và khác nhau ?

Mong ai có thể trả lời dùm mình. Mình muốn định hướng rõ ràng 1 chút.

Thanks mọi người nhé ..

3 câu của bạn gút lại chỉ còn 2 thắc mắc chính:

1. Các distro nào hiện tại được sử dụng phổ biến?

--> tham khảo danh sách này
http://distrowatch.com/dwres.php?resource=major

trang này cũng liên tục cập nhật thông tin về các distro, đánh giá và xếp hạng cho các distro được người dùng quan tâm nhiều. qua đó bạn cũng sẽ phần nào thấy được sự giống và khác nhau giữa các distro
http://distrowatch.com/

2. Các phiên bản Linux (distro) có gì giống và khác nhau?

tham khảo ở đây:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions

thử compare side by side (giữa 1 distro này với 1 distro khác) ở đây:
http://polishlinux.org/choose/comparison/

SITRUMITEE wrote:

Các bạn cho help mình vói:
mình đã mua 1 tên miền vd: abc.com tại mắt bão
mình xây dựng 1 web server trên fedora 6 với dns là : abc.com
trong Lan đã phân giả được abc.com
bây giờ làm sao để bên ngoài có thể phân giải được abc.com và truy cập web ok

trên modem đã NAT port ok, khi ở ngờai internet vào bằng ip thì ok

Thanks các bác nhiều

--> trong LAN, bạn có dựng 1 DNS server cho domain abc.com không mà phân giải được như vậy?

nếu public IP gán cho modem của bạn là kiểu động (tức bạn không có 1 IP tĩnh cho cổng WAN của modem) thì rất khó khăn và bất tiện cho web user khi muốn truy cập tới web server của bạn vì IP WAN kia có thể thay đổi mỗi khi modem reset hay có vấn đề về kết nối tới ISP --> ánh xạ (record) của IP WAN - domain abc.com trong DNS cũng phải thay đổi theo --> nếu record đó trong DNS chưa được update thì user phải truy cập tới server với IP WAN hiện tại được gán cho modem của bạn --> rất phiền phức!

nếu vẫn muốn dựng web hosting tại nhà thì chọn 1 trong 2 phương án sau:

+ mua 1 IP tĩnh cho kết nối WAN của modem rồi cấu hình DNS theo hướng dẫn của hosting provider.

+ bỏ luôn abc.com và sử dụng Dynamic DNS để giải quyết chuyện IP WAN là kiểu động.

cả 2 cách bạn đều phải NAT port trên modem để điều hướng web user tới web server trong LAN.

cuối cùng, nếu thực sự bạn muốn website được host tại nhà hoạt động ổn định thì cần tăng băng thông kết nối Internet, tăng khả năng xử lý của PC làm server và am hiểu thêm các phương thức bảo vệ an toàn cho hệ thống web. không biết bạn thử nghiệm chơi chơi hay cho website tại nhà đó hoạt động thường xuyên nhỉ?