Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 04:07:09 (+0700) \| #1 \| 239401

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Chào các anh chị em. Tôi lập ra chủ đề này là tạo ra một điểm tập trung chia sẻ những kinh nghiệm tổng quát về việc kiện toàn bảo mật trong tình trạng đang bị hackers TQ tấn công. Chủ đề này chỉ bàn thuần tuý các chi tiết kỹ thuật, không tiếp nhận bất cứ thảo luận chit chat nào. Bất cứ vi phạm nào sẽ dẫn đến kết quả tên đăng ký bị khoá.

Sau đây là sườn chính của các dạng tấn công hiện đang xảy ra:

1. Bị các lỗi bảo mật thông thường do không cập nhật bản vá.
2. Bị SQL injection do lập trình không chú trọng bảo mật.
3. Bị Cross site scripting từ những tiện ích javascript và do không kiểm soát nhập / xuất.
4. Bị đánh cắp tên miền.
5. Bị tấn công từ chối dịch vụ.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 05:03:50 (+0700) \| #2 \| 239403

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

1. Bị các lỗi bảo mật thông thường do không cập nhật bản vá.

Rà xuyên qua một số trang web đã bị TQ tấn công, tôi nhận thấy đa số là những trang web chạy trên hệ thống quá cũ và không được cập nhật những bản vá cần thiết. Những hệ thống như thế này cực kỳ dễ bị tấn công bởi vì các phương pháp tấn công, thậm chí những công cụ tấn công đã được công bố rộng rãi trên mạng. Tin tặc chỉ cần dùng công cụ như nmap để rà và nắm bắt được footprint (phiên bản của hệ điều hành và dịch vụ) và họ sẽ dễ dàng thực hiện biện pháp tấn công đã có sẵn. Đây chính là lý do hàng loạt các trang web của VN bị ngã gục một cách nhanh chóng và dễ dàng.

Biện pháp kiện toàn:

1. Cập nhật ngay các bản vá trên hệ điều hành.

- Nếu máy chủ được thuê từ nhà cung cấp, yêu cầu họ giúp đỡ việc cập nhật hệ điều hành trên máy chủ. Nếu họ không làm việc này (hầu hết các máy chủ thuê từ nhà cung cấp dịch vụ đều có cùng một bản chung và họ thường không hỗ trợ việc cập nhật hệ điều hành theo định kỳ), thuê ngay máy chủ mới có hệ điều hành phiên bản mới và tiến hành di chuyển trang web + csdl sang các máy chủ mới.

- Nếu máy chủ do tự mình quản lý và thuộc hệ thống mạng riêng của cơ quan, nên tiến hành cập nhật trọn bộ những bản vá cần thiết cho hệ điều hành và tất cả các dịch vụ đang hoạt động (web, mail,....). Quản lý hệ thống nhưng bê trễ chuyện cập nhật bản vá là chuyện không thể chấp nhận được.

2. Áp dụng ngay một hệ thống cản lọc.

- Nếu là một doanh nghiệp có kinh phí, nên sử dụng ngay một hệ thống "application firewall" (dạng appliance hoặc software) tuỳ nhu cầu. Nên liên lạc với nhóm tư vấn bảo mật có uy tín để họ giúp ý kiến. Web applications không nên để trần ra ngoài Internet mà không có một cơ chế bảo vệ nào.

- Nếu là một máy chủ thuê ở dịch vụ, nên hỏi xem họ có chọn lựa hoặc dịch vụ cản lọc nào không. Nếu không có, hãy tự xây dựng một hàng rào cản lọc như mod_security (chạy trên apache như một reverse proxy nhằm bảo vệ dịch vụ web bên trong.

Không có hệ thống cản lọc và không cập nhật các bản vá cần thiết thì việc bị tấn công và bị kiểm soát là chuyện không thể tránh khỏi được.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 07:48:02 (+0700) \| #3 \| 239408

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

Em có ý kiến về vấn đề thứ 5.

Ở Việt Nam phần lớn mọi người mua từ các nhà cung cấp như VDC, Hostvn.net, MatBao, PA Việt Nam. Theo hiểu biết ít ỏi của em thị nôm na gọi là share host (dùng chung một web server cho nhiều domain trỏ tới, các trang web được đặt trên những thư mục phân quyền khác nhau).

Ở Việt Nam việc chống tấn công từ chối dịch vụ rất khó, người sử dụng dịch vụ không có quá nhiều quyền can thiệp vào hệ thống. Trong khi việc chống DOS cần phải có những config phù hợp ở nhiều mức khác nhau. Mặt khác bộ phận support của các côn ty thường thờ ơ với khách hàng, hoặc không làm việc đúng với trách nhiệm của mình. Em có làm vài website nhưng khi bị DOS thì mấy công ty kia họ chỉ khoá tài khoản thôi. Nên đành phải sử dụng biện pháp tạm thời là dùng code PHP để lọc request nhưng do server không được cofig để chống lại DOS nên chất lượng dịch vụ rất thấp.

Mặt khác nếu nhà cung cấp mà sử dụng chung SQL server như ông hostvn.net thì đến khổ cứ lần nào bị DOS là chết luôn cả dãy, không làm gì đc. Theo em nghĩ việc chống DOS ở Việt Nam đối với các site trung bình và nhỏ là không đồng bộ và chịu phụ thộc nhiều và những nhà cung cấp dịch vụ rất thờ ơ với khách hàng. Đây có lẽ là vấn đề nhức đầu.

while(1){}

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 08:49:12 (+0700) \| #4 \| 239424

tmd
Member

Joined: 28/06/2006 03:39:48
Messages: 2951
Offline

chiro8x wrote:

Em có ý kiến về vấn đề thứ 5.

Ở Việt Nam phần lớn mọi người mua từ các nhà cung cấp như VDC, Hostvn.net, MatBao, PA Việt Nam. Theo hiểu biết ít ỏi của em thị nôm na gọi là share host (dùng chung một web server cho nhiều domain trỏ tới, các trang web được đặt trên những thư mục phân quyền khác nhau).

Ở Việt Nam việc chống tấn công từ chối dịch vụ rất khó, người sử dụng dịch vụ không có quá nhiều quyền can thiệp vào hệ thống. Trong khi việc chống DOS cần phải có những config phù hợp ở nhiều mức khác nhau. Mặt khác bộ phận support của các côn ty thường thờ ơ với khách hàng, hoặc không làm việc đúng với trách nhiệm của mình. Em có làm vài website nhưng khi bị DOS thì mấy công ty kia họ chỉ khoá tài khoản thôi. Nên đành phải sử dụng biện pháp tạm thời là dùng code PHP để lọc request nhưng do server không được cofig để chống lại DOS nên chất lượng dịch vụ rất thấp.

Mặt khác nếu nhà cung cấp mà sử dụng chung SQL server như ông hostvn.net thì đến khổ cứ lần nào bị DOS là chết luôn cả dãy, không làm gì đc. Theo em nghĩ việc chống DOS ở Việt Nam đối với các site trung bình và nhỏ là không đồng bộ và chịu phụ thộc nhiều và những nhà cung cấp dịch vụ rất thờ ơ với khách hàng. Đây có lẽ là vấn đề nhức đầu.

Mình đã thuê bao như vậy rồi , cùng chung tình trạng này thì tự chịu lấy kết quả(mình đã biết hay không biết và không được thông báo trước....
"Server không được cofig để chống lại DOS" -> thuê phải dịch vụ tào lao. Nên nhớ là có hai cấp dịch vụ, chính thức và reseller. Tóm lại, chuyện .5 là do mình tự quyết định.

Thuê ở chính hảng thì lại có hai dạng khác, thuê chô đặt rồi vác server tới rồi tự cấu hình. Hoặc thuê trọn gói , dịch vụ làm cho hết và có cam kết đảm bảo chất lượng dịch vụ( vụ này mình cũng còn sợ). Dùng open source hay dùng hàng trả phí(mình phải đặt vào tình thế sài hàng bản quyền).
Thuê ở reseller thì phải xem mình thuê cái gì và tự nhận thức. Thuê đại thì đừng than thở về chuyện chống DDOS.

3 giai đoạn của con... người, ban đầu dek biết gì thì phải thăm dò, sau đó biết rồi thì phải thân thiết, sau cùng khi quá thân thiết rồi thì phải tình thương mến thương. Nhưng mà không thương được thì ...

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 09:06:02 (+0700) \| #5 \| 239427

hvthang
Member

Joined: 20/07/2005 03:26:58
Messages: 187
Offline

@chiro8x: Thường các site của các đơn vị nhỏ lẻ mới thuê host dùng chung. Còn các site lớn hơn thì thuê VPS hoặc cao hơn là dedicated server.
Khi bị tấn công thì thiệt hại cũng sẽ tăng theo quy mô công ty/doanh nghiệp. Do đó, các site lớn họ phải có cơ chế đánh giá thiệt hại khi bị tấn công và có cơ chế chuyển đổi sang giải pháp hosting phù hợp (anh conmale đã nói ở post #2).

Theo ý kiến cá nhân mình thì đợt tấn công của TQ vào các server của VN lần này là để dằn mặt nhau và nó sẽ phát huy tác dụng càng cao khi các site bị tấn công càng uy tín (nhóm gov.vn chẳng hạn).

Đối với các site nhỏ (theo mình nghĩ nó sẽ chủ yếu bị các nhóm hacker "nhỏ" tấn công) do đó việc cần làm là đổi password quản lý, dùng một công cụ scan để kiểm tra toàn diện (Acunetix Web Vulnerability Scanner chẳng hạn).
Sau khi scan xong thì thực hiện xử lý các lỗi đã phát hiện ra.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 09:39:29 (+0700) \| #6 \| 239432

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

2. Bị SQL injection do lập trình không chú trọng bảo mật.

Đây là lỗi thường thấy nhiều đến nỗi hầu như các trang web ở VN đều bị dính. Các lập trình viên nếu tự code cũng không mấy quan tâm đến cơ chế kiểm soát truy vấn hoặc tệ hơn, code được lấy từ nhiều nơi khác nhau rồi xào nấu miễn sao chạy được là tung lên và đưa vào hoạt động. Chẳng những vậy, hầu hết các trang web lớn nhỏ ở VN bị thiếu hẳn bộ cản lọc đứng trước dịch vụ web để bảo vệ cho nên những dạng SQL injection xuyên qua các permutation sử dụng nhiều dạng encoding (urlencoding, unicodeencoding, hexencoding....) đều có thể qua mặt dễ dàng. Điều tệ hại nhất là hàng loạt các website có dịch vụ mysql hoặc mssql chường ra Internet mà không có gì bảo vệ cả. Từ chỗ thực hiện sql injection, tin tặc có thể dễ dàng khống chế cả CSDL và việc deface hoặc xoá trọn bộ thông tin trên CSDL là việc không mấy khó khăn.

Biện pháp kiện toàn:

1. Đề nghị nhà cung cấp dịch vụ bịt kín cổng dịch vụ đến CSDL. Họ phải có trách nhiệm với việc này vì khách hàng bình thường hoàn toàn không có quyền can thiệp. Nếu dịch vụ CSDL thuộc hệ thống do mình tự quản lý, tìm cách đưa CSDL vào bên trong và bảo vệ nó bằng firewall hoặc những biện pháp cản lọc cần thiết khác (ví dụ chỉ cho phép một số IP bên trong được truy vấn trực tiếp đến CSDL..).

2. Rà soát kỹ lưỡng code của ứng dụng web và kiện toàn trên tầng coding. Đây là việc làm khó khăn và tốn thời gian nhưng không làm thì không có cách gì bảo mật hết. Ít nhất cũng nên áp dụng một tầng "application firewall" như mod_security và ấn định bộ luật chống SQL injection. Bộ luật ấy có thể cản lọc ít nhất 90% những dạng tấn công SQL injection thông thường và làm cản trở không ít những permutation cao cấp hơn. Nếu không nắm vững SQL injection là gì thì nên tìm một số thông tin về SQL injection để nghiên cứu và làm quen. Một lập trình viên giỏi là một lập trình viên không những code gọn gàng mà còn có thể tạo ứng dụng hiệu suất và bảo mật.

3. Đối với các doanh nghiêp và các công sở, nên có các kế hoạch rà soát theo định kỳ, cập nhật bản vá và trước khi đưa ra bản cập nhật mới của ứng dụng web, cần phải thử nghiệm thật kỹ lưỡng (nên tạo ra một bản test plan cẩn thận và chi tiết để thực hiện).

Nên nhớ, bảo mật luôn luôn mất thời gian và tốn kém nhưng nếu không kiện toàn bảo mật thì độ thiệt hại còn tốn kém hơn rất nhiều. Nếu hình thành trang web nhưng không có nhu cầu cấp thiết hoặc không có kinh phí để bảo vệ và kiện toàn nó thì không nên tạo ra trang web vì đó là sự lãng phí vô ích.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 09:57:18 (+0700) \| #7 \| 239434

xnohat
Moderator

Joined: 30/01/2005 13:59:19
Messages: 1210
Location: /dev/null
Offline

Do anh conmale có đề cập tới việc sử dụng mod_security như một application firewall, tôi cập nhật một link tham khảo đến loạt bài "Bảo mật web server Apache với mod Security" của bạn tanviet12 để anh chị em tiện tham khảo ngay, bài viết rất chi tiết, nhất là phần 2 và 3 đề cập tới rất nhiều cách cản lọc hiệu quả bằng mod_security

/hvaonline/readingRoom/item/237029.html

Cập nhật thêm link tới bài viết "Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn" của lão seamoun , bài viết đề cập về các công cụ rất hiệu quả, hỗ trợ nhanh chóng cho việc rà soát mã nguồn, công việc cấp thiết cần làm ngay hiện nay để tránh bị deface

https://www.hvaonline.net/hvaonline/posts/list/36839.html

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: http://www.facebook.com/hvaonline

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 10:08:57 (+0700) \| #8 \| 239436

Ikut3
Elite Member

Joined: 24/09/2007 23:47:03
Messages: 1429
Location: Nhà hát lớn
Offline

Đối với các hệ thống sử dụng M$

- Đừng quên đổi các password và cấu hình mặc định của hệ thống. Nhất là đối với các máy chủ cho phép từ ngoài Terminal vào. Nên thay đổi user Administrator thành 1 username khác kèm với 1 password đủ khó để không có Khựa nào brute force ra được, ngoài ra nếu cẩn thận có thể đổi luôn cả port remote desktop

- Các dịch vụ IIS / Apache nên được hardering đúng mức và phù hợp với các event viewer hoặc log file trả về. Chẳng hạn tại thời điểm các dịch vụ đang có sự tương tác từ bên ngoài lớn thì việc giới hạn các thông số connection / session time out là chưa cần thiết. Nhưng đối với những khoảng thời gian tài nguyên bị hao tổn bởi các request lạ, hoặc các request không hợp lệ thì nên có những điều chỉnh có giá trị "immediate".

- Cảnh báo với toàn bộ user đang làm việc và có quyền truy cập vào hệ thống về tính an toàn bao gồm từ phía client (Virus - Trojan - Spyware .v.v..) đến tầm cao hơn là kiểm soát mã nguồn, rà soát các file lạ trên Server. Theo dõi được việc phát sinh hay thay đổi các file thuộc quyền sở hữu của Host.

- Rà soát các dịch vụ Process đang hoạt động trên hệ thống. Đảm bảo không có bất kì 1 services (no name/un defined) đang khởi chạy và hoạt động song song với các dịch vụ có tính xác thực khác.

Vài dòng thiếu xót

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 11:47:37 (+0700) \| #9 \| 239444

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

3. Bị Cross site scripting từ những tiện ích javascript và do không kiểm soát nhập / xuất.

Cross site scripting (XSS) là dạng thâm nhập phổ biến nhất trên web. Bất cứ các biến cố (event) nào đươc javascript tạo ra (ví dụ như onClick, onMouseOut, onLoad....) đều có thể dùng để phát động một hàm của javascript nhằm đánh cắp xuất truy cập hoặc thậm chí trọn bộ HTTP header. Từ những thông tin này, tin tặc có thể truy cập vào mục tiêu với chủ quyền của người bị đánh cắp xuất truy cập và từ đó có thể mở rộng biên độ tấn công.

Rất nhiều người xem nhẹ dạng tấn công này do không hiểu rõ tính chất của nó hoặc do cố tình làm ngơ. Tương tự như SQL Injection, dạng tấn công XSS này nằm trên tầng web và các permutation đều xoay quanh phương thức encoding URL cho các đường dẫn (href link). Quản lý trang web nên xét kỹ và kiện toàn những điểm sau:

1. Trên dịch vụ web, cookie cho session nên dược set ở dạng httpOnly. Hầu hết các ngôn ngữ lập trình web đều có hàm riêng biệt để set response hoặc set Cookie và bằng phương tiện này, httpOnly được ấn định. Ngày nay, đa số các trình duyệt đều hỗ trợ "httpOnly" và đây là biện pháp hữu hiệu để ngăn cản tình trạng đánh cắp cookie và session. Lập trình viên cũng cần chú ý chuyển đổi trọn bộ HTML thành "html entities" thay vì để nguyên các HTML tag như <>. Đặc biệt chú ý những khu vực "href" nhằm phòng chống tình trạng XSS. Nếu không nắm vững nguyên tắc, nên tìm vài tài liệu đặc thù về vấn đề này để tham khảo. OWASP www.owasp.org) là trang web có đầy đủ các thông tin về khía cạnh này.

Nếu người dùng có cơ hội nhập dữ liệu (ví dụ như diễn đàn cho phép thành viên gởi bài hoặc blog cho phép comment) thì ngay nơi nhập dữ liệu (đường vào) phải được kiểm soát chặt chẽ để chuyển hoá trọn bộ thông tin thành "html entities" trước khi nhập vào CSDL.

2. Trên trình duyệt, người dùng nên cài những tiện ích như "NoScript" nhằm cản lọc và giới hạn các javascript được thực thi ngầm. Người dùng cũng có thể sử dụng 2 trình duyệt song song với nhau. Một trình duyệt dùng để đăng nhập hẳn hòi, một trình duyệt hoàn toàn không đăng nhập. Tất cả các đường dẫn nên copy và dán vào trình duyệt không đăng nhập để xem. Bằng cách này sẽ giảm thiểu tình trạng bị XSS.

Người dùng cũng nên tập thói quen xác định đường dẫn có chứa gì khả nghi hay không. Nếu đường dẫn trỏ đến một trang web khác (không phải trang web mình tin cậy và thường duyệt), nên cẩn thận xem xét trước khi bấm. Có những đường dẫn được encoded theo dạng base64 hoặc vài combination nào đó nhằm che giấu nội dung mờ ám, nên tránh xa những đường dẫn ấy bởi vì các trang web hợp lệ và thông thường không sử dụng những thủ thuât ấy. Đặc biệt đối với những người làm công tác quản lý, tuyệt đối không nên đăng nhập vào một account quan trọng và tiếp tục duyệt web. Chỉ nên đăng nhập vào account quan trọng, hoàn tất công việc và thoát ra.

Cách an toàn nhất có lẽ là tạo một máy ảo (vmware player hoặc virtualbox) và cài một hệ điều hành hoàn toàn sạch có cài antivirus và các ứng dụng chống malware. Trên máy ảo này chỉ dùng để đăng nhập vào những account quản lý quan trọng. Thực hiện xong là thoát ra ngay. Tuyệt đối không dùng máy ảo ấy để duyệt web đại trà.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 12:08:55 (+0700) \| #10 \| 239445

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

4. Bị đánh cắp tên miền.

Đánh cắp tên miền cũng là phương pháp tấn công, đặc biệt cho mục đích defacing. Tính bảo mật của tên miền phụ thuộc vào nhiều yếu tố như sự bảo mật của registrar, sự bảo mật của hòm thư đăng ký tên miền.... Nếu hòm thư đăng ký tên miền bị mất cắp thì cơ hội tên miền ấy dễ dàng bị mất cắp rất cao. Tên miền bị mất cắp phần lớn do thủ thuật phishing, xss... chủ yếu là tổ hợp tấn công vào người dùng nhẹ dạ hoặc gần đây, phương thức cài trojans và keyloggers để đánh cắp password cũng là phương thức bắt đầu phổ biến. Nếu tên miền bị mất thì cơ hội bị deface sẽ lâu dài (ít ra cho đến khi nào tên miền được phục hồi).

Để kiện toàn bảo mật tên miền, nên chú trọng các điểm sau:

1. Chọn một registrar có uy tín (về vấn đề bảo mật và xử lý hành chính). Một registrar càng lớn, có công cụ quản lý trên web càng phức tạp thì cơ hội bị lỗ hổng bảo mật càng nhiều. Nếu tên miền có giá trị quan trọng đến doanh nghiệp, nên sử dụng chọn lựa quản lý trực tiếp mặt đối mặt (in person) thay vì xuyên qua web. Tất cả mọi thay đổi trên tên miền chỉ nên được thực thi khi có giấy tờ chứng minh chủ quyền (bằng lái, biên nhận mua tên miền....v...v...). Tên miền nên luôn luôn áp dụng tình trạng "Registrar Lock". Không nên để ở trạng thái "OK".

2. Tuyệt đối không bao giờ dùng hòm thư miễn phí (như yahoo, gmail...) để đăng ký tên miền. Nếu không có chọn lựa nào khác, nên dùng gmail và sử dụng tính năng 2 factors verification của gmail để bảo vệ hòm thư của mình. In ra các giao dịch đăng ký tên miền hoặc tải về và lưu trong một USB nào đó để cất kỹ rồi xoá hết trọn bộ các thông tin liên quan đến việc đăng ký tên miền trong hòm thư gmail.

3. Cũng như phần XSS, nên sử dụng một máy ảo để thao tác việc đăng nhập vào hòm thư quan trọng dùng để đăng ký tên miền cũng như control panel của tên miền. Thao tác xong là thoát ngay và tuyệt đối tránh duyệt web đại trà trên máy ảo ấy.

4. Theo dõi thường xuyên tình trạng của tên miền xuyên qua tiện ích whois. Việc này có thể làm bằng tay hàng ngày hoặc tự động bằng cách viết một script tự động để thực thi "whois" trên command line. Nếu tình trạng tên miền bị thay đổi (ví dụ như từ "Registrar Lock" chuyển sang "OK", hoặc email dùng để đăng ký tên miền bị thay đổi) thì cảnh báo ngay xuyên qua email hoặc SMS, tuỳ cách ứng dụng. Thông thường, việc chuyển tên miền từ một registrar này sang một registrar khác cần thời gian và cần sự xác nhận. Bởi vậy, ngay khi tình trạng của tên miền bị thay đổi, phải liên hệ ngay với registrar bằng mọi cách (kể cả gọi điện trực tiếp) để ngăn chặn tình trạng tên miền bị chuyển đi nơi khác.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 13:36:58 (+0700) \| #11 \| 239451

zjm_zjm
Member

Joined: 26/07/2009 01:53:09
Messages: 159
Location: hhhhhh
Offline

Cho em hỏi về vấn đề 0day, em nghĩ nếu gặp tình huốn như thế này thì mình đỡ không được tại tại thời điểm bị tấn công rồi, chỉ còn 1 cách là dùng các event để cảnh báo về cho sysadmin. ví dụ như cảnh báo qua điện thoại...

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 15:50:14 (+0700) \| #12 \| 239468

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

5. Bị tấn công từ chối dịch vụ.

Đây là dạng tấn công trở nên cực kỳ phổ biến trong những năm gần đây. Các mục tiêu bị tấn công từ chối dịch vụ thường là những mục tiêu không thể thâm nhập, deface, xoá dữ liệu.. một cách nhanh chóng và dễ dàng. Bởi vậy, nếu không bị những dạng tấn công như đã nêu ở trên thì cơ hội bị tấn công từ chối dịch rất cao. Với tình trạng "botnet for sale" lan tràn, hiểm hoạ DDoS chắc chắn sẽ không dừng lại mà sẽ tiếp tục lan rộng với cường độ càng lúc càng lớn. Đứng trước vấn nạn DDoS, đây là những việc nên làm để giảm thiểu dung hại (bởi vì không có cách nào khắc chế DDoS 100% được).

1. Gia tăng băng thông và tài nguyên trên hệ thống là điều đầu tiên cần làm bởi vì DDoS nhắm vào hai trọng điểm: a) làm cạn kiệt tài nguyên của nạn nhân (trên 1 hoặc nhiều máy chủ) và b) làm bão hoà đường truyền. Nếu có thể, nên tạo hệ thống cân bằng tải trên nhiều network khác nhau và cách đơn giản nhất là tạo reverse proxy trên nhiều server. Mỗi proxy ấy nằm trên một network (của data center) khác nhau. Sử dụng DNS round robin để buộc các requests đi từ zombies sẽ xoay vòng đến các IP khác nhau của những reverse proxy mà mình đã thiết lập. Đây là cách gia tăng băng thông hữu hiệu nhất bởi vì nó không làm nặng nề một network nào cả. Tất nhiên, biện pháp này sẽ tốn kém hơn là chỉ cung cấp dịch vụ trong một data center.

2. Nhận diện dạng DDoS. Đây là chìa khoá quan trọng cho việc hình thành biện pháp khắc phục tình trạng trì trệ do DDoS tạo ra và tạo điều kiện cho người dùng thực sự có cơ hội sử dụng dịch vụ. Mỗi dạng DDoS có dấu hiệu và đặc tính khác nhau cho nên việc nhận diện DDoS là điều quan trọng đứng sau việc gia tăng băng thông và tài nguyên. Băng thông và tài nguyên luôn luôn có giới hạn nhất định cho nên việc nhận diện dạng DDoS giúp cản lọc và tách rời chúng một cách hữu hiệu. Cách tổng quát để nhận diện dạng DDoS là sử dụng packet sniffer (như tcpdump trên *nix hoặc Wireshark trên hầu hết các hệ điều hành) để nắm bắt các gói tin đi vào hệ thống. Sau đó phân tích đặc tính của chúng (kích thước gói tin, biên độ tấn công, cường độ tấn công tính theo khoảng thời gian nhất định và nếu DDoS là dạng tấn trên web thì cần nắm bắt URL nào [hoặc biến thái của chúng] được sử dụng để tấn công).

3. Sử dụng mọi phương tiện cản lọc từ tầng IP lên đến tầng application. Không có một luật nhất định nào cho việc cản lọc này hết mà phải tuỳ hoàn cảnh, tuỳ dạng DDoS mà hình thành biện pháp cản lọc trên các tầng giao thức.

- Nếu bị tấn công với lượng traffic quá lớn, bạn cần sự trợ giúp của nhà cung cấp dịch vụ để hỗ trợ cản lọc ở tầng định tuyến bìa (border router). Ở tầng này, có nhiều phương pháp cản lọc khác nhau tuỳ loại thiết bị và tuỳ ứng dụng công nghệ của từng data center. Cách thông thường nhất là cho vào "lỗ đen" những gói tin đi từ một IP đổ vào dồn dập. Thậm chí có những data center cản hoàn toàn traffic đi đến một mục tiêu (nạn nhân) nào đó thuộc network của họ đã giảm thiểu ảnh hưởng đến những hệ thống khác.

- Trên tầng IP có thể cản hẳn IP hoặc hẳn network mà bạn không muốn họ truy cập (vì hầu hết những IP ấy chỉ dùng để tấn công), trên tầng IP cũng có thể cản lọc dựa trên tầng số tấn công (bao nhiêu gói tin trong 1 đơn vị thời gian nào đó). Trên tầng IP của chính các hệ thống do mình quản lý, cản lọc có thể đi từ chỗ giới hạn số lượng SYN đi vào (trong một khoảng đơn vị thời gian nào đó) cho đến việc cản lọc hoàn toàn các IP đi quá giới hạn thông thường (vì không có người dùng nào đọc nhanh và liên tục đến độ phải request liên tục). Sự cản lọc có hệ thống và có logic trên tầng IP giúp bảo tồn tài nguyên của hệ thống ngay cả đã áp dụng phương pháp load balancing như đã nêu ở trên.

- Nếu bị tấn công cụ thể ở dịch vụ web (rất thường thấy) thì ngoài việc cản lọc trên tầng IP, việc cản lọc cụ thể trên tầng 7 (của mô hình OSI) là việc quan trọng và cần thiết để giảm thiểu tình trạng tạo load trên hệ thống máy chủ. Tấn công DDoS trên web rất đa dạng. Nó có thể trải dài từ dạng DDoS dồn dập vào index.html hoặc "/" (trang bìa của website) cho đến những dạng biến thiên ngẫu nhiên như /?a=123, /?a=345.... nhằm qua mặt hệ thống phòng thủ. Ngoài ra, để góp phần qua mặt hệ thống phòng thủ, các hệ thống botnet ngày nay còn tinh xảo đến mức có khả năng tạo "User-Agent" ngẫu nhiên và hoàn toàn hợp lệ. Dù gì đi chăng nữa, nguyên tắc "số lần truy cập trong 1 đơn vị thời gian" vẫn được áp dụng ở biên độ này. Một lần nữa, "application firewall" như mod_security có thể giúp bạn việc này. Thậm chí nó có thể "báo" với hệ thống tường lửa những IP vi phạm nguyên tắc (màu đỏ) trên và cản lọc chúng trong một khoảng thời gian nào đó.

Ngoài nguyên tắc (màu đỏ) ở trên, lắm khi cũng có những dạng DDoS có dấu hiệu rất đặc thù trong HTTP header và dấu hiệu ấy có thể được mod_security nhận diện và xử lý một cách gọn nhẹ.

Ngăn chặn và giảm thiểu DDoS là việc rất khó khăn bởi vì không có một thiết bị hoặc một giải pháp đơn giản và dễ dàng nào có thể thực hiện được. Bởi vậy, nếu bị tấn công và nhắm thấy không đủ khả năng tự bảo vệ, nên liên hệ với các nhóm tư vấn bảo mật đáng tin cậy để họ giúp đỡ.

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 16:48:24 (+0700) \| #13 \| 239473

conmale
Administrator

Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline

Giúp giảm thiểu hiểm hoạ tấn công từ chối dịch vụ.

Botnet sẽ không có tác dụng nếu như không có zombies. Chính bản thân người dùng phần lớn không hề biết máy của mình bị biến thành zombie, đặc biệt đối với những người có giới hạn kiến thức máy tính và mạng. Đây là tóm lược những dấu hiệu máy tính bị biến thành zombie:

1. Máy khởi động chậm hơn bình thường.
2. Thao tác trở nên ì ạch và có những dấu hiệu bất thường (như các chương trình bị treo bất chợt).
3. Truy cập net chậm.
4. Không duyệt web nhưng khi thực thi lệnh: netstat -na thì thấy liệt kê ra hàng loạt các network connections đến một (hoặc nhiều IP) khác nhau.
5. Không thể cập nhật chương trình chống virus hoặc không thể thực thi công tác rà quét virus.

Có những dạng DDoS không trực tiếp biến máy tính thành zombies bằng cách cài mã độc lên máy nhằm "sai khiến". Dạng x-flash trước đây (đã từng tấn công HVA trong thời gian dài) là một điển hình "mượn tay" người dùng để tấn công các nạn nhân khác mà không biến máy của họ thành zombie xuyên qua việc cài mã độc. Ở dạng này, một số trang web đông người viếng bị cài x-flash và khi người dùng viếng trang web ấy, trình duyệt của người dùng sẽ liên tục gởi "requests" đến nạn nhân (được ấn định trong x-flash hoặc nhận chỉ thị từ nơi khác xuyên qua x-flash). Trong trường hợp này, vận tốc lướt web luôn luôn chậm hơn bình thường, thậm chí rất trì trệ. Nếu quan sát kỹ thì sẽ thấy thanh "status bar" liên tục hiển thị trình duyệt đang request đến một trang nào đó chớ không phải trang mình đang viếng.

Đối với network administrators, nếu theo dõi băng thông và lưu lượng sử dụng Internet thường xuyên, network administrators sẽ nhận thấy gia tăng đột biến. Trong trường hợp này, Wireshark là công cụ thích hợp dùng để sniff traffic lên switch level để xác định những IP nào trong nội mạng có dấu hiệu hoạt động như một zombie. Những máy ấy cần tách rời và xử lý ngay.

Đối với người dùng bình thường, nên tránh:

- Viếng các trang web không trong sáng (có liên quan đến những hoạt động mang tính bất hợp pháp hoặc có biểu hiện tương tự). Những trang web đã bị defaced hoặc chứa thông tin mang tính "nóng sốt" để câu khách.

- Không cài và sử dụng các software đã được cracked vì không có gì bảo đảm không có mã độc bị nén chung.

- Không mở các tập tin đính kèm từ email nếu không xác định được người gởi có đáng tin hay không. Ngay cả người gởi là bạn bè hoặc gia đình đi chăng nữa, cũng nên cẩn thận khi tải tập tin đính kèm và mở nó ra vì đây là phương tiện phát tán mã độc phổ biến nhất.

- Không tải và sử dụng các công cụ "vạn năng" nào đó để làm những việc mờ ám (như hack game, hack máy tính....) bởi vì chẳng có công cụ nào có những khả năng như vậy.

Nói cho cùng, chính người dùng bị thiệt hại trước khi nạn nhân nào đó bị thiệt hại do DDoS bởi vì một khi đã trở thành zombie thì cơ hội bị dính trong tình trạng zombie trong một thời gian dài (cho đến khi được phát hiện và sửa chữa hoặc cài lại máy).

What bringing us together is stronger than what pulling us apart.

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 22:35:50 (+0700) \| #14 \| 239519

chiro8x
Member

Joined: 26/09/2010 00:38:37
Messages: 661
Location: /home/chiro8x
Offline

tmd wrote:

Mình đã thuê bao như vậy rồi , cùng chung tình trạng này thì tự chịu lấy kết quả(mình đã biết hay không biết và không được thông báo trước....
"Server không được cofig để chống lại DOS" -> thuê phải dịch vụ tào lao. Nên nhớ là có hai cấp dịch vụ, chính thức và reseller. Tóm lại, chuyện .5 là do mình tự quyết định.

Thuê ở chính hảng thì lại có hai dạng khác, thuê chô đặt rồi vác server tới rồi tự cấu hình. Hoặc thuê trọn gói , dịch vụ làm cho hết và có cam kết đảm bảo chất lượng dịch vụ( vụ này mình cũng còn sợ). Dùng open source hay dùng hàng trả phí(mình phải đặt vào tình thế sài hàng bản quyền).
Thuê ở reseller thì phải xem mình thuê cái gì và tự nhận thức. Thuê đại thì đừng than thở về chuyện chống DDOS.

Chủ yếu lí do về mặt kinh tế và việc xin kinh phí từ sếp quyết định chuyện này. Với lại website chưa phát triển nên việc đầu tư nhiều không khôn ngoan cho lắm. Theo mình muốn site hiệu quả về kinh tế, cần trải qua từng bước phát triển sau đó mình nâng cấp dần lên, chứ một bước lên mây sao nổi. Với lại phải giải trình với sếp là site hoạt động hiệu quả thì mới thuê VPS và Server riêng được. Haizz ! không phải lúc nảo vấn đề kỹ thuật cũng đi chung đường với kinh tế mà. Hiện tại site ở Việt Nam dùng share host nhiều.

conmale wrote:

1. Trên dịch vụ web, cookie cho session nên dược set ở dạng httpOnly. Hầu hết các ngôn ngữ lập trình web đều có hàm riêng biệt để set response hoặc set Cookie và bằng phương tiện này, httpOnly được ấn định. Ngày nay, đa số các trình duyệt đều hỗ trợ "httpOnly" và đây là biện pháp hữu hiệu để ngăn cản tình trạng đánh cắp cookie và session. Lập trình viên cũng cần chú ý chuyển đổi trọn bộ HTML thành "html entities" thay vì để nguyên các HTML tag như <>. Đặc biệt chú ý những khu vực "href" nhằm phòng chống tình trạng XSS. Nếu không nắm vững nguyên tắc, nên tìm vài tài liệu đặc thù về vấn đề này để tham khảo. OWASP www.owasp.org) là trang web có đầy đủ các thông tin về khía cạnh này.

Nếu người dùng có cơ hội nhập dữ liệu (ví dụ như diễn đàn cho phép thành viên gởi bài hoặc blog cho phép comment) thì ngay nơi nhập dữ liệu (đường vào) phải được kiểm soát chặt chẽ để chuyển hoá trọn bộ thông tin thành "html entities" trước khi nhập vào CSDL.

Về vấn đề của anh conmale nói em thấy hiện trạng này tồn tại ở nhiều site, và lỗi phần lớn nằm về mảng lập trình. Xoay quanh vấn đề sử dụng cookie và đánh cắp cookie bằng XSS. Em tự hỏi tại sao không dùng session thay thế cho cookie. Có lần em mang thắc mắc tới hỏi những người khác, thì đều nhận được lời khuyên là không nên xài session. Vì khi server bị DOS session sẽ là dao hai lưỡi sự tiện lợi và an toàn của nó sẽ không còn là lợi thế nửa, bù vào đó là sự cắt xén và làm giảm tài nguyên của server.

Nhưng dù sao em vẫn thấy thích sử dụng session, thường thì khi lập trình các modlue xử lí session em sẽ lưu lại IP của session và một vài thông tin để tạo ra một key md5 để chứng thực cho session mà người dùng tạo nên. Còn về vấn đề code chứa hàm session_start() bị DOS em vẫn chưa tìm được cách hợp lí.

Về chuyện anh conmale nói về chèn mã javascript vào href (dưới dạng <a href="#"javascript:alert('test');"); Trên một số trình duyệt còn có thể chền vào các file CSS dưới đạng như sau.

.test_class{
background-image: url("javascript:alert('')");
}

while(1){}

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	06/06/2011 23:14:59 (+0700) \| #15 \| 239523

K4i
Moderator

Joined: 18/04/2006 09:32:13
Messages: 635
Location: Underground
Offline

Giảm thiểu rủi ro trở thành zombie đối với các máy tính cá nhân, chạy Windows
1. Cài đặt và luôn cập nhật một chương trình diệt Anti-Virus (AV). Tuỳ thuộc vào cấu hình máy tính đang sử dụng và trình độ của người dùng mà có thể chọn lựa AV đơn thuần hoặc bộ AV + Firewall (Internet Security).
a. Các phần mềm miễn phí
- CMC Anti-Virus: www3.cmcinfosec.com/San-pham/CMC-Antivirus/14.epi
- AVG Anti Virus: http://free.avg.com/ww-en/download-free-antivirus
- Microsoft Security Essentials: http://www.microsoft.com/en-us/security_essentials/default.aspx. Lưu ý: Bản windows đang sử dụng phải có bản quyền.

b. Các phần mềm trả phí
- Kaspersky Antivirus / Kaspersky Internet Security: hiện đang có bán rộng rãi trên thị trường.
- BitDefeneder: hiện đang có bán rộng rãi
- ESET Nod32 Anti Virus / Smart Security: http://www.eset.com/home/

Lưu ý: các phần mềm trên đươc đưa ra mang tính chủ quan của người viết

2. Bật chế độ Automatic Updates trên các máy tính Windows có bản quyền. Hoặc giữ cho máy ở bản cập nhật mới nhất có thể (Service Pack 3 cho Windows XP, Service Pack 1 cho Windows 7).

3. Cập nhật phiên bản mới nhất có thể cho trình duyệt mình hay sử dụng (Internet Explorer 9, Firefox 4, Chrome 12).

4. Cập nhật phiên bản Flash Player mới nhất tại http://get.adobe.com/flashplayer/

5. Hạn chế click vào các link lạ / file đính kèm mà bạn nhận được qua Y!M, diễn đàn, email. Trước khi mở link, download file về máy cần xác định những nội dung sau
- Nguồn gốc có đáng tin tưởng hay không? (người gửi, nơi gửi, tên link)
- Nội dung mô tả sơ bộ có đáng tin hay không?
- Có nhận xét gì đặc biệt về link / file này từ những người khác hay không?
- Các nội dung liên quan đến khiêu dâm, sổ xố, trúng thưởng, cờ bạc thì tránh luôn từ đầu.
Nếu có nghi ngờ, không mở link đó ra / download file về máy.

6. Hạn chế sử dụng USB cá nhân tại các máy tính công cộng (máy tại cửa hàng internet, máy tính có nhiều người sử dụng). Sau khi cắm USB vào máy tính, cần quét virus với USB đó trước khi thực hiện bất kỳ một thao tác nào khác.

7. Hạn chế sử dụng các phần mềm "lậu":
- Sử dụng các phần mềm miễn phí có tính năng phù hợp với mình.
- Với các phần mềm "bắt buộc" phải sử dụng "lậu": hạn chế các động tác tự tìm kiếm crack, keygen,... của phần mềm trên mạng internet. Download các gói phần mềm lậu tại các website lớn, có nhiều người dùng (ưu tiên sử dụng serial) hoặc trao đổi với người quen có kiến thức sâu về sử dụng máy tính.
- Nên sử dụng các bản cài Windows nguyên bản, tránh các bản đã được chỉnh sửa hoặc tự dựng lại bởi một nhóm nào đó.

8. Giúp đỡ những người khác, ít hiểu biết về máy tính hơn bạn thực hiện những điều trên.

Sống là để không chết chứ không phải để trở thành anh hùng

[Discussion] Những việc cần làm để tự kiện toàn bảo mật trước sự tấn công của TQ	07/06/2011 07:31:07 (+0700) \| #16 \| 239541

TQN
Elite Member

Joined: 29/06/2006 22:28:01
Messages: 888
Location: Biết làm chi ?
Offline

Các malware/keylog hiện nay đa số được gởi tới cho nạn nhân ( smilie

?) dưới các định dạng .pdf, MS Office documents, flash. Malware code được giấu trong các file này, tận dụng các exploit code đã hay chưa công bố và máy nạn nhân chưa update các bản vá.
Để phân tích các file này, các bạn có thể tham khảo link sau:
Analyzing Malicious Documents Cheat Sheet. http://zeltser.com/reverse-malware/analyzing-malicious-documents.html

Nếu user chỉ muốn kiểm tra, có thể dùng các website check online sau:
1. https://www.vicheck.ca/
2. http://www.virustotal.com/
3. http://wepawet.cs.ucsb.edu/

Về phần user, nên update Windows đầy đủ, install AV mạnh (KIS, Bit...), cập nhật thường xuyên, install Firewall mạnh, như Comodo.

Go to:

Users currently in here
1 Anonymous