Tự kiện toàn bảo mật trước sự tấn công của hackers

Published by Việt Coding on

Xin chào các bạn,

Chắc Việt Coding không cần phải nói nhiều về tình hình căng thẳng tại biển Đông hiện nay giữa Việt Nam chúng ta và Trung Quốc. Trong những ngày gần nay, đại đa số đồng bào chúng ta đang sôi sục trước sự kiện có liên quan đến An ninh Quốc gia này. Tuy nhiên, ít nhiều trong chúng ta đã nảy sinh những phản ứng tiêu cực. Điển hình là hàng loạt hacker – chưa xác định được nguồn gốc – tấn công nhiều website của Trung Quốc. Hầu hết là kiểu tấn công deface (thay đổi giao diện, nội dung,…) website thay thế hình ảnh bản đồ Việt Nam, Hải quân Việt Nam và khẳng định chủ quyền hai quần đảo Trường và Hoàng Sa. Sự bộc phát này đã ngay lập tức bị trả đũa khi hàng loạt website Việt Nam bị tấn công tương tự. Nghiêm trọng hơn trong đó có các website của chính phủ (.gov.vn). Ngoài ra cũng có một số website nhỏ lẻ không liên quan đến chính trị cũng bị tấn công. Để tránh tổn thất có thể xảy ra, Việt Coding xin trích đăng lại bài viết của thành viên hnd trên diễn đàn HVAOnline, qua đó các bạn có thể chuẩn bị tự bảo vệ mình nếu chẳng may lọt vào tầm ngắm của hackers:

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ụ.

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.

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.

(Còn tiếp…)

(Nguồn: HVAOnline)


Việt Coding

Là một người đam mê lập trình, tôi vọc vạch đủ thứ liên quan đến lập trình cho thoả chí tò mò. Hiện làm chủ yếu ở mảng phát triển ứng dụng di động cho iOS và Android với React Native. Thỉnh thoảng vọc vạch mấy thứ liên quan đến Internet of Things như Smart Home. Đang nghịch mấy con Raspberry Pi và thấy nó cũng thú vị :)

14 Comments

Quốc Việt · 07/06/2011 at 12:51

Bài viết hay quá, không biết bảo mật toàn diện cho wordpress thì cần phải dùng những gì nhỉ, sợ nhất là bị tấn công ddos.

    Việt Coding · 07/06/2011 at 21:20

    Hiện tại chưa có cách nào chống được tấn công DDos đâu bạn !

      Mẫn · 08/06/2011 at 00:50

      Theo Mình nghĩ Tác hại của DDOS là – Ý kiến của mình Thôi nha 🙂

      1. MẤT BĂNG THÔNG CỦA WEBSITE
      2. MÁY CHỦ CHẠY CHẬM HOẶC SẬP NẾU QUÁ TẢI

      Khắc phục 1: Tạo 1 Trang Welcome Trước khi vào Trang chính. Trang chính kiểm Tra nếu REFERER không phải Từ Trang Welcome vào sẽ đẩy ra Welcome lại.

      Khắc phục 2: Do chủ HOSTING Thôi. Mình cấu hình sao khi nhận Thấy 1 IP KẾT nối quá nhiều Trong 1 khoản Thời gian ngắn Thì khóa IP đó Trong vòng 5 PHÚT chẳn hạn.

      🙂

        Việt Coding · 08/06/2011 at 12:26

        Hi,
        Cả 2 cách bạn nói người ta đều đã nghĩ đến. Không những vậy còn nghĩ ra nhiều cách hơn thế nhiều. Thế nhưng đến nay DDoS vẫn là một nguy cơ không thể phòng chống được. Nôm na, DDoS là Tấn công từ chối dịch vụ, bản thân cái tên của nó đã nói lên vấn đề rồi: Từ chối dịch vụ. Kẻ tấn công tạo ra vô số những truy vấn đến website khiến máy chủ phải hoạt động hết sức để đáp ứng những request “ma” đó khiến nó quá tải, nghẽn đường truyền và không thể đáp ứng những request thực sự.

        Với 2 cách bạn nêu trên, cách 2 có thể tạm chấp nhận nhưng cách 1 là vô phương. Hãy cùng phân tích nhé !

        Giả sử bạn bị tấn công bởi 1 triệu request / giây (thực tế có thể lớn hơn nhiều) và giả sử tiếp theo là hosting của bạn chịu đựng được từng ấy request trong 1 giây mà không bị nhà cung cấp suppend account hosting. Như vậy hosting của bạn phải :

        – Tiếp nhận 1 triệu request
        – Lần lượt kiểm tra REF của 1 triệu request đó
        – Nếu đúng thì chuyển request vào web chính
        – Nếu sai thì chuyển về trang welcome

        Như vậy tính sơ sơ hosting của bạn phải xử lý 4 thao tác cho 1 request ~ 4 triệu thao tác mỗi giây 😀 Hosting không ngắc ngư mới là lạ !

        Đó chính là tác hại không thể chống đỡ của DDoS 🙂

          Mẫn · 08/06/2011 at 14:50

          Thanks mình đã rõ. Vì lúc Trước mình ghé Thăm mấy diễn đàn

          Họ có chiêu nhấn hình ENTER để vào diễn đàn còn không vẫn ở Trang đó.

          Mình Tưởng cách đó có Tác dụng :d

            Việt Coding · 08/06/2011 at 15:38

            Thực ra những cách anti-DDoS đều có một tác dụng nhất định trong một giới hạn tấn công nào đó, ví dụ cỡ vài chục ngàn request nhưng khi số đó tăng lên thì chỉ có chết ! Do đó, cho đến nay DDoS vẫn là kiểu tấn công nguy hiểm nhất và chưa có cách nào thực sự hữu hiệu để ngăn chặn !

            Thân,

tuanht · 10/06/2011 at 22:06

Nếu vậy thì bọn tq chỉ cần một spy được cài đặt bí mật vào một máy nào đó, mà cái này thì tụi chính quyền tq làm quá dễ là cài ngầm vào máy tính mới bán ra, hay từ các phần mềm chính thức (ví dụ giống như BKAV), là có thể điều khiển máy đó tham gia vào cuộc tấn công, mà nghe đâu số máy tính của nó hình như lên đến hàng chục hoặc trăm triệu >.<

Võ Duy Tuấn · 10/06/2011 at 23:06

Tình cờ phát hiện blog của anh cũng khá thú vị. Cảm ơn bài viết hay.

Mèo khùng · 11/06/2011 at 21:01

Em khá thắc mắc về cái không đăng ký tên miền bằng những email miễn phí như yahoo, google. Vậy phải dùng cái gì để đăng ký vậy anh.

    Việt Coding · 13/06/2011 at 09:44

    Hi,

    Bạn sử dụng email riêng, ví dụ bạn có domain abc.com thì nên đăng ký email với domain đó. Trường hợp không có, bạn sử dụng Google Mail với chức năng bảo vệ 2 lớp cho an toàn.

    Thân !

Hoc Marketing · 17/06/2011 at 19:01

Em cứ tưởng bài này chống được DDos nên mò vào 🙁

    Việt Coding · 17/06/2011 at 21:10

    DDoS là vô phương chống được, chỉ có giảm thiểu tác hại của nó thôi !

Do go noi that · 01/11/2011 at 00:34

Phương pháp của Mẫn có dùng cũng không thể được hả các bác?

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *