Messages posted by: Mr.Khoai

Xin chào các bác,

Muốn phân tích lợi/hại của password vs. public key thì mình phải hiểu rõ cách làm việc của SSH server và client khi sử dụng password và public key infastructure như thế nào. Sử dụng password thì khá đơn giản. Bỏ qua quá trình SSL Initialization, SSH chẳng khác chi telnet. User nhập password vào interactive session rồi phía server sẽ authenticate username và password đó. Vậy nếu user dùng public key thì server và client sẽ hoạt động thế nào? Có tổng cộng bao nhiêu cái public key và private key được sử dụng với 1 server và 1 client? Vậy còn trường hợp 1 server, 1 user với nhiều clients khác nhau?

Điểm yếu của password thông thường là do dễ bị đoán hoặc brute force như nhiều người đã trình bày. Nhưng nếu như anh lamer nói: Có tool generate một password đủ dài và phức tạp, user chỉ cần copy và paste khi đăng nhập bắng SSH thì password này chưa chắc là "yếu" hơn public/private key về mặt cryptology.

Cá nhân khoai thấy điểm mạnh khi sử dụng password là password không cần lưu lại trên một máy nào cả. Cộng với một yếu tố khác (như public/private key) có thể tạo thành two-factor authentication: Phải có private key, và phải biết password. Nếu password được generate và được lưu lại (đơn giản vì không thể nào nhớ được) thì mình mất đi một yếu tố xác nhận user.

Việc nên sử dụng cái nào hay hơn thì tùy. Public key không có passphrase thì dùng cho mấy cái remote batch job rất tốt. Password thì không bị lệ thuộc vào tính bảo mật của máy client để lưu lại private key. Nhưng cái nào cũng có điểm yếu của nó cả.

khoai

hizit91,

Coi lại bài của mybb đi smilie

Vậy ICMP do tầng nào xử lý transport hay network?

khoai

Phó Hồng Tuyết,

Đừng có lấy cái iptables script của anh conmale mà chạy đại. Bạn chỉ nên đọc để tham khảo thêm cách anh conmale triển khai firewall cho một forum như HVA là thế nào, sau đó tự bạn nên viết lại một cái firewall để thích hợp với yêu cầu cá nhân của bạn. Chạy script của ảnh thì chả hiểu thêm được gì đâu.

Trước tiên nên tìm hiểu về iptables đã. Các chains, các rules được áp dụng thế nào? Các modules nào trong kernel hỗ trợ cho iptables? Và hỗ trợ như thế nào?

khoai

dragonball,

pango của bạn có support Cairo không? Configure có chỉ định rõ path đến pango chưa?

khoai

hizit91,

Trả lời rất hay. Vỗ tay! Như vậy, hệ thống routing sẽ dựa vào các yếu tố sau để làm việc:

1. Network mask: Match càng nhiều bits thì càng chính xác. Và route nào match càng nhiều sẽ được chọn.
2. Metric: Nếu trường hợp có nhiều routes match rules ở trên, Metric sẽ được dùng đến để chọn xem nên dùng route nào là tốt nhất.
3. Order: Giả sử Metric trùng luôn thì chỉ việc sử dụng đại một interface nào đó. Cụ thể, windows sử dụng thứ tự của các interface để chọn một interface thích hợp.

À, vậy là Windows sẽ không send broadcast ra cả 3 interface cùng lúc (thử hỏi tại sao?) mà sẽ chọn interface đầu tiên, ở đây là 192.168.1.3 vì đó là physical interface. Hamachi tạo một interface giả sẽ xuất hiện sau physical interface này. Do đó, muốn dùng Hamachi phải đưa Hamachi Interface lên trên Physical Interface này.

Ủa, mà có gì mà sức cùng lực kiệt?
khoai

hizit91 wrote:

Cái này mới thú vị, em đã đọc được trong cuốn "TCP ...." ở tầng IP thì phải.....,
Để hiểu được đường đi của gói tin có IP đích bất kỳ, ta cần biết đến "routing table", tầng IP dùng bảng này để định hướng đường đi của gói tin tới interface được chỉ định.

Chính xác. Muốn biết một gói tin được chuyển đi thế nào thì phải hiểu rõ cơ chế hoạt động của routing. Và routing hoạt động ở IP Layer. Nó không quan tâm đến cái gì ở trên hay ở dưới nó.

Nhưng, bạn vẫn chưa trả lời hết 3 trường hợp mà khoai nêu ra. Đúng là với destination IP là 5.123.123.123 hoặc 5.156.188.123 thì máy sẽ chọn Hamachi Interface. Vậy còn trường hợp A và trường hợp C thì sao?

Mở rộng thêm một chút, chú ý 3 dòng cuối cùng của routing table. Nếu mình send ra ngoài một gói broadcast với destination IP là 255.255.255.255 thì làm sao phân biệt interface nào mà send đi? Còn cái Metric trong routing table đó là cái gì? Được dùng đến khi nào?

Hm....ý của bạn mà lại không nói thì làm sao khoai đoán biết được?

khoai

hizit91,

Cái proposal mà RFC 947 đề nghị giống với trường hợp của bạn ở điểm là khi send broadcast thì send ra trên nhiều interface mà máy đó đang điều khiển (cho dù là interface thật, hay ảo do Hamachi tạo ra). Nhưng khác nhau ở điểm bạn không cần làm vậy vì bạn chỉ cần sử dụng Hamachi để chơi game, còn interface kia không cần nhận gói broadcast đó.

Máy của bạn có một IP là 192.168.1.3/24, và một IP mà Hamachi sử dụng 5.156.188.157. Khi bạn send ra ngoài một gói tin đến các IP sau:

a. 192.168.1.5
b. 5.156.188.123
c. 1.2.3.4

thì chuyện gì xảy ra? Làm sao OS quyết định send ra interface nào? Và vì sao lại quyết định vậy? Vậy còn broadcast thì nên làm thế nào? Và giải pháp broadcast ra tất cả các interface so thực tiễn hay không? Vì sao RFC 947 kia đã viết từ hồi 1985 mà đến nay vẫn chưa được ứng dụng?

Mời thảo luận cho vui smilie

khoai

hizit91 wrote:

Có lẽ cách viết của em khiến mọi người khó hiểu, em đã cố gắng cho nó đi theo trình tự thế này :
Đầu tiên, ta gặp một vấn đề trong thực tế, ở đây là việc "không chơi được các game multiplayer qua hamachi", từ vấn đề đó lại đặt ra nhũng câu hỏi( hay vấn đề) mang tính kĩ thuật (ở đây là vấn đề "Broadcasting tại host được kết nối tới nhiều Mạng"), em đã cố gắng trình bày cả một quá trình đi từ "game" --> "vấn đề kĩ thuật" của một học sinh 12 mới có những bước đi chập chửng vào "Nền tảng công nghệ về Mạng".
Cách thức tìm tòi này, theo em có thể mở rộng cho nhiều vấn đề khoa học khác, là cách thức đi từ một vấn đề thực tiễn, tới sự am tường, mở rộng những kiến thức nền tảng về vấn đề , sau cuối những kiến thức này lại cho ta nguồn "nội lực" để chinh phục những thách thức lớn hơn.

Chính xác! Từ những vấn đề thực tiễn hằng ngày ta có thể mở rộng ra nhiều hướng để học tập và nghiên cứu về IT nói chung một cách sâu sắc hơn.

hizit91 wrote:

Em thừa nhận vấn đề (1) ở trên, theo như cách khai triển bài viết đã nói ở trên, đầu tiên điều này(1) chính là thắc mắc của em, qua quá trình "ngâm cứu" thì "cậu học sinh 12" đã biết được điều này và nêu lên "Đề xuất về cronus trong RFC 947" có liên quan tới ý (2) mà anh Mr.khoai nói.

Khoai có đọc sơ sơ về RFC 947 mà bạn đề cập. Có vẻ như khái niệm Broadcast repeater hoàn toàn không thích hợp trong trường hợp này. Cái broadcast repeater mà RFC 947 đề cập là một thiết bị kết nối nhiều network/sub network với nhau, và chuyên relay các broadcast packets mà nó nhận được sang các network/sub network đó.

hizit91 wrote:

Tuy vậy em cũng cần nhấn mạnh một ví dụ em đã nêu trong bài là " dịch vụ chia sẻ file của windows hay tổng quát hơn là tất cả hoạt động Workgroup đều suôn sẻ qua hamachi". Điều này nói lên rằng Windows đã áp dụng những thứ đại loại như Cronus để phục vụ cho Workgroup, từ đó em đã nêu lên đề xuất "Viết một lớp hỗ trợ cho Windows, một thứ tương tự như Cronus, để áp dụng được cho tất cả các ứng dụng."

Không hẳn là vậy. Theo khoai được biết dịch vụ file sharing của Windows sử dụng multi-cast, không phải broadcast. Và, game bạn chơi không được chưa hẳn là do chuyện network của bạn có vấn đề. Cả hai dịch vụ (game và filesharing) đều sử dụng chung network stack của Windows, do đó có thể vì một lý do nào khác khiến cho game của bạn không chơi được (firewall, cấu hình game sai sót, vân vân).

khoai

hizit91,

Đầu tiên phải nói là bạn cố gắng tìm tòi từ một vài điều khó hiểu ra cả chục điều không hiểu là chuyện rất đáng...vỗ tay tuyên dương trước bà con. Nhưng mà khoai đọc đi đọc lại bài đầu (thay đổi vài chục lần) mà vẫn chưa hiểu ý bạn có gì thắc mắc và có gì không hiểu. Khoai nghĩ bạn nên làm quen cách diễn đạn đầy đủ, nhưng ngắn gọn, thay vì viết văn kể chuyện smilie

Khoai cố gắng trả lời/mở rộng các điểm mà khoai nhận được từ bài đầu tiên.

1. Game hay applications nói chung không quan tâm đến NIC hoặc card mạng là gì cả. Applications đơn giản chỉ yêu cầu gửi dữ liệu đến một IP hoặc một hostname nào đó. Chính OS sẽ lo việc truyền tải như thế nào. Hay cụ thể hơn, chính network sub system của OS sẽ lo vụ này.

Do đó, việc máy của bạn send broadcast ra interface với IP là 192.168.1.3 là do cấu hình của mạng, không phải do applications.

2. Để gửi dữ liệu ra tất cả các network interface, bạn cần thao tác trực tiếp với phần output của network sub system. Khi dữ liệu muốn được gửi ra ngoài, network sub system sẽ kiểm tra xem: Nên chọn source IP nào cho thích hợp, và với source IP đó thì device nào là thích hợp để gửi ra.

khoai

xuduaqueanh,

Nếu khoai nhớ không lầm thì chính khoai là người xác nhận cho nick của bạn. Bạn không nên sử dụng nhiều nick làm gì, cho dù bạn dùng cả chục nick thì chắc cũng khó mà biết được. Mỗi thành viên đang ký thì các moderators hoặc validating moderators đều xem lại tên nick và tên địa chỉ e-mail có thích hợp hay không trước khi xác nhận việc gửi e-mail để kích hoạt nick đó. Lý do có việc này là trước kia có nhiều tình trạng các thành viên đăng ký nick không thích hợp, hoặc để lọc lại các nick dạng quản cáo trên forum.

Sau khi đăng ký, bạn nên chờ một khoản thời gian (ít hơn 24 giờ) thì đảm bảo sẽ nhận được email kích hoạt.

khoai

HacBit, đề nghị bạn không viết bài bằng CHỮ IN. khoai +1 warning cho bạn!

khoai

nvmanh1990,

khoai vẫn không hiểu "Install inside windows" thì wubi làm như thế nào. Đoán già đoán non là Wubi tạo một file "X" nào đó với dung lượng lớn làm root filesystem cho Ubuntu, rồi đặt trong ổ E: của bạn.

Như vậy, bạn có thể thử mout sda2, sda3 hoặc sda5 (là một trong các partition có dung lượng khoảng 60Gb) để thử xem cái nào là ổ E:. Vì ổ F: (Multimedia) đã được mount tại /media/MULTIMEDIA, bạn có thể sử dụng output của lệnh
Code:

$ mount -v

để biết partition nào đã được sử dụng, và partition nào vẫn chưa xài.

khoai

phpvirus,

Ah, default không cấu hình PermitRootLogin (comment nó ra) thì bạn vẫn login bằng account root được. Ý anh quanta ở đây là không nên cho account root login remotely bằng cách

- Chỉnh PermitRootLogin thành No
- Xác định rõ user nào được login bằng AllowUser.

Khoai không thích blacklist IP vì có trường hợp mình có thể có một user nào đó sử đụng trúng một trong các IP bị blacklist thì khổ.

anhsaobang,

Câu thông báo trên của bạn là user root không phải là một trong các user được phép log in remotely, cấu hình cụ thể bằng AllowUser Option. Đụng trúng tình trạng này thì ssh có lẽ sẽ không kiểm tra password, nên không thể khẳng định là đúng hay sai password được.

khoai

phpvirus,

Bạn chưa config gì cả nhưng có thể chính distro đã cấu hình sshd_config để disable root login rồi. Xem lại file sshd_config, tìm đoạn AllowRootLogin để biết rõ thêm.

Việc bruteforce không nhất thiết là tấn công vào root account, mà còn có thể tấn công vào các account "thông dụng" như test, admin, user, apache, vân vân. Tốt nhất là sử dụng PAM, hoặc chính sshd_config để chỉ cho phép một số user nào đó login remote mà thôi. Limit thêm số lượng connection để giảm hiệu quả của việc bruteforce.

khoai

longvnit wrote:

hihi . ý em là file đó các bro hay áp dụng cho webserver mà bro cấu hình .
Newbie hỏi mà các bro chém dử quá (

Mỗi site có cấu hình, nội dung và các tiêu chuẩn bảo mật khác nhau. Không hề có chuyện một file mod-security nào đó có thể xài chung cho tất cả mọi người. Bạn nên tham khảo lại xem cần có những yêu cầu gì cho việc sử dụng mod security, sau đó tìm hiểu xem cấu hình thế nào mới đạt được các yêu cầu đó. Vậy là chuẩn.

khoai

angelforever wrote:

ban oi ba o dau vay minh` co the hoi ban them mot so' van de doc chu' tai min`h o q12 neu ban o gan`do' thi mi`nh tien chao doi ban thay sao

Đề nghị bạn tập viết tiếng Việt có dấu!

khoai

hellloeverybody wrote:

Tui cũng đã nhiều lần chmod cái như vậy nhưng mà chown của nó vẫn là Unknown User và Unknown group trong khi bạn tạo file đó với đặc quyền root chú ý cái này nhé Sử dụng MC mà thiết lệnh cho dễ bạn à

Good luck!

khoai không hiểu đoạn chown vẫn là Unknown User và Group? Bạn giải thích rõ hơn được không? Thônt thường khi ls -al mà owner và group bị unknown là do bạn mount partition được sử dụng bởi một hệ thống nào khác. Trên hệ thống kia, userid của owner đó không tồn tại trên máy đang chạy nên mới có hiện tượng trên. Chỉ cần chown trở lại cho đúng với owner chính xác là được.

khoai

quanta wrote:

FaL wrote:

Chào St Konqueror,
Nhu cầu của bạn là trao đổi dữ liệu giữa 2 máy? Tớ không biết cái cáp qua USB này nó thế nào, nhưng nếu chỉ là trao đổi dữ liệu thì có thể trao đổi qua mạng được. Bạn tìm mua 1 đoạn dây mạng nối 2 máy với nhau là giải quyết được vấn đề này.
Thân mến.

Nhớ là cáp chéo (crossover cable) nhé, windows hay Linux không cần quan tâm.

Anh quanta,

Nhiều khi straight-through cũng xài được, mặc dù đúng ra là phải dùng cáp chéo. Các NIC "hiện đại" bây giờ có thể tự động detect và auto-crossover ở chính NIC. Cái này rất tiện lợi vì người dùng bình thường chỉ cần straight-through để kết nối đến switch, routers, hubs, hoặc trực tiếp đến một máy khác mà không cần quan tâm nhiều.

khoai