20:32
zeko sock
Tôi định viết về điều này nhiều lần rồi nhưng mãi vẫn chưa có bài nào cho hợp tình hợp lí đúng thời điểm. Hôm nay, sau những ngày tháng dài đánh vật với nhu cầu và mục đích an toàn thông tin cho khách hàng tôi lại có dịp hí hoáy viết lại vài dòng. Coi như 1 sự lưu giữ kỉ niệm và kinh nghiệm cho bản thân
Khách hàng của tôi là 1 cậu chủ nhỏ đang quản lí 1 hệ thống hàng trăm website. Từ các doanh nghiệp vừa và nhỏ đến các trung tâm, dịch vụ và thậm chí là cả trường THPT, đại học. Cậu chủ này sở hữu 1 server chính và 2 VPS. Hầu hết các site được xây dựng trên nền tảng Joomla (Open Source) Platform : Linux CentOS x86_64. Cài đặt đầy đủ các dịch vụ WebServer + MailServer + DNS + FTP. Tình hình tệ hại xảy ra liên tục trong những tháng đầu năm. Các Website của cậu ta liên tục gặp các vấn đề error database, deface, v.v… Nói chung cảm giác đầu khi bước vào nó như một ngôi nhà hoang không khóa với nhiều ô cửa sổ to và rộng. Tôi nhận nhiệm vụ hạn chế triệt để vấn đề nhà không cửa, cửa không khóa này trong 1 ngày không nắng không mưa, không chất xúc tác.
Nó đã diễn ra như 1 giấc mơ, có đôi lúc là ác mộng, lắm khi là 1 cảm giác ngon ngọt tươi mát. Nhưng tất cả qua đi thật chậm và chính xác theo lối vô định
Những ngày đầu tôi bỏ rất nhiều thời gian và công sức để rà soát các website trên hệ thống. Tựu trung chúng đều có chứa ít nhiều vài con shell của các bạn trẻ ham nghịch phá, vài lỗ hổng khởi nguồn từ SQL Injection. Tất cả thông tin tôi thu thập được đều đưa vào notepad. Từ những điều đó tôi hình thành những căn nguyên khởi sự của vấn đề và tìm cách giải quyết từng điều một. Trong trường hợp này không thể mang tính chất “đánh nhanh thắng nhanh” vào đó. Tin tưởng chậm mà chắc tỉ lệ thành công vẫn cao hơn
- Một mặt tôi cài đặt các ứng dụng tìm kiếm trojan, virus trên mã nguồn mở. Avgscan coi như là 1 lựa chọn tạm ổn. Dù gì nó cũng khó lòng phát hiện các shell đã bị encode. Tuy nhiên các shell chưa bị thì vẫn có thể phát hiện ra. Mặt khác tôi yêu cầu cậu chủ cùng các nhân viên cậu ta rà soát lỗ hổng của các site hiện tại.
#avgscan -r report.txt -s /home
Quãng thời gian file report list các shell chứa trong cụm home được hình thành sau gần 4 tiếng đồng hồ. File report với dung lượng gần 50mb. Với các hàng dài virus – trojan nối đuôi nhau. Nhưng tạm khoan hãy nhắc đến các virus chứa trong mail của khách hàng. Để ý những link chứa shell đuôi .php .pl
Mất 1 khoảng thời gian gần 2 ngày trời để lọc ra các link chứa shell và lần lượt rm chúng. Thật may vì chúng không nhiều như tôi tưởng. Chỉ khoảng 20 – 30 con. Nhưng tôi nghĩ phải nhiều hơn số đó, vì tôi không tin avg có thể scan được hết các shell có trong server. Ít nhiều nó cũng sẽ phải bỏ qua những con đã được mã hóa dưới dạng base64 hay 1 thuật toán nào đó. Có khá nhiều con shell lạ nguồn gốc thổ nhĩ kỳ hoặc nga được up lên server. Chẳng trách khách hàng kêu la oán thán. Những thứ này hầu như by pass được firewall mặc định của hệ thống
Việc 1 hệ thống bị local có thể khởi nguồn từ nhiều nguyên nhân, nhưng đa phần tôi thấy lỗ hổng nguy hiểm nhất mà shell có thể bị upload lên là từ SQL inject. Cảm nhận điều này, tôi nhờ bên khách hàng check kĩ từng source site của họ 1 lần nữa, nhằm hạn chế việc shell bị upload lên thông qua đó. Tôi hình thành nhanh 1 qui trình hạn chế các shell còn tồn tại như sau
- Chmod lại các file & folder của các site. Đảm bảo việc 1 file được thực thi dưới quyền hạn nhất định. Hạn chế việc cấp toàn quyền cho nhóm Others.
- Cài đặt và triển khai ModSecurity, tiến hành viết rules nhằm triệt để việc thực thi các câu lệnh nhạy cảm lên hệ thống
- Audit các sự kiện được trả về từ phía người dùng thường xuyên, từ đó lên phương án hỗ trợ kịp thời nếu có biến cố xảy ra
Tôi không liệt kê việc hạn chế các Functions của PHP vào 3 việc trọng điểm trên kia. Thiết nghĩ bản chất của việc chống Local Hack không phải ở đây. Thứ nhất nếu disable các hàm trên php sẽ gây ảnh hưởng to lớn đến các site đang chạy. Thứ hai nó sẽ gây khó khăn đối với việc lập trình. Tất nhiên khi đối mặt với 1 vấn đề an toàn thông tin, khách hàng phải chọn lựa 1 là bảo đảm an toàn tuyệt đối 2 là hiệu năng công việc. Kĩ năng của người làm bảo mật không phải ở khả năng triển khai và cài đặt các qui chế các ứng dụng 1 cách máy móc. Mà nó phải là sự cân bằng của việc đảm bảo an toàn và hiệu năng xử lí công việc từ phía người dùng.
- Mọi người có thể thấy ở đây tôi phân quyền cho các file & folder như sau. Đối với root tôi cho toàn quyền. Đối với người dùng cùng nhóm owner thì không và bên nhóm Other tôi chỉ cấp sự thực thi cho họ. Điều này hạn chế được việc đọc các file tài nguyên giữa những người dùng với nhau. Tôi nghĩ còn khá nhiều cách Chmod khác mà mọi người có thể bắt gặp trên mạng. Tuy nhiên hiểu nó và làm theo nó là 2 điều hoàn toàn khác nhau
#chmod 0711 /home/*/public_html
Các bạn có thể download nó từ Website chủ, tiến hành biên soạn và cài đặt. Tuy nhiên chú ý download đủ các gói thư viện cần thiết về. Kèm theo việc chắc chắn module Unique id đã được cài đặt cùng Apache. Đơn giản hơn có thể sử dụng câu lệnh Yum và install nó từ repo của Remi
Đến phần viết Rules cho Modsecurity. Tôi nghĩ không gì hơn là bạn nên download 1 số ebook về nó. Các rules được nói và phân tích rất kĩ. Điều này đảm bảo cho bạn có cái nhìn tổng thể hơn các làm việc của từng Rules từ đó đưa ra lựa chọn thích hợp nhất. Tuy nhiên ở đây vẫn có 1 vài rules để các bạn tham khảo thêm
Thực sự khi viết và làm việc với Modsecurity, tôi vô cùng bỡ ngỡ. Vì đa phần trước giờ tôi thường áp rules 1 cách tràn lan theo những gì có sẵn của thư viện rules theo từng kiểu tấn công. Tuy nhiên lần này khó mà làm thế, bởi đơn giản các shell trên kia hầu như có thể bypass được hết các qui chế có sẵn do mình áp đặt. Thế nên tôi sử dụng ethereal để phân tích từng request từ phía client. Điều này tuy có hơi mệt mỏi lúc đầu thế nhưng vẫn còn tốt chán nếu thật sự muốn triệt để hóa ngần ấy thứ còn vương vãi trên hệ thống
SecRule REQUEST_URI "/etc/passwd"
SecRule REQUEST_URI "/etc/php.ini"
SecRule REQUEST_URI "/bin/ps"
SecRule REQUEST_URI "/usr/bin/id" chain
SecRule REQUEST_URI "/usr/bin/perl"
SecRule REQUEST_URI "/bin/ls" chain
SecRule REQUEST_BODY "/etc/passwd"
SecRule REQUEST_URI "/~(root|ftp|bin|nobody|named|guest|logs|sshd)/"
SecRule REQUEST_URI "/\.it/viewde"
SecRule REQUEST_URI "/cmd\?&(command|cmd)="
SecRule REQUEST_URI "/cmd\.php\.ns\?&(command|cmd)="
SecRule REQUEST_URI "/cmd\.(php|dat)\?&(command|cmd)="
SecRule REQUEST_URI "/[a-z]?(cmd|command)[0-9]?\.(gif|jpe?g|txt|bmp|png)\?"
SecRule REQUEST_URI "<(.|\n)+>"
SecRule REQUEST_URI "<[[:space:]]*script"
SecRule REQUEST_URI "delete[[:space:]]+from"
SecRule REQUEST_URI "insert[[:space:]]+into"
SecRule REQUEST_URI "select.+from"
SecRule REQUEST_URI "file=%2Fetc%2Fpasswd"
SecRule REQUEST_URI "file=/etc/"
SecRule REQUEST_URI "act=/"
- Phần cuối là việc audit. Tôi muốn giới thiệu với mọi người 1 công cụ được tích hợp sẵn trong kernel các phiên bản linux. Để triển khai và cài đặt cái này thì hoàn toàn đơn giản
# chkconfig auditd on
# /etc/init.d/auditd start
Ngoài ra khi tiến hành việc bảo mật lại hệ thống trước những tác nhân kia tôi cũng luôn khuyên khách hàng sử dụng các biện pháp mã hóa chuyên nghiệp, để chống bị đọc trộm thông tin nếu chẳng may các rules của tôi có bị bypass. Có thể sử dụng Zend code hoặc Ion Cube như 1 ví dụ điển hình cho công việc này
Thực sự sau 1 case qua đi, điều làm tôi hài lòng nhất chính là sự hài lòng của khách hàng và khách của khách hàng. Nó đến từ sự cân bằng hiệu năng làm việc và đảm bảo an toàn thông tin như tôi đã đề cập. Hãy thử tưởng tượng xem, bạn vẫn có thể làm việc trong 1 khuôn khổ tự do với chiếc vòng bao bọc cứng cáp. Chẳng hạnh phúc quá còn gì. Tuy nhiên điều tôi muốn nói vẫn đề cao phòng hơn là chống. Nếu ngay từ đầu, có sự cộng tác từ phía khách hàng trong việc an toàn source code thì rõ ràng shell hoàn toàn không thể có mặt trên server. Duy có điều nếu không có shell thì tất nhiên tôi không thể viết bài này cho các bạn đọc.
Posted in: 
0 nhận xét:
Đăng nhận xét