Trang Chính
Tháng 5/2011 tàu cá Trung Quốc ngang nhiên đi vào vùng biển nằm hoàn toàn trong vùng đặc quyền kinh tế của Việt Nam khiêu khích và cắt cáp của tàu Bình Minh 2 đang thăm dò dầu khí. Vụ việc đã làm cho nhân dân Việt Nam phẫn nộ, nhiều nơi xảy ra biểu tình phản đối Trung Quốc
Đầu tháng 6/2011 đã xảy ra nhiều cuộc tấn công mạng qua lại giưa hacker 2 bên. Nhiều website VN bị tê liệt vì bảo mật yếu kém. Bài viết này ra xuất phát từ nguyên nhân trên.
Mình sưu tầm bên diễn đàn Hvaonline.
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ụ.
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.
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.
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.
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à.
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.
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 đỡ.
Nguy cơ phá sản vì bị tấn công DDoS
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).
Nguồn hvaonline.net
Đầu tháng 6/2011 đã xảy ra nhiều cuộc tấn công mạng qua lại giưa hacker 2 bên. Nhiều website VN bị tê liệt vì bảo mật yếu kém. Bài viết này ra xuất phát từ nguyên nhân trên.
Mình sưu tầm bên diễn đàn Hvaonline.
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ụ.
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.
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.
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.
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à.
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.
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 đỡ.
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).
Nguồn hvaonline.net