cho em hỏi vậy cài ubuntu hay fedora tốt hơn cho 1 newbie ... google quá nhiều ý kiến khác nhau 

conmale wrote:

Trong mớ ở trên, chỗ nào nói là đã DROP udp đâu?


"Em đang cấu hình iptables với rule sau"
-A INPUT -p udp -j DROP

--> em "cấu hình" ở đâu? Cụ thể em làm những gì? Hãy trình bày cụ thể từng bước em thực thi xem? 

1. đầu tiên em dùng lệnh vi /etc/sysconfig/iptables để add thêm rule drop udp vào iptables
A INPUT -p udp -j DROP
sau đây là toàn bộ rule của iptables của em
Code:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -j DROP
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

sau đó restart lại dịch vụ iptables để rule được thực thi.
kiểm tra lại bằng lệnh iptables -L -v -n
Code:

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
93 5796 RH-Firewall-1-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 93 packets, 11092 bytes)
pkts bytes target prot opt in out source destination
Chain RH-Firewall-1-INPUT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
84 5052 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
5 628 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
4 116 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

sau đó em đã thử bằng cách dùng chương trình low orbit ion cannon để flood udp đến web server trong mạng local. và dùng tcpdump bắt dc cả mấy chục ngàn gói tin udp . bên cạnh đó truy cập web rất chậm và ssh bị đơ luôn.

nhờ anh conmale chỉ giúp với ạ 

Em có 1 ứng dụng SWING viết trên linux chạy tốt, tốc độ load frame chấp nhận được, nhưng khi chạy trên win 7 thì tốc độ thua rất xa (chậm hơn gấp mấy lần). Em mới học java nghĩ là code viết chưa được tối ưu. Có ai hướng dẫn em giúp để ứng dụng chạy nhanh hơn. 

Bà con tham gia thảo luận xôm tụ lắm nhưng vẫn chưa có cái nhìn toàn diện nên khó khai triển cho rốt ráo. Tớ xin đưa ra vài điểm mấu chốt để dễ khai triển.

Khi nói đến "tracks" (trong tinh thần cover-tracks), ta nói đến điểm nguồn (source) và điểm đích (destination).

Nguồn ở đây là một public IP trực tiếp tương tác với đích:

Nguồn ---> Đích.

Trong đó,

- Những gì đằng sau nguồn đều là tracks.
- Những gì trước đích và chung quanh đích đều là tracks.

Ví dụ, một perpetrator tấn công một máy chủ có IP là zz.zz.zz.zz và public IP của perpetrator là xx.xx.xx.xx. Nếu biểu thị ở một dạng "flow" đơn giản thì có thể là:

máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).

Với biểu thị trên thì "nguồn" chính là 3.3.3.3 và "đích" chính là 5.5.5.5.

Nếu packets đi từ 1.1.1.1 xuyên qua các jump servers (VPN, VPS, anonymous proxies....) trước khi trở thành 3.3.3.3 đối với đích 5.5.5.5 thì tất các những jump servers ấy đều thuộc về "tracks".

Ở phía "đích", ngoài FW (4.4.4.4) còn có thể có những "stealth" IDS nằm ẩn và thu thập tất cả mọi thông tin đi từ "nguồn" 3.3.3.3 (bởi vì IDS không thể nào detect được những gì thuộc về 2.2.2.2 hoặc 1.1.1.1 hoặc nếu được thì chỉ là những thông tin mơ hồ vì hầu hết anonymous proxy đúng nghĩa sẽ xoá hết những thông tin nguyên thuỷ của client đứng sau nó). Ở phía đích, ngoài IDS còn có thể có kernel-based keylogger thu thập hết những "actions" xảy ra trên chính 5.5.5.5).

Nói tóm lại, "xoá vết" bao gồm tất cả những gì đi từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) đến điểm đích và những gì xung quanh điểm đích. Bởi vậy, ngoài việc xoá (hoặc ẩn) những thông tin trên những chặng trung gian còn phải tìm hiểu xem đích được cái gì bảo vệ và theo dõi. 

Ok đón xe ôm về cà mau, chú nhớ mang cục 3G theo nha, mang nhiều sim rác vô nha, vào đó vừa tắm biển vừa hack nó mới đã !
 

tất cả chúng ta đều không (thể) sợ và không (thể) phòng ngừa những nguy cơ mà chúng ta không biết 

Vụ STL chúng ta khuyên nên vào trang chủ download các phần mềm. Giờ vào trang chủ cũng bị dính chưởng . Có khi nào là của mấy bác STL nữa không ta . Có lẽ nên thông báo rộng rãi cho cộng đồng, đồng thời tổ chức một chầu nhậu cho anh em RCE có sức làm việc  

Về phía server (quá trình xoá dấu vết sau khi khai thác):

Ở chặng này, chúng ta cần phải thu thập đầy đủ thông tin về server (như là phiên bản hệ thống, thông tin và phiên bản các dịch vụ, cấu hình)

=> Từ những thông tin mà ta thu thập được, giúp ta tìm ra được nơi lưu trữ logs (syslogs,app logs, ...). Khi có được những thứ này, ta sẽ gặp 1 trong những tình huống sau:
+ Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch !
+ Bạn không có quyền hạn để tác động được đến những file logs + server cấu hình có giới hạn ... Chẳng lẽ bó tay sao ? smilie
Tất nhiên là không rồi, hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ...
Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ...
+ Bạn không có quyền hạn để tác động được đến những file logs + server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi smilie Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:  

--->;cho mình hỏi tí, trường hợp log đã đổ về server log center thì sao hã bạn? 

• Hành động của bạn có thể lưu dấu vết ở những chỗ nào?
• Tính chất của các dấu vết bạn để lại

Ky0 wrote:

2. Log của ISP

Đây là các thông tin có thể tin cậy. Kết hợp với phân tích log trên Server ta có thể biết được cách thức hacker xâm nhập, thời gian xâm nhập, IP .... Đồng thời kết hợp với log trên server thì ta có thể hình dung được các hành động của hacker trên hệ thống, đồng thời tìm các điểm yếu của hệ thống.
 

Điểm này e là rất khó Ky0. 

• Đưa server dự phòng vào hoạt động, đồng thời triển khai Firewall và IDS để giám sát tránh tình trạng Hacker quay lại tiếp tục phá hoại.
• Cách ly Server bị tấn công đợi cơ quan điều tra vào cuộc.
• Đánh giá thiệt hại chung để đưa ra các thông tin bảo vệ khách hàng

• Soạn một thông cáo báo chí chính thức, nhằm kiểm soát thông tin tránh các thông tin ngoài luồng gây ảnh hưởng đến uy tín của công ty.
• Cáo lỗi với khách hàng và cung cấp các thông tin hướng dẫn bảo vệ quyền lợi của khách hàng.
• Phối hợp với cơ quan điều tra để công bố các thông tin gây nhiễu (nếu cần thiết) phục vụ quá trình điều tra.

Trên đây có nhiều bạn đã trả lời với nhiều ý kiến. Có những ý kiến khá hay, đáng học hỏi. Nhưng có vẻ có những ý kiến hơi khái quát, hơi bao quát quá. Các giải pháp đưa ra có thể hay chỉ áp dụng như một nguyên tắc, nguyên lý, qui định chung về bảo mật hay khắc phục sự cố mà thôi.

Tôi xin bổ sung thêm một vài ý kiến nhỏ.

Ta giả dụ hệ thống bị defaced theo cách mà trang web webscan.bkav.com.vn bị defaced, nghĩa là hacker đặt đươc một file "hacked.html" vào thư mục gốc hay Documentroot của Apache, tức là của webserver và sau đó một vài ngày nó bị tấn công từ chôi dịch vụ và bị ngưng trệ trong nhiều ngay, dù có vẻ không có sự tham gia của một hệ thống botnet (DDoS zombies) trên mạng.

Điều quan trọng đâu tiên chúng ta phải xác định rõ cấu hình cụ thể của webserver vừa bị hack.
Trước tiên, loại HĐH mà webserver cài đặt là một yếu tố rất quan trọng cần phải xem xét. Win2k3 hay Windows OS nói chung có những điểm yếu rất khó khắc phục, tạo cơ hôi cho hacker thâm nhập. Vấn đề phải tìm xem hành đông hay hiện tượng thâm nhập vừa qua có liên quan đến điểm yếu nào của Win2K3 hay không?
Chú ý là việc update tự động các lỗ hổng bảo mật cho Windows thì MS làm khá tốt và dễ dàng. Vì vậy chỉ nên tập trung vào các lỗi mà admin của hệ thống bị hack chưa kip update, vì một lý do nào đó, hay lỗi mà MS chưa kịp ban hành bản vá lỗi trên mạng. Có rất ít hacker tim ra lỗi 0-day để hack.

Điểm thứ hai chúng ta phải xem xét đến phiên bản web server (trình quản lý web) được cài trong hệ thống. Ở đây là Apache(Win32)2.2.15. Apache không ban hành các bản vá lỗi tự động như MS cho Windows. Họ chỉ ban hành các phiên bản mới thay cho các phiên bản cũ có lỗi, có khả năng bị hack. Hiện nay đã là Apache 2.2.22 (released 2012-01-31). Chỉ cần tham khảo tài liệu của Apache là biết các lỗi của phiên bản cũ. Vấn đề chỉ còn là phải xác định hiện tượng và hành đông xâm nhập cụ thể của hacker vừa qua có liên quan đến các lỗi này không và đó là lỗi nào? (Tuy nhiên xác định được điều này không hề dễ dàng tí nào).

Điểm thứ 3, nhưng có khi lại là quan trọng nhất là các application được cài đặt trong hệ thống. Các application ở đây là PHP 5.3, MySQL 5.1, vBulletin 4.1.5.... Chú ý là các application mới là các nguyên nhân tạo ra nhiều lỗ hổng để cho hacker đột nhập hay defaced hệ thống. Một Application đươc cải tiến để tiện dụng hơn, có nhiều tính năng hơn thì lai càng có nhiều lỗ hổng hơn, đó là hậu quả, là "side effect", điển hình là PHP chẳng hạn.

Vì vậy nếu hiện tượng haker defaced website và để lai một file "hacked.html" ở root thì điều trước tiên ta phải nghĩ đến lỗi RFI (không phải "Đài phát thanh Pháp quốc" đâu nhé! Hì hì- mà là Remote file Inclusion vulnerability) hay LFI (Local File Inclusion). Lỗi này cho phép hacker đưa (upload) một file bẩn vào hệ thống từ xa và đặt nó ở directory hacker mong muốn. Vấn đề là admin của hệ thống đã không config. PHP (cụ thể là file php.ini) kỹ càng....(Các bạn ở BKAV cũng nên kiểm tra lai điều này). Chú ý là chỉ PHP đời mới sau này, như PHP 5.3.x, mới có lỗi này. Hì hì.

Tất nhiên một hệ thống Windows cài DotNet (.Net framework ) như hệ thống mà anh conmale đưa, cũng có lỗi RFI, nhưng khả năng hacker tận dụng lỗi này có vẻ ít hơn.
Chúng ta nhớ lai, trong đợt các hacker TQ defaced hàng loạt website của VN vừa qua, chúng cũng tận dụng lỗi nói trên (RFI). Ngược lai các hacker trẻ VN cũng làm giống như thế.

Cũng cần xác định rằng việc hacker defaced website như trường hợp webscan.bkav.com.vn thì không có nghĩa là hacker đã chiếm được quyền admin (lấy được password) của hệ thống đâu nhé. Khoảng cách đến đó nhiều trường hơp khá xa đấy.

Còn việc hệ thống bị tấn công từ chối dịch vụ và bị ngưng trệ trong thời gian dài mà không có sự tham gia cuả một hệ thống botnet trên mạng, thì thực tế có thể có đấy. Vấn đề là phải có hai yếu tố:
- Hacker phải dùng một DoS tool loại nào?
- Hệ thống phải cài các application nào để DoS tool này mới có thể phát huy tác dung? (Chỉ cần một hay hai hacker DoS trong một vài phút là hệ thống có thể ngưng trê nhiều giờ).Hệ thống mà anh conmale nói có cài các application ấy đấy. Tuy nhiên vấn đề này tôi xin nói sau, vì bài viết đã dài.

Chỉ khi xác định đươc cách thức tấn công cụ thể của hacker thì ta mới chặn được nó và có biện pháp hữu hiệu để phòng thủ.

"The Only Way To Stop A Hacker Is To Think Like One"
 

Trong file tasklist.txt, có vài điểm mà em nghi ngờ cái server này đã nhiểm virus của stl. Uổng thiệt, nếu cậu hacker này mà tasklist thêm thông số thì em khoẻ biết mấy:

jusched.exe 1628 Console 0 6,136 K
jusched.exe 2948 1 6,192 K
wuauclt.exe 3652 Console 0 3,896 K
jucheck.exe 3392 Console 0 8,588 K
jucheck.exe 4136 1 7,344 K  

jucheck # jusched nhé các bạn. Khả năng jucheck.exe là virus cao hơn jusched.exe của Java Update.
Nếu đã tắt Windows Update thì wuauclt.exe sẽ không run, các bạn còn nhớ wuauclt.exe trong "đống" mèo què của stl chứ.
Nếu em đoán đúng thì hết nói về cái BKAV phờ rồ. Nhưng nói vậy thôi chứ làm sao em có 3 mẫu này được ?
 

Cái ngu số 04

Administrator lướt web ngay trên server và trong giờ làm việc

Bạn vui lòng tham khảo tệp tin "tasklist.txt" , bạn sẽ thấy các dòng sau:

chrome.exe                    4520 Console                    0     42,804 K
chrome.exe                    4588 Console                    0     32,088 K
 

Sau khi thấy có quá nhiều process của trình duyệt Chrome đang vận hành trên server chúng tôi nghi ngờ là quản trị viên server đang lướt web ngay trên server nên thực hiện việc sniff gói tin trên server, kết quả khá thú vị khi thấy quản trị server đúng là đang lướt web đọc báo, thậm chí vô Facebook bằng Server của BKAV. Chúng tôi rất tiếc không thể cung cấp gói sniff đó lên đây do nó chứa nhiều thông tin có thể làm hại người vô tội.
 

• Trường hợp hacker xóa log bằng các câu lệnh xóa thông thường => Dễ dàng khôi phục lại log gốc bằng các công cụ chuyên dụng.
• Trường hợp hacker xóa log bằng các công cụ xóa an toàn (xóa và ghi đè 30 lần chẳng hạn) => Không thể phục hồi log để phục vụ quá trình forensic. => Việc truy tìm và buộc tội hacker là điều cực kỳ khó khăn. Tuy nhiên cũng có thể còn chút dấu vết nào đó nhận dạng hacker (chương trình xóa an toàn hacker sử dung, thói quen xóa dấu vết khi xâm nhập ....)

• Thu thập thông tin từ Blog: IP truy cập vào http://bkavop.blogspot.com/ post bài, email đăng ký blogspot.
• Thu thập thông tin từ nhà cung cấp email: IP và log quá trình đăng nhập và sử dụng tài khoản email.
• Thu thập thông tin từ các các nguồn khác: HVA, bkav, vozforum … => tìm các sai sót và cung cấp dữ liệu hình thành "chân dung" hacker

cách đây vài năm tôi có viết một bài nhắc đến Tor như là một công cụ tốt để trở nên ẩn danh trên Internet. bây giờ đọc lại thì tôi mới thấy, nói như cách g4mm4 hay nói, hạn chế của tôi hồi đó. bạn nào nghĩ rằng sử dụng Tor là an toàn thì bây giờ bắt đầu lo lắng là vừa. đối với một hệ thống có sự chuẩn bị tốt thì phải rất cao tay mới mong lai vô ảnh, khứ vô hình khi xâm nhập vào hệ thống đó. địa chỉ IP, thứ mà Tor có thể giúp che dấu một phần, chỉ là một trong số rất rất nhiều "dấu vân tay" mà chúng ta để lại khi duyệt web. 

• Dấu vân tay (Địa chỉ IP)
• Dấu vết (hành vi của thủ phạm) và chứng cứ (log) tại hiện trường
• Phân tích tính cách khả năng, hành vi của tội phạm (Thu thập thông tin từ các nguồn + Các biện pháp thăm dò tâm lý) => Phác họa chân dung cơ bản của tội phạm.

• Dựa trên các thông tin log ISP, và thông tin được cung cấp từ các công ty, tổ chức … Ta có thể xác định được là hacker sử dụng Tor nên việc tìm ra địa chỉ IP thực của hacker gần như là không thể (tạm thời thiếu mất một yếu tố).
• Dấu vết (hành vi của thủ phạm) và chứng cứ (log) tại hiện trường của BKAV chưa xác định được trạng thái. Nhưng dù chứng cứ (log) tại hiện trường có bị xóa sạch hay tạo hiện trường giả (sửa log, làm nhiễu log) thì vẫn còn các dấu vết (Các bước hành động tổng quát của hacker).
• Thêm các thông tin từ http://bkavop.blogspot.com/, https://www.facebook.com/pages/BKAV-Op/197446347029547?sk=wall, các forum … Thì ta có thể hình thành bảng đánh giá phác họa chân dung Hacker.

Đại tá Trần Văn Hòa, Cục phó Cục Cảnh sát phòng chống tội phạm công nghệ cao (C50 - Bộ Công an), khẳng định với VnExpress.net rằng đã xác định được hacker - tác giả của những thông tin về các lỗi bảo mật của Bkav đang gây xôn xao trên mạng, đồng thời cho biết những gì hacker đưa lên có một số điều không chính xác.
 

• Đây là hành động nhóm hacker lo sợ sẽ “ảnh hưởng đến người vô tội” hoặc BKAV & C50 thí con tốt để trấn an dư luận. Lúc này mục tiêu ban đầu của hacker( đòi lại công bằng cho hacker bị bắt và hạ uy tín của BKAV) không đạt được.
• Hacker đã thăm dò và lên kế hoạch tỉ mỉ cho việc tấn công BKAV (deface, drop database, dump database, thông tin cấu hình các thành phần, …) đồng thời lộ trình đưa lần lượt các thông tin lên mạng. Nhưng vẫn chưa dự trù đối phó hết các chiêu tâm lý của BKAV & C50. Chính vì thế “thư gửi điều tra viên” kia có chút lúng túng nhưng lại được viết theo phong cách hành văn khác (giống cách hành văn phản hồi cho anh conmale). -a-
• Hacker đã xác định tấn công BKAV thì C50 sẽ vào cuộc=> một mình Hacker đấu trí với một đội ngũ chuyên nghiệp là việc làm dại dột -b-

• BKAV vẫn tiếp tục im lặng nếu tìm được nghi phạm sẽ quăng bom, nếu không tìm ra thì im lặng và dùng các biện pháp bưng bít thông tin nhằm cho vụ việc rơi vào quên lãng.
• Hacker vẫn lần lượt tung các thông tin có được trong đợt xâm nhập BKAV
• Màn đấu trí giữa C50 và hacker
• Màn đấu khẩu giữa sgtc BKAV và cộng đồng IT

• Nghi can sẽ được hai nhân viên thẩm vấn (Có thể có một vài người giám sát để phát hiện nghi can có nói dối hay không). Bằng các biện pháp tâm lý từ đe dọa đến mềm mỏng để khai thác thông tin và khiến nghi phạm mất bình tĩnh mà để lộ sơ hở. => Nếu nghi can phạm tội thực sự sẽ để lộ sơ hở và bị người thẩm vấn hỏi vặn lại => Thành khẩn khai báo.
• Các nghi can có mối liên hệ với nhau thì tung hỏa mù dạng: “Thằng xxx và thằng yyy đã thành khẩn khai nhận, và nó nói chủ mưu chính là anh/chị” => Lần lượt từng người khai báo với suy nghĩ: “Nếu thằng xxx hay thằng yyy có khai báo thật và đổ tội hết lên đâu mình thì toi”
• Nghi can khai báo lung tung hoặc không có gì để khai báo => Tiến hành thẩm vấn các nghi can khác. Nếu không thu được gì thì tiếp tùng sàng lọc lại các đối tượng. => Mất thời gian và có thể không tìm ra được thủ phạm.

• Một đấu trí với hai thì không thể dành chiến thắng được . Thực tế chứng minh dù tội phạm có tinh ranh và ngoan cố đến đâu đi chăng nữa, thì sau một thời gian thẩm vấn sẽ ngoan ngoãn nhận tội => Chính vì thế trong phim nghi can thường không nói gì khi không có luật sư bên cạnh. Ở Việt Nam thì tùy từng hoàn cảnh .
• Đôi khi nghi can tâm lý không vững nên sau khi bị đe dọa, bị mớm cung vẫn có thể nhận tội bừa => Đối với tội phạm kinh tế hay tội phạm công nghệ cao thì rất hiếm có trường hợp này.
• Nếu nghi can hoàn toàn không phạm tội thì sẽ chả có gì để khai => Đôi khi nghi can phạm tội nhưng khả năng ứng phó và đối đáp quá tài tình thì các điều tra viên cũng không thu được kết quả gì (Trường hợp này chỉ có những chuyên gia tình báo, nhân viên an ninh nằm vùng được đào tạo bài bản mới vượt qua được, trừ trường hợp mấy thằng bị mất trí nhớ )

Em thấy cái này em vào bằng IE <7 thì nói báo thế nhưng nếu qua FF hay Chrome thì lại không vấn đề. Cho em hỏi sao lại thế ạ?