[Question] Chống local attack bằng ModSecurity |
06/12/2010 23:13:26 (+0700) | #1 | 226503 |
CuteFTP
Member
|
0 |
|
|
Joined: 25/05/2009 02:07:45
Messages: 60
Offline
|
|
Chào các anh chị.
1. Em đang nghiên cứu về một số chống tấn công bằng ModSecurity. Không biết đối với kiểu tấn công local attack thì chống kiểu gì? Cơ chế ra sao? Mong mọi người chỉ rỏ.
2. Vấn đề về iptables. Em đã gỏ luật sau
Code:
iptables -A FORWARD -d 192.168.1.10 -i eth0 -p icmp -m icmp --icmp-type echo-request -m length --length 60:65535 -j ACCEPT
iptables -A FORWARD -s 192.168.1.10 -i eth1 -p icmp -m icmp --icmp-type echo-reply -m length --length 60:65535 -j ACCEPT
nhưng gặp vấn đề là khi client ping với tham số -l 32 lại ping bình thường trong khi đó length cho phép là từ 60 đến 65535 byte?
Em cảm ơn ạ. |
|
|
|
|
[Question] Chống local attack bằng ModSecurity |
07/12/2010 01:28:39 (+0700) | #2 | 226507 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
- Tấn công "local" là tấn công cụ thể ra làm sao? Nếu không biết "local" là cái gì thì chống nó là chống cái gì? Trước tiên, bồ cần liệt kê và phân tích ra hết những dạng "local" và tính chất cụ thể của những dạng này. Sau đó mới coi thử mod_security có khả năng nào để ngăn chặn từng loại. Thông thường, nếu bồ dùng shared host thì việc chống "local" là việc của nhà cung cấp dịch vụ bởi vì bồ không có đủ chủ quyền. Nếu nhà dịch vụ không bảo toàn chuyện này thì tìm nhà cung cấp khác. Nếu bồ là người cung cấp dịch vụ thì việc ngăn chặn local không nên sử dụng mod_security mà nên sử dụng các biện pháp "isolation" thật sự (ví dụ, chroot, SuExec cho từng virtualhost, tạo virtual machine cho từng virtual host....).
- 2 rules ở trên là cho "FORWARD" chớ đâu phải cho "INPUT". Khi nào thì cần thiết lập rule cho "FORWARD" và khi nào thì cần thiết lập rule cho "INPUT"? Bồ muốn thiết lập rule cho ping.... từ đâu? từ bên ngoài vô hay từ bên trong ra? Máy nào dùng để ping tới máy có IP 192.168.1.10 kia có được iptables kiểm soát hay không hay là nó có thể ping thằng tới đích?
Nên tìm hiểu căn bản iptables trước khi soạn rule và hiểu rõ cấu trúc mạng mình muốn tạo râ vì lay hoay kiểu này không đi tới đâu hết. |
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
[Question] Chống local attack bằng ModSecurity |
07/12/2010 09:22:55 (+0700) | #3 | 226524 |
CuteFTP
Member
|
0 |
|
|
Joined: 25/05/2009 02:07:45
Messages: 60
Offline
|
|
Trước tiên cảm ơn anh đã đọc và reply.
1. Tấn công local em hỏi trường hợp này là tấn công qua webshell (ví dụ r57, c99) thôi ạ. Việc tích hợp nhiều phần mềm trên một máy chủ sẻ gây tốn tài nguyên. Vì vậy em muốn ModSecurity chống lại cách này luôn. Các tools hổ trợ mạnh và nghiệp vụ khác thì em sẻ tìm hiểu sau. Trước mắt em muốn MS chặn như nào và có mấy kiểu mà thôi .
2. Mô hình của em gồm
+ 1 máy chủ CentOS làm Server Web (SV)(192.168.1.10).
+ 1 máy cũng CentOS làm firewall (dựa vào iptables sẵn có).
Firewall này là đơn dịch vụ và nó có 1 card tiếp xúc với mạng Internet (eth0: tiếp xúc với External, eth1 tiếp xúc với Internal)
Mọi truy vấn đến firewall đều bị DROP. Nếu truy vấn ko qua Firewall mà trực tiếp đến SV cũng bị DROP hết.
Firewall chỉ có chức năng là chuyển tiếp và NAT gói tin từ mạng ngoài đi vào và ngược lại mà thôi.
Vấn đề ở đây em ko hiểu cho dù client ping với length là 32 byte vào SV lại được. Trong khi đó đặt length là từ 60 đến 65535 byte? (thử ping 31 byte lại ko đc :">.
Chờ ý kiến của anh và mọi người. |
|
|
|
|
[Question] Chống local attack bằng ModSecurity |
07/12/2010 14:47:16 (+0700) | #4 | 226560 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
CuteFTP wrote:
Trước tiên cảm ơn anh đã đọc và reply.
1. Tấn công local em hỏi trường hợp này là tấn công qua webshell (ví dụ r57, c99) thôi ạ. Việc tích hợp nhiều phần mềm trên một máy chủ sẻ gây tốn tài nguyên. Vì vậy em muốn ModSecurity chống lại cách này luôn. Các tools hổ trợ mạnh và nghiệp vụ khác thì em sẻ tìm hiểu sau. Trước mắt em muốn MS chặn như nào và có mấy kiểu mà thôi .
Nguyên tắc bảo mật là phòng hiểm hoạ rồi mới chống hiểm hoạ . Điều này có nghĩa em nên phòng làm sao không cho phép những thứ như r57, c99 được upload lên máy chủ. Tiếp theo mới đến chuyện chống làm sao cho những thứ như vậy có thể thực thi được.
- Phòng: Có nhiều cách phòng và nguyên tắc phòng hoàn toàn dựa vô cấu trúc của trang web của em. Cách phòng upload files hữu hiệu nhất có lẽ là chế độ chmod trên file system. Ví dụ, em có file system là: /path/to/myweb/, trong đó myweb chứa forum, modules, includes, images, js chẳng hạn.
Nếu em không cho phép upload hình lên thì cách hay nhất là chmod -R ugo-w (chỉ là read-only) cho tất cả mọi người.
Nếu em cho phép upload hình lên thì em chỉ cho phép account nào đó chạy apache được quyền "w" trong một thư mục là images chẳng hạn thì nên chmod -R u+w /path/to/myweb/images/. Tất nhiên, phải vào thư mục images đó và chown <account_chay_apache> .
Ngoài ra, phòng còn có thể siết chặt trên php chẳng hạn như trên httpd.conf của em, em xác định thư mục images kia chỉ chứa các hình ảnh, js chỉ chứa javascripts và php không được quyền execute từ các thư mục ấy, em có thể áp đặt:
<LocationMatch /myweb/(images|js)/>
RemoveHandler .php
php_flag engine off
Options -Includes -Indexes
</LocationMatch>
Nếu em dùng 1 apache nhưng host nhiều virtual hosts thì nên áp dụng suExec (nên đọc tài liệu trên trang http://httpd.apache.org để nắm thêm suExec làm cái gì) và mỗi thư mục cho mỗi account chỉ có account đó có quyền rw mà thôi.
- Chống: Có nhiều cách chống nhưng với đề nghị dùng mod_security cụ thể của em thì có hai chuyện có thể làm được.
1. Áp dụng biện pháp lọc theo tên của các php được phép thực thi:
Giả sử trong /path/to/myweb/ có 100 php files và có các tên đặc thù nào đó. Em có thể liệt kê các tên này trong một file okphp.txt có nội dung như:
a.php
b.php
c.php
.....
và áp dụng hai mod_security rules như:
<Location /myweb/>
SecRule REQUEST_FILENAME "[color=red]!@pmFromFile /path/to/okphp.txt" "t:lowercase,deny,msg:'UnauthorizedFile'"
SecRule REQUEST_FILENAME "\.js|\.css|\.gif|\.jpeg|\.jpg|\.png|\.doc|\.pdf|\.txt|\.zip|\.rar" allow
</Location>[/color]
Để cản các php không thuộc danh sách cho phép trên và cho phép các .js, .css.... thực thi. Cách này có cái lợi và hại. Em thử suy nghĩ xem nó lợi hại như thế nào? .
2. Áp dụng biện pháp cản "RESPONSE":
Áp dụng một mod_security luật để cản một response nào đó match một string đặc thù nào đó. Ví dụ:
SecRule RESPONSE_BODY "Coded-by-Hacker" "deny,msg:'match_shell'"
String đặc thù đó tuỳ em xét và chọn lựa cho từng loại shell. Con shell nào cũng có một số điểm đặc thù và em nên chọn string nào đặc thù nhất để cho vào luật trên. Khi ai đó "may sao" upload được shell rồi và thực thi thì vẫn có những "response" match với string đặc thù kia thì sẽ bị mod_security cản.
Anh chỉ đưa ra phương hướng ở đây. Chuyện em cần làm là tìm hiểu các điểm đặc thù và tự thử nghiệm + điều chỉnh.
CuteFTP wrote:
2. Mô hình của em gồm
+ 1 máy chủ CentOS làm Server Web (SV)(192.168.1.10).
+ 1 máy cũng CentOS làm firewall (dựa vào iptables sẵn có).
Firewall này là đơn dịch vụ và nó có 1 card tiếp xúc với mạng Internet (eth0: tiếp xúc với External, eth1 tiếp xúc với Internal)
Mọi truy vấn đến firewall đều bị DROP. Nếu truy vấn ko qua Firewall mà trực tiếp đến SV cũng bị DROP hết.
Firewall chỉ có chức năng là chuyển tiếp và NAT gói tin từ mạng ngoài đi vào và ngược lại mà thôi.
Vấn đề ở đây em ko hiểu cho dù client ping với length là 32 byte vào SV lại được. Trong khi đó đặt length là từ 60 đến 65535 byte? (thử ping 31 byte lại ko đc :">.
Chờ ý kiến của anh và mọi người.
Nếu vậy thì 2 dòng iptables ở trên dành riêng cho người dùng từ trong LAN ping đến web server 192.168.1.10? Hai rules này chỉ có tác dụng với người dùng từ trong LAN mà thôi. Em biết lý do tại sao không?
Hãy thử đổi 2 rules ấy thành:
iptables -A FORWARD -d 192.168.1.10 -i eth0 -p icmp -m icmp --icmp-type echo-request -m length ! --length 60:65535 -j DROP
iptables -A FORWARD -s 192.168.1.10 -i eth1 -p icmp -m icmp --icmp-type echo-reply -m length ! --length 60:65535 -j DROP
coi thử? |
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
|
|
|
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|