Messages posted by: myquartz

Modem này của bạn là Modem cable, chạy qua cáp truyền hình. Cái này ở VN mới có 1 ít người sử dụng, cáp của SCTV.

Hơn nữa, cái modem của bạn đã bị .... lock với nhà cung cấp dịch vụ đó rồi (cái Cable Modem Certificate đó). Chắc là đồ khuyến mại đi kèm khi mở dịch vụ truy cập qua cáp. Chỉ có nhà cung cấp mới mở được nó để bạn có thể thiết lập được.

Để chia sẻ Internet, bạn phải dùng 1 router khác cắm vào cái modem này, bạn cho biết cái router đó nó setup ra sao, thông số status, IP WAN của nó là gì xem. Nếu IP WAN là public, thì có khả năng sẽ setup được.

Bấm số 0 là vào Shell mà. Có cái menu đó cũng tiện, nhất là reboot máy, ko cần password.

Sửa như thế này:

# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller
DEVICE=eth1
BOOTPROTO=none
HWADDR=00:1a:4d:5d:52:67
ONBOOT=yes

Là được.

Đừng tạo cert mới, hãy renew (hay nói cách khác là ký lại các cert request), rồi gửi cho họ cái cert mới để overwrite lên là xong. Key vẫn như cũ, mọi thông số như cũ, chỉ khác là ký ở thời điểm mới nên expire mới.

Với Fedora 11, để đảm bảo an toàn, với user root nó không tự mount khi click, mà thực chất là qua gvfs (nói hơi khó hiểu nhưng đó là tool tự động mount các đĩa trong giao diện gnome/nautilus). Muốn mount khi login as root thì phải xài lệnh.
Bạn nên xài user bình thường, dùng các ứng dụng cũng như vậy mà thôi, gõ pass root nếu có tác vụ cần (nó chỉ hỏi 1 lần duy nhất thôi), còn thì với GUI ko nên xài root để làm gì cả.
Bạn có thể chạy ứng dụng System => Preference => Authorizations. Nếu hiểu 1 chút bạn có thể config để cho phép/không cho phép ai đó (trừ root) mount qua gvfs các loại đĩa khác nhau mà có hỏi pass hay không.

Nếu ở Sài Gòn, ra tiệm Đồng Huy (số mấy ở Tôn Thất Tùng quên rồi, nhưng nó gần kề Nova), tìm mua USB Sound card, có 2, 3 loại gì đó, giá từ $12-$15/1 em.
Nếu ở HN, tìm Hồng Hải New (trong BK hoặc Lý Nam Đế), cũng có 1, 2 loại tương tự.
Nếu nhiều tiền, mua X-Fi ISB của CreativeLab, ở bất kỳ chỗ nào cũng có, giá khoảng $70-$150 tùy loại.

WPA-PSK mà bị "xơi" tốt à? Chắc không? Kể cả có Handshake đủ đi?
Bẻ khóa WPA người ta không còn dựa trên gói ARP nữa đâu. Check lại manual đi.

Nên đi học lớp về kiến trúc máy tính và kiến trúc hệ điều hành (và học linux nói riêng). Chứ các khái niệm nó lẫn lộn thiếu cơ bản thế thì không biết giải thích thế nào cả.

Chú thích nhỏ: không phải thiết bị kiểu nào cũng HotPlug được đâu, và nên học để hiểu thế nào là ngắt cứng và IRQ là cái gì.

Hi!
Theo tớ Comale sử dụng thuật ngữ "dynamic html" và "static html" .. .chưa hợp lắm. Dynamic HTML dễ nhầm với DHTML (viết tắt), là 1 khái niệm với ý nghĩa khác: http://en.wikipedia.org/wiki/DHTML
Cái này ngược với Static HTML, cũng như thế.
Với 2 cái ý nghĩa tương tự như là Comale nói, thì nên được gọi là Dynamic Web Page, và Static Web Page. Xem http://en.wikipedia.org/wiki/Dynamic_web_page
Bài này nói về khái niệm, vì thế nên có ý kiến vậy.

Fedora 7 quá cũ rồi. Cài Fedora 11 đi.

Hi!
Không phài là so sánh. Nhưng tớ xài postfix thay vì qmail vì có 3 cái tính năng này thôi:

I - LDAP intergration: qmailrocks là qmailtoaster đều chơi với mysql cả. Nếu tự làm thì e admin của tớ không patch nổi. (tớ làm được nhưng để mấy cậu đó làm, chớ 1 mình mình bao nhiêu cái khác smilie

).

II - SMTPD: reject when not logged in: cái này mô tả rất dễ. Ví dụ server của công ty abc.com, nhận và gửi mail (tức là mail relay kiêm mail host). Giả thiết ta có 1 user là john@abc.com.
1. john@abc.com muốn gửi mail cho ai đó, ví dụ xx@yahoo.com">xxx@yahoo.com, thì phải xác thực trước, kiểu như: AUTH LOGIN john, .. MAIL FROM: <john@abc.com>, RCPT TO: <xxx@yahoo.com>. Nếu không xác thực thì sẽ không cho gửi đi, server sẽ báo là not allow to relay. Cái này MTA nào cũng có.
2. Mail ở ngoài đến (ví dụ từ domain @yahoo.com), tới john@abc.com. 1 loạt lệnh sẽ kiểu như là: MAIL FROM: <xxx@yahoo.com>, RCPT TO: <john@abc.com>... server chấp nhận chả cần xác thực. Và 1 loạt các thủ tục kiểm tra spam/virus được áp dụng, như là domain nguồn có hợp lệ, from 1 user có hợp lệ ko, có domain key không....
Tuy nhiên nếu 1 thằng spammer nó chơi kiểu: MAIL FROM: <john@abc.com>, RCPT TO: <john.abc.com> thì với server vẫn chấp nhận, dù cái này là địa chỉ giả mạo, MTA check nguồn sẽ là hợp lệ (tất nhiên là còn 1 loạt các thứ khác).
=> Với postfix, tớ có thể setup để mọi email from @abc.com đều ép phải xác thực như trường hợp 1., nếu không thì sẽ là "reject: not logged in". Cái này sẽ giảm được đáng kể spammer lợi dụng vì cơ chế xác định domain gửi đi + check sự tồn tại của host/user nguồn sẽ cứng rắn hơn. Nếu xài bừa from @yahoo.com chẳng hạn, thằng amavis sẽ check được domain key.
Qmail không check được cái này vì 2 giai đoạn xác thực và smtp do 2 process đảm nhiệm. Chưa thử xem Exchange có bị không.
Mỗi ngày server chỗ tớ ghi nhận khoảng 10K cái not logged in này. Chứng tỏ spamer rất khoái trò đó. Hiệu quả đấy chứ?

III- Reject when logged user not match: cái này tương tự như là mục II.1, nhưng là kiểm tra xem người gửi và tên đăng nhập có phải là 1 cặp hợp lệ hay không. Đơn giản là ông john chỉ được phép mail from là john@abc.com. mới gửi được, không thể khác được. Cái này tránh cho user thiết lập nhầm hoặc chống giả mạo. Ông xyz gì đó ko thể from <john@abc.com> được, dù có đăng nhập thành công với user xyz, sẽ nhận được thông báo: "reject: logged user xxx not match with email xxx@xxx".
Cái này có 1 điểm hữu ích: Vì là các bác user rất hay để password dễ đoán (như là 123456), cái này tất nhiên ngoài chính sách ép buộc ra, thì vẫn phải có phòng bị. Tớ đã từng bị 1 gã hacker nào đó, do bằng 1 số cách nào đấy nó đoán được pass của 1 số user. Nó lợi dụng các login đó để gửi mail from <linh tinh>, gửi spam ầm ầm qua server của mình. Hồi đó xài qmail, vì đã đăng nhập nên from cái gì cũng được, chỉ cần domain hợp lệ là xong. Server thì nó ghi nhật ký cái này không rõ ràng lắm, nên mãi mới xác định được gốc và đổi pass của user.
Qmail không check được cái này. Bác nào có Exchange thử xem nó có hỗ trợ không.

Xài Exchange là hàng khủng rồi, tiền nhiều thì xài cái đó. Không chỉ là license mà máy cũng phải khủng, HDD cũng khủng.
Exchange nó có 1 cái khá thú vị, ko phải nói về bảo mật, mà là cái lưu dữ liệu của nó. Nó phình to kinh hãi luôn. User nào cũng muốn giữ email trên server cả, không muốn xoá. Mỗi bác giữ 500Meg (chỉ trong vòng 1, 2 năm) , 1000 users = 500GB, thêm phụ phí nữa thì...

Tính cho lẹ, Exchange cho 1000 user, xài trong 2 năm, đĩa phải cỡ 1TB (để còn RAID nữa) + máy chủ 4 core, 4GB RAM trở lên. Tốt nhất là backup cẩn thận, vì Exchange rất hay bị hư data, mà hư data, phải restore cứ gọi là ... phê. Xài nó rồi, mình sẽ được sếp khen làm việc chăm chỉ (vì xử lý ... sự cố).

Mạng xài M$ rồi thì cài Exchange sướng lắm, nó tích hợp AD xác thực ngon lành, khỏi phải tạo 3000 user lại (chuyển từ Mdaemon sang, nếu cần, thuê tớ, tớ tính phí rẻ thôi).

Tớ xài mấy năm qmail rồi, nhưng giờ chuyển qua postfix cho dễ xài và tính năng phong phú. Nếu xài Zimbra nó dùng postfix sẵn, đừng nghĩ tới qmail. Qmail quả thực là nhẹ, ổn định, nhưng postfix dễ xài, dễ setup hơn và có vài tính năng rất tốt cho việc chống SPAM mà qmail ko có (ví dụ "SMTP reject when not logged in."). Qmail muốn có tính năng gì đều phải chơi patch, compile mất thời gian lắm. Chơi postfix trên CentOS và yum lẹ lắm.

Về ưu điểm, qmail/postfix hay xxx open source gì, đều tốn ít tiền, không phải chỉ là tiền license mà là tiền hardware nữa. Cái postfix + dovecot cơ quan tớ (trước là qmail + vpopmail), 1 máy chủ kiểu PC, RAM 1 GB, đĩa cứng 300GB (2x), dual-core 2.0 GHz, quét virus, chống spam tùm lum đủ cả (ClamAV + amavis), phục vụ 3000 users ngon ơ. Tổng chi phí khoảng: $3000 (tức là $1/user).
Cơ quan của 1 ông bạn, quy mô user tương đương, xài Exchange 2007, phải chơi 1 cái server x3650 2xQuad CPU, RAM 8GB. Hơn thế nữa giải pháp virus cũng khủng, chơi luôn Symantec for Mail server trên 1 server khác tương đương. Tổng chi phí: mỗi server 2x$5000 + Exchange license $2000 + CAL 3000*$30 + Symantec 3000*$15 ~ $150K. Nếu chia theo user: $50/user.
Tất nhiên tiền nào của ấy, Exchange cho email + 100 tính năng. Còn giải pháp kia thì chỉ có email + 10 tính năng thôi. Nhưng căn bản nếu chỉ xài mỗi việc email thì ... như nhau cả. Zimbra thì = email + 70 tính năng.

Chắc vì lý do tốn tiền trên, sếp của bạn mới yêu cầu ... ko sử dụng Exchange, mà phải xài 1 cái gì khác đỡ hơn, ví dụ qmail (chắc nghe loáng thoáng ở đâu đó xài chạy lẹ, tiết kiệm, ổn định).

FastEthernet muốn line protocol up lên, thì phải cắm dây mạng LAN cho nó (vào switch hoặc 1 thiết bị khác), sao cho đèn hiệu của nó sáng xanh lên thì được.
Với Serial (chạy PPP hoặc HDLC) thì đầu xa phải up và đường truyền thông nhau.

Tắc nghẽn mạng LAN? tức là tắc ở các đường truyền mạng Ethernet 100Mbit? Ứng dụng gì mà kinh thế? Nếu thế thì xác định nút cổ chai ở port nào rồi mua cái switch hỗ trợ 1GBit thay vào là ổn. Còn mạng LAN thì phát hiện tắc nghẽn phải cần đến sw có thể manage được, show trạng thái port lên. Hoặc là đơn giản nhìn đèn sw cái này nháy kinh nhất => là bị nghẽn.

Còn nếu tắc đường truyền WAN, VPN hoặc Internet thì phải nói rõ ra, và cần phải có nhiều chiến lược để đạt được chất lượng dịch vụ dù có tắc nghẽn.

Để chặn 1 host nó post quá nhiều thứ vào 1 thời điểm như cái topic lúc đầu. Nếu bạn dùng dedicated server thì nên xài fail2ban (nó cần đến iptables). Chỉ cần monitor các request đến page not found hoặc có log đưa ra 1 thông điệp định trước là được.
Fail2ban nó xem log, rồi tự ban khi phát hiện IP nào đó thực hiện 1 việc gì đó (do mình thiết lập rule) quá n lần/1 đơn vị thời gian. Block luôn IP bằng iptables rule, không cho kết nối luôn. Nó cũng tự giải ban cho IP đó sau 1 khoảng thời gian định trước.
Ví dụ: chặn IP nào post quá 20 lần trong vòng 10 giây, chặn trong vòng 5 phút.

StarGhost wrote:

@myquartz: hình như bạn không rành lắm về việc linux kernel xử lý cái khoản network thế nào ấy nhỉ? Ở trên mrro đã có nhắc đến vấn đề cookies rồi.

SYN flooding ít hiệu quả không phải là vì đã có một fancy mechanism để chống lại nó (kể cả syn cookies cũng chỉ là cực chẳng đã thôi), mà là vì các tay admin có trình độ thì biết cách tune system để "sống chung với lũ", cộng thêm khả năng của hệ thống. Chính vì vậy, nếu một hệ thống hoặc là có ít tài nguyên, hoặc là được quản lý bởi một tay mơ thì việc SYN flooding thành công là đương nhiên, và không cần thiết phải làm nghẽn đường truyền, vì bản thân SYN flooding cũng khó mà làm được như vậy. Những hệ thống như vậy thì nhan nhản ra.

Hì tớ ko phải dân network chuyên nghiệp, chuyên gia StarGhost thi thoảng còn đố về kiến thức network cơ mà. Có cái thông tin gì mới hơn về cái đó thì nói ra đi, chớ úp mở làm gì. Nói ra có khi biết mình đúng/sai ra sao mà.

Cái Class Memcache là 1 extension của php (tên gói là php-pecl-memcache).
Ngoài ra còn cần memcached server (tên gói là memcached), cài vào vào start lên.
Kỹ thuật sử dụng memcache này áp dụng cho khá nhiều site có tải nặng, ở VN đấy, khi muốn lưu lại nội dung tạm thời để tăng tốc và giảm tải cho CSDL, hiệu quả tốt không ngờ đấy. Nhiều Web master giấu nghề nên ko nói ra thôi. Tớ thì dùng nó cho đoạn code chống DoS trên.

Khi bật Syn cookies lên thì còn quan tâm gì được đến cái tcp_synack_retries nữa. OS lúc này nó có lưu được half-open mới vào back-log buffer nữa đâu mà giá trị đó còn ý nghĩa.

Nói chung không nói đến DDoS chung chung, về tấn công Syn flooding thì giờ ít hiệu quả lắm.

Với các site có cường độ hoạt động cao, nhiều kết nối, client hàng xịn là chính, vẫn phải tăng độ dài back-log buffer, nhưng tăng giảm tcp_synack_retries thì không nên (và cũng không cần thiết). Bởi trong điều kiện không bị nghẽn (coi là đường truyền đủ lớn đi), thì haft-open connection được dẹp bỏ khỏi back-log buffer rất nhanh, khi cái ACK của client tới được server, giá trị retries đó nói chung không cần sờ đến.

Cái này đôi khi phải kết hợp với giải pháp network nếu như là đường truyền nó đạt ngưỡng, hay bị nghẽn (vì data, ko phải vì syn/ack nhá), lúc này cần ưu tiên cho các gói ACK đơn thuần (của bất cứ trạng thái nào) tới được server và từ server đi, gói này nhỏ không tốn đường truyền, lại rất dễ làm rule trên router.

Có mấy ý kiến phản hồi nhỏ với chuyên gia StarGhost.

StarGhost wrote:

Khi một hệ thống bị DDoS (SYN-flooding), nhiều khả năng backlog sẽ bị đầy, và OS không thể nhận thêm connections, và phải đợi cho đến khi lifetime của một số connections kết thúc thì mới tiếp tục nhận SYN. Như vậy, việc tăng số lượng retries sẽ khiến tình hình trở nên tồi tệ hơn, vì OS sẽ không có khả năng nhận thêm connections trong một khoảng lớn thời gian (e.g., 180s).

Điều này đúng, nhưng cũng là không đúng vì bất kể lifetime dài hay ngắn, OS cũng ko thể tiếp nhận được thêm kết nối khi đó => kết quả đều là toi như nhau và hầu như ko thể tồi tệ hơn.

StarGhost wrote:

Việc giảm số lượng retries ở một khía cạnh nhỏ có hiệu ứng tốt, vì half-opened connection lifetime sẽ giảm, dẫn đến OS sẽ nhanh chóng loại bỏ half-opened connections và nhận các SYN mới. Tuy nhiên, điều đó cũng có nghĩa là khả năng legitimate peer có thể connect đến cũng giảm mạnh, vì 2 lí do:
- Trong khi bị DDoS, legitimate peers có rất ít cơ hội để nhảy vào được backlog.
- (cũng) trong khi bị DDoS (massively), việc packets loss là đương nhiên (gồm syn, syn/ack, ack), nên retransmission là cần thiết.

Cuối cùng, việc giảm số lượng retries không thực sự cải thiện được tình hình DDoS, vì attacker chỉ cần tăng attack frequency thì mọi việc lại như cũ.

Đúng là giảm retries ở một mức độ nào đó thì mọi sự "có thể" vẫn có hiệu ứng tốt hơn, nhưng không phải mặt tạo thêm kết nối, nó chỉ giải quyết vấn đề là hệ thống không bị quá tải về tài nguyên CPU, memory, port number..., chứ server vẫn không tiếp nhận được kết nối, vì thế việc giảm retries không phải nhằm mục đích để server tạo được thêm kết nối mà là giảm sự lifetime tài nguyên vô giá trị (nếu có thể). Một điểm nữa là khi tấn công SYN ngưng lại thì server trở lại trạng thái phục vụ được sẽ nhanh hơn, do lifetime ngắn.
Nhưng giảm thấp quá, ví dụ retries 1 lần thôi, sẽ có thể ngăn trở các legitimate peer có đường truyền tệ hoặc đang bị tắc nghẽn, và vô tình làm cho các peer gửi đi gửi lại gói SYN nhiều lần và vô tinh trở thành ... máy tấn công.

- OK, đúng, khi bị DoS thì legitimate peers có ít cơ hội vào đc backlog, nhưng được khắc phục bằng cách khác, xem ở dưới.
- Sai: Khi bị SYN flooding, việc mất packet sẽ vẫn ít khi xảy ra (nghĩa là không có tắc nghẽn), bởi đơn giản là là gói SYN nó rất bé và thường thì khả năng đáp ứng của đg truyền của server là thừa sức. SYN flood là cách tấn công của những client có băng thông nhỏ, với mục tiêu tốn ít để đạt đc kết quả. Nó làm cho server đầy backlog không thể nhận thêm kết nối chứ không phải là nhằm làm cho đường truyền bị nghẽn. Nếu muốn làm đường truyền nghẽn, người ta gửi gói thật to như là ICMP to hay UDP to, chứ không gửi gói TCP SYN bé tí làm gì.

Cách người ta chống back-log bị đầy: ví dụ Linux nó dùng Syn Cookies http://en.wikipedia.org/wiki/Syn_cookies), Khi back-log bị đầy, linux host vẫn trả lời gói SYN gửi tới bằng 1 gói tin SYN-ACK với cái sequence là 1 giá trị được tính toán đặc biệt gọi là cookie, nó không cần lưu cái haft connection này và không cần back-log buffer đang bị đầy kia. Nếu client xịn, nó sẽ reply cái gói SYN-ACK của server kia bằng 1 gói ACK có chứa cái seq đúng là cái cookie của server kia. Server nhận được gói ACK, check được đúng cookies mà mình gửi, cho dù không tìm được haft connection trong backlog tương ứng với cái ACK này (lúc trước có lưu đâu?), nó vẫn cho tạo kết nối và kết nối được thiết lập với đủ 3 bước, và mặc kệ cái back-log đang bị full.
Tất nhiên lúc này sẽ chậm hơn 1 chút đối với các client xịn mà có đường truyền tệ, vì nếu SYN-ACK trả lời mà bị mất, server sẽ không retries việc gửi này (vì có lưu lại đâu mà biết retry?), client sẽ buộc phải gửi lại SYN mới và sẽ nhận SYN-ACK khác. Tham số retries lúc này cũng vô nghĩa.
Và mọi thứ vẫn chạy được, kệ SYN flooding.

Hi!
Thấy vài member thảo luận về code chống DOS. Tớ góp 1 tí cho vui.
Đây là đoạn code tớ đã áp dụng 1 cho 1 site của tớ, nó có khoảng 5000 keep-alive session, 10K IP khác nhau truy cập hàng ngày, site cung cấp thông tin trực tuyến nên mỗi client request khoảng 5-7 giây 1 lần, với 18-20 triệu hit/ngày (cường độ khá kinh khủng đấy).

code này áp dụng cho php. Phải kết hợp với memcache để đảm bảo tốc độ (1 ứng dụng khá là ... hay đấy). Nếu dùng mysql cũng đc, với memory table, nhưng ko hay lắm vì mysql nhiều overhead hơn nên chậm hơn.

Code:

$antiflood = 4; // anti-flooding protect time in seconds.
$MCobj = new Memcache;
if(!$MCobj->pconnect($MCHost, 11211))
$MCHost = null;
else if($debug) echo "<debug>Connected to cached</debug>";
//Anti flooding
$pattern = '/^(10\.|192\.168\.|127\.)/';
if($MCobj && !preg_match($pattern,$_SERVER['REMOTE_ADDR'])) {
$protectedkey = 'ip'.$_SERVER['REMOTE_ADDR'].'-'.$_SERVER['SCRIPT_FILENAME'];
$isquery = $MCobj->get($protectedkey);
if($isquery) { // query too fast
echo 'Server too busy, please visit later.;
exit();
}
$MCobj->set($protectedkey, 1, 0, $antiflood);
}

Chúc các bạn thành công.

Hi!
Tớ có vài cái web site, tất cả đều chạy CentOS.
Tuy nhiên, tớ rất nhiều lần đọc được logwatch của server báo lại dường như có sự "probe" cái server của mình như sau:

Code:

A total of 17460 unidentified 'other' records logged
GET /administrator/backups/oldfiles HTTP/1.0 with response code(s) 404 1 responses
GET /help/70-351/Bai2/incoming HTTP/1.0 with response code(s) 404 1 responses
GET [b]/administrator/images/global.asa.old[/b] HTTP/1.0 with response code(s) 404 1 responses
GET /help/K01MB/70-620/tests HTTP/1.0 with response code(s) 404 1 responses
GET /administrator/mp3 HTTP/1.0 with response code(s) 404 1 responses
GET /help/70-291/global.bak HTTP/1.0 with response code(s) 404 1 responses
GET /help/K01MB/70-620/network HTTP/1.0 with response code(s) 404 1 responses
GET /mambots/search/tree HTTP/1.0 with response code(s) 404 1 responses
GET /media/new HTTP/1.0 with response code(s) 404 1 responses
GET /help/pass HTTP/1.0 with response code(s) 404 1 responses
GET /language/cgi-bin HTTP/1.0 with response code(s) 404 1 responses
GET /mambots/info HTTP/1.0 with response code(s) 404 1 responses
GET /forum/templates/subSilver/images/support HTTP/1.0 with response code(s) 404 2 responses
GET /help/70-351/Bai6/ccbill HTTP/1.0 with response code(s) 404 1 responses
GET [b]/help/70-270/Global.asax.orig[/b] HTTP/1.0 with response code(s) 404 1 responses
GET /img/save HTTP/1.0 with response code(s) 404 1 responses
GET [b]/language/Global.asax[/b] HTTP/1.0 with response code(s) 404 1 responses
GET /forum/templates/subSilver/images/lang_english/export HTTP/1.0 with response code(s) 404 1 responses
GET /forum/templates/subSilver/images/lang_english/cert HTTP/1.0 with response code(s) 404 1 responses
GET /forum/cache/CVS/Root HTTP/1.0 with response code(s) 404 1 responses
GET /administrator/index2.backup HTTP/1.0 with response code(s) 404 1 responses
GET /help/70-351/Bai5/purchase HTTP/1.0 with response code(s) 404 1 responses
GET /mambots/_logs HTTP/1.0 with response code(s) 404 1 responses
....
GET [b]/_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0[/b] HTTP/1.1 with response code(s) 404 1 responses
GET /MSOffice/cltreq.asp?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.0 with response code(s) 404 1 responses
GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6403&STRMVER=4&CAPREQ=0 HTTP/1.0 with response code(s) 404 2 responses
POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1 with response code(s) 404 2 responses
GET /installation/ HTTP/1.1 with response code(s) 404 4 responses
GET /_vti_bin/owssvr.dll?UL=1&ACT=4&BUILD=6254&STRMVER=4&CAPREQ=0 HTTP/1.0 with response code(s) 404 1 responses
...
GET /cgi-bin/nph-test-cgi HTTP/1.1 with response code(s) 404 1 responses
GET [b]/wsasp.dll/WService=wsbroker1/webutil/ping.p[/b] HTTP/1.1 with response code(s) 404 1 responses
GET /cgi-bin/mapserv?map=nessus.map HTTP/1.1 with response code(s) 404 1 responses
GET /index.cfm?Mode=debug HTTP/1.1 with response code(s) 404 1 responses
GET [b]/CategoryView.aspx?category=nessus[/b] HTTP/1.1 with response code(s) 404 1 responses
GET /administrator/wa?DEBUG-SHOW-VERSION HTTP/1.1 with response code(s) 404 2 responses
GET /trace.axd HTTP/1.1 with response code(s) 404 1 responses

Như bạn thấy, các URI có rất nhiều là các URI dành cho các server Windows, còn các cái khác thì chung chung, ko rõ cho cái nào.

Tất nhiên nhìn qua các request này biết ngay có kẻ nào đó (hoặc 1 con bot nào đó), nó đang query cái server của mình, tìm sơ hở.. để chiến tiếp. Các admin ít kinh nghiệm hoặc bất cẩn hay để lại các file linh tinh hoặc ko bảo vệ kỹ, có thể ăn đòn, nhưng đó là bàn ngoài lề.

Cái quan trọng, tớ nhận xét các URI này, và các lần đã bị probe khác, tỉ lệ probe đối với 1 server Win nhiều hơn so với 1 server Linux (trừ đi những cái có thể cho cả 2).
Như thế tớ suy đoán được là có thể Win dính nhiều đòn hơn so với Linux, hoặc admin của Win thường bất cẩn nhiều hơn so với admin của Linux (vì các probe này phần nhiều suy ra từ các thực tế bất cẩn đã xảy ra, với nguyên lý Murphy: 1 ng bất cẩn như thế, thì sẽ có 1 ng khác làm sai giống họ).
Không phải tôi không gặp các probe cho Linux, điển hình là probe dạng:
Code:

/administrator/index.php?action=view&filename=../../../../../../../../../../../../../etc/passwd HTTP Response 200

Nhưng nó ít hơn đáng kể.

Không phải bênh Linux hơn Win, ko muốn có khẩu chiến so sánh, nhưng chỉ là 1 suy đoán về 1 thống kê. Không hiểu có đồng chí admin nào chịu khó đọc logwatch hoặc 1 công cụ tương tự, hoặc raw log của ISS/apache có nhận định tương tự hay không?

Sử dụng ifconfig để tính bandwidth không sai, nhưng sẽ tính thừa 1 ít.
Thông thường thì các nhà hosting chỉ tính tiền dung lượng của 1 server khi nó đi/đến cửa ngõ mạng LAN chứa cái server đó, tức là có ra/vào qua cái gateway.
Còn các traffic trong nội bộ LAN đó thì không tính tiền.
ifconfig nó cho biết mọi dữ liệu đi qua card mạng của server, gồm cả traffic của LAN. 1 server bên cạnh nó broadcast 100 packet cũng được ghi nhận là RX của mình, và mình broadcast ra cũng được tính là TX. Cái này hoàn toàn nằm trong LAN.
Một khả năng nữa mà RX/TX của bạn cao, dù là trang web php thôi, là bạn có kết nối database chẳng hạn, là server riêng (trường hợp của bạn chắc là không vì thuê vps chắc ít tiền). Traffic giữa web server và database server là trong nội bộ LAN, nó cũng nhiều khủng khiếp lắm đấy.
Một khả năng nữa, rất có thể là do broadcast packet (100 server gửi 3 giây 1 packet, ngày đêm liên tục cũng khá nhiều đấy), làm cho TX/RX nhiều.
Nếu có các traffic non-http khác (mà bạn không thống kê được), ví dụ email POP3/SMTP, hoặc là ssh, hoặc ftp gì đó. Tiền hosting cũng được tính cho những cái này, nhưng các phần mềm control panel ít khi đếm được. 1 site có host email thì 5GB/ngày là khá bình thường (khoảng 1000 user chắc là thừa vượt, mỗi ng xài có 5MB). Hoặc là server của bạn khá tích cực trong việc gửi mail đi, kiểu như spam ấy. Trong trường hợp này thì chịu khó móc túi ra mà trả.

4. Các thư mục tế nhị nén lại thành file Zip, có đặt mật khẩu. Rồi xoá thư mục đi.

StarGhost wrote:

myquartz wrote:

Bạn này hỏi ko rõ khiến mọi người nhầm. Không phải là hỏi về VPN, mà là AD.

Ơ, sao bạn biết hay vậy?

Với việc VPN kết nối site-2-site, cũng chả có chuyện không thể đặt được IP range trùng nhau (tức là hệ thống không ngăn việc setup/định nghĩa bằng tool nào đó), bạn có thể đặt trùng nhau, vô tư ko có báo lỗi, nhưng nếu trùng thì đơn giản site-2-site sẽ ko hoạt động.

Thêm nữa với VPN (tất cả các loại), tớ chưa gặp 1 ai lại định nghĩa là 1 site là forest, 1 site là tree, và cái khái niệm IP range đó. Mấy cái khái niệm này là nằm trong hệ thống AD, do đó khả năng nhiều nhất là hỏi về AD.

Bạn này hỏi ko rõ khiến mọi người nhầm. Không phải là hỏi về VPN, mà là AD.

Đó là hỏi về 2 site trong Microsoft Windows Active Directory (đã được nối VPN), một bên là 1 forest, bên kia chỉ là 1 tree.
Trong AD, nó cho phép khai báo các range IP (nhiều subnet) trong 1 cái gọi là site. Cái này nó không cho định nghĩa overlap IP của 2 site, không phải là để routing, mà là để phân hoạch host.
Việc khai báo đó giúp ích cho hệ thống Win khi AD nó đồng bộ/sao chép thông tin AD quanh các Domain Controller. AD xác định các PC, các DC thuộc các site khác nhau nhờ IP của host đó (do mình định nghĩa range trước). Các DC trong cùng 1 site sẽ sao chép thông tin của nhau, và chỉ 1 DC ở 1 site sao chép với 1 DC ở site kia 1 lần, tránh trùng lắp dữ liệu qua WAN. Việc truy vấn từ client lên DC cũng thế, nó sẽ giúp cho client tránh tạo ra các truy vấn "liên site".
Trong công cụ gọi là AD sites and domains, sau khi phân site (dựa trên IP), nó sẽ tạo ra lược đồ sao chép thông tin AD cho các DC với nhau tối ưu (gọi là link), bạn có thể điều chỉnh tần suất sao chép liên site (mau hay thưa để tiết kiệm băng thông), phương thức sao chép (qua kết nối TCP trực tiếp hay qua SMTP như là mail).

Không thể định nghĩa trùng IP range vì như thế, AD sẽ phải chấp nhận 1 host thuộc cả 2 site, không thể chọn đúng DC hay tạo lược đồ đúng được (nhưng nó chấp nhận 1 PC ko thuộc site nào cả, được coi như là default site).

Lý do là Ubuntu nó bị nhầm route khi có 2 kết nối wifi - LAN đồng thời. Khác với Win, Nó ưu tiên route mọi thứ đi theo kênh kết nối thành lập sau (ở đây có lẽ là LAN cắm trước, wifi kết nối sau khi đăng nhập, do NetworkManager hay gì đó kết tự động do được lưu lại). Route đi lối wifi vì lý do nào đó không vào được Internet, bị unreachable, nên ko vào được bằng Ubuntu. Win thì nó luôn ưu tiên kết nối có dây, dù có hay không có wifi, do đó vào được.

Giải quyết: nếu không cần thiết kết nối wifi (ko nên dùng 2 kết nối cùng 1 mục đích Internet), hãy tắt wifi của máy: phím tắt, công tắc hoặc nháy phải vào biểu tượng Network Manager trong thanh bar của Ubuntu và bỏ chọn cái wireless.
Nếu dùng wireless thì đơn giản là rút dây mạng LAN ra.

Ở nhà không có wifi mà kết nối dây Win không vào được thì chưa đủ thông tin để kết luận, có khả năng thiết lập sai tham số mạng.

mrro wrote:

Bạn myquartz ơi, ở đây người ta đang nói đến việc làm sao có một cơ chế xác thực tốt mà chỉ dựa vào mật khẩu của người dùng thôi. Đây là một hướng nghiên cứu với nhiều công trình của cryptography, chứ không phải là vấn đề đã được giải quyết rốt ráo rồi đâu bạn ơi.

Tự dưng bạn lôi PKI ra, thế bạn thử nói xem một công ty bình thường, muốn xác thực khách hàng qua Internet, thì triển khai PKI thế nào? Mình chẳng biết công ty nào mà lại đi làm cái việc đó cả.

Hình như cái này mình đã có nói một lần ở trên đây, bữa nay nói lại, gọi là mrro's law nha: hễ mà nói về bảo mật hay xác thực, thì không sớm thì muộn sẽ có người kêu phải triển khai PKI thôi.

OK, hiểu ý rồi, khỏi tranh cãi. Lý do: đó là 1 hướng nghiên cứu mới về xác thực bằng mật khẩu (một cách đơn giản mà lại bảo đảm an toàn). Dự định áp dụng: cho dịch vụ web NON-SSL.
Nếu thế nên thảo luận thêm 1 số cái scheme nữa, ví dụ CHAP, MS-CHAP, MD5-Challenge, EAP, NTLM...

Theo quan điểm của tớ, giới nghiên cứu không tiếp tục đổ công sức thêm vào authentication scheme vì hiện đã có quá nhiều rồi. Nếu không sử dụng các công nghệ mã hoá và bảo đảm tính toàn vẹn, thì nghĩ ra 1 auth scheme thoả mãn 1-7 gần như là rất khó đạt được, hoặc scheme đó phải làm lại các thứ mà công nghệ SSL chẳng hạn đã có sẵn. Ví dụ việc sử dụng hàm E()/D() rất nhiều, chính nó là mã hoá đấy :-D. Ai tiếp tục theo thì ... xin mời tiếp. Tớ tưởng giúp ích được cho các bạn web master shared host ko có SSL, chứ thế này thì xin ngưng sau cái bài này thôi.

@mrro: À mà PKI ở đây ko chỉ dùng là xác thực 2-way, rất tốn kém và phức tạp. Nó có thể là phương pháp xác thực 1-way là SSL (đã có 1 loạt chức năng an ninh rồi) với server-certificate only, ko cần client-cert. Với way còn lại là bằng cách chọn 1 trong các công nghệ công nghệ xác thực password hiện có ví dụ digest hay đơn giản là basic/form, người ta đã có 1 giải pháp khá hoàn chỉnh để chống được từ 1-7 rồi (tất nhiên còn 1 số nguy cơ khác nhưng nó là ở tại host).
Cách kết hợp này không phải là mới, ví dụ Wifi (rất kém bảo mật, y như tình huống thảo luận trên đây) với EAP-TLS, client xác thực bằng user/pass, server xác thực bằng server-certificate, mã hóa và bảo đảm toàn vẹn bằng TLS, là giải pháp kết hợp 2 thứ, nhưng nhìn từ client vẫn là ... password.

StarGhost wrote:

@myquartz: Hình như bạn còn chưa đọc kĩ và hiểu rõ về mục đích của topic, tức là thảo luận về authentication schemes, chứ không phải là về implementation. RFC 2617 chính là nói về protocol 1 và 2 ngay trong post đầu tiên, cùng với những vấn đề của chúng. Còn nếu nói về implementation, mình thật nghĩ không ra cái javascript của bạn chống được MitM attack kiểu gì.

Nếu chỉ thảo luận lý thuyết, không dùng (hoặc không thể) triển khai thì bên dưới mình đã nói là nó sẽ phí thời gian. Sẽ giống như phát minh lại cái bánh xe, vì người ta đã có cái scheme đủ tốt để thực hiện rồi, chính nó là PKI.

RFC 2617 không phải là protocol 2, nó mạnh hơn nhiều, vì không phải chỉ là salt, nó còn thêm nonce, nonceCount, clientNonce... Nó có khả năng chống MitM nếu sử dụng full option, nghĩa là HA2 gồm cả digest của method, URI và nội dung cần gửi đi. Kiểu Digest này chỉ yếu khi nó bị trình duyệt/MitM fail-back về RFC2096 (giống protocol 2).
Tất nhiên RFC 2617 client không xác thực server, không phải là 2-way (mutual) authentication, đó không phải là mục tiêu của nó.
Mình chỉ thấy rằng nó có thể triển khai thực tế để bảo vệ các web site NON-SSL thôi.

Trong điều kiện thông thường và dễ triển khai, đáp ứng được các yếu tố 1, 2, 3, và 1 ít 7, thì nên chơi Digest Authentication theo RFC 2617.
Nếu chơi đơn giản, ko code gì hết, thì config HTTP Server hỗ trợ cái này.

Còn nếu tự implementation để tránh browser bị man-in-the-middle lừa thì làm javascript (ko cần đến ajax làm gì cho nó mệt, chỉ là vài step xác thực mà thôi).

Cái này xài hàm hash là MD5, dễ viết java script hơn các hàm mã hoá AES/DES hoặc RSA. Nếu tự handle thay cho HTTP thì xài SHA1 cho nó máu. (Nếu sợ rằng phải lưu HA1 hoặc plain-text password tại client sau khi xác thực, hãy sử dụng 1 session key làm 1 password tạm (hay HA1 tạm cho Digest Auth phiên làm việc) cho các bước tiếp theo cho đến hết phiên làm việc. Session key nên tạo và trao đổi qua 1 giải thuật IKE nào đó, ví dụ Diffie-Hellman cho nó đơn giản (http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange ). JS có khả năng hỗ trợ tất cả những cái này ở một mức độ nhất định (session key kiểu integer nếu là số to quá 53bit thì các hàm Math không tính chính xác hơn nữa, vì nó sẽ thành số float, có thể viết lại hàm nhân chia số integer thực lớn nhưng ... hơi mệt thôi). Theo ví dụ thì Alice sẽ làm server vì server có thể có gọi nhiều hàm tính ra số nguyên tố lớn tốt hơn client.

Cân bằng giữa giá trị và lợi ích mang lại sẽ là giải pháp được thực tế chấp nhận. Nếu cần bảo mật hơn nữa, đừng tìm kiếm giải pháp xác thực nào khác với password mà cần nâng lên PKI, công nghệ sẵn có, giá thành sẽ rẻ hơn nhiều đưa ra 1 loạt các scheme mới, chưa chắc đã chứng minh được tốt hơn, mà giá thành lại cao. Tất nhiên tranh cãi lý thuyết thì vẽ con voi nó có mấy vòi cũng được, nhưng ... tốn thời gian.
Forum hoặc các ứng dụng web chạy không SSL, nếu cần bảo mật thì có thể triển khai cái này, tuy hơn bị vất 1 tí về việc làm script, nhưng đa số các kiddies sẽ khó ăn cắp được mật khẩu hay xâm nhập cướp session dù có capture được dữ liệu.