Messages posted by: vd_

Mikko Hypponen của F-Secure có nói mẫu Flame đã được report từ 2010, tuy nhiên vì Flame sử dụng lib phổ thông, và nhìn giống như 1 soft bình thường nên không bị phát hiện. Nói 1 cách khác, nếu virus/trojan càng giống 1 phần mềm bình thường thì sẽ có khả năng tránh bị phát hiện thay vì phải cố gắng pack, encrypt hoặc làm khác người :/

http://www.wired.com/threatlevel/2012/06/internet-security-fail/

@lamletoi

Bạn nên cân nhắc dùng barnyard2-1.10beta2 (1.9 chưa hỗ trợ)

unified2
snort ----------> barnyard2 ------> snortsam

Sau này có thể upgrade từng phần dễ dàng hơn là cứ phải patch snort

Đọc cái này đi bạn (sign = authenticate)

http://blog.thoughtcrime.org/the-cryptographic-doom-principle

@Ikut3

Bạn nghiên cứu auditd, config để log toàn bộ lại sys call access vào dir/file, sau đó cron query cuối ngày để đưa vào db hoặc là hiển thị lại.

http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
http://people.redhat.com/sgrubb/audit/

Một cách khác là bạn thông qua chính nfs/cifs để log và đưa vào db các hành vi truy cập file.

@Ky0
http://rfbproxy.sourceforge.net/manpage.html
-> save vnc session thành video

@tamvunb

trả lời các câu hỏi sau để làm thành đề cương
- what? (what is internet banking?)
- who? (who uses internet banking?)
- how? (how internet banking work?)
- why? (why need protect?)
rồi đi sâu tiếp (breakdown) cho các thành phần của internet banking cho đến tận các thiết bị

@hoakhanh
2 cách:
1- dùng snortsam trên fw nhận drop request từ snort agent
2- send snort log (fast_alert) về 1 server (có thể là chính cái fw đó) rồi xử lý log, add iptable rule

@ikut3

workstation trong LAN nếu flood thì phone lên HR nói chuyện được chứ ta? Multiple attempt trong LAN là đủ để IT lưu ý account rồi.

Theo ý tui thì trong trường hợp bạn nêu nên làm SSL, có điều nhớ lưu ý expired certificate.

Đâu có ai chắc attacker chỉ là user thường mà không là một người net/sys admin bất mãn smilie

-> SSL ít nhất cũng hạn chế được 1 phần nào

theo tui thì nên SSL càng nhiều càng tốt smilie

, tất nhiên phải cân nhắc đến năng lực xử lý nữa => làm risk assesment đi rồi quyết.

@chiro8x

Bạn phải biết bạn viết cho ethernet, FDDI hay 802.11 để xác định các header field cho packet tương ứng -> từ đó cast struct cho đúng. PC có sử dụng cả ethernet và 802.11. Server có lẽ chủ yếu trên nền ethernet.

Bạn dùng wireshark, lưu ý các nó display capture data như là 1 series những struct lồng trong struct để thể hiện mô hình lớp của mạng: layer ở dưới add thêm header (hoặc wrap trong header/footer) vào packet của lớp trên.

@chiro8x

gcc -I<include dir cài openssl> -L<lib dir của openssl> -lssl test.c

chạy thêm ldconfig -p (as root) để coi trong system hiện tại các lib của SSL được đặt ở đâu.

openssl là một lib rất quan trọng nên tránh trường hợp config ld load nhầm version sẽ dẫn đến hệ thống không ổn định

keyword: arp poisoning, aircrack-ng sử dụng airmon & airdecap

OTR plugin

Tui lười viết dài, nên chắc tóm tắt:
1. Vào hệ thống mới tức là vào môi trường lạ, và admin của môi trường là chủ môi trường đó, vì vậy bước đầu tiên quan trọng nhất luôn luôn là điều tra về môi trường chuẩn bị thâm nhập. Điều tra thông qua social engineering, dùng tool v.v... Chỉ khi bạn biết khá khá về môi trường bạn chuẩn bị attack thì bạn mới có thể xoá dấu vết được.
2. Nguyên lý cơ bản: tất cả những gì bạn chạm đến đều có dấu vết của bạn => như Ky0 nói, muốn người ta biết thì đừng có làm. Dù cho bạn chuẩn bị xoá dấu vết kỹ (dùng tor, vm, proxy ...) thì với đủ time người ta cũng sẽ lần ra bạn.
3. Vào hệ thống thì bạn cần 1 pc, 1 đường mạng, và 1 server, như vậy sẽ có trace của bạn ở máy pc, ở các thiết bị mạng, và ở server.
3.1 Ở PC bạn có thể dùng tor v.v... để giấu luồng traffic, xoá VM để xoá marking.
3.2 Đối với thiết bị mạng và server, nếu hệ thống dùng central log + central analysis (SIEM system) thì bạn chỉ có thể gây nhiễu để làm khó khăn cho việc truy vết.
3.3 Gây nhiễu thông qua việc phát hiện cơ chế log của server, cơ chế gửi log đến central server và sau đó phun dữ liệu giả vào. Tuy nhiên sẽ phải rất cẩn thận để dữ liệu giả đủ nhiều và đủ hợp lý để che được các hành vi của bạn vì nếu tạo dữ liệu giả lộ liễu thì bạn sẽ tự hại mình trước do nhiều nhiễu sẽ dễ trigger các sensor của admin đặt ra => sau khi vào được server thì việc đầu tiên phải làm là giải quyết liền log daemon và tạo log daemon giả.
4. Sau khi hack xong thì đừng nổ smilie

cái miệng hại cái thân. Nhiều khi bạn sẽ bị bắt gián tiếp thông qua một việc không đâu vào đâu lúc bạn bất cẩn, và họ sẽ có cách làm cho bạn phải thừa nhận những việc bạn đã làm, kể cả những việc bạn không làm smilie

@bolzano_1989

Tui đang nghĩ đến hướng indirect tiếp cận đến attacker. Ví dụ attacker nếu đủ khả năng thì sẽ xoá dấu vết bằng cách xoá máy ảo, trình duyệt v.v... Nhưng ở đây chúng ta chú ý là attacker còn thường xuyên vào các diễn đàn bàn về sự việc này để công bố và nghe ngóng, như vậy không lẽ mỗi lần post bài ở hva hay blogspot thì attacker (hoặc bạn của attacker) phải lặp lại hoàn toàn chu kỳ cài vm - tor - xoá vm v.v... Chưa kể theo thời gian thì sự chủ quan của con người sẽ tăng và sẽ dễ bị mắc sai lầm (to err is human) -> chỉ cần đủ kiên nhẫn, đủ thời gian góp nhặt thông tin thông qua việc đánh dấu các phát biểu liên quan đến sự việc thỉ cũng có thể thu thập khá khá thông tin. Và như vậy, chỉ cần tóm bạn của bạn của bạn của .... thì với social engineering + "physical" engineering (xem phim Mẽo, quánh 1 trận thì cái gì cũng khai smilie

) => có thể tiếp cận được.

Vì vậy, cảnh báo của conmale hay mrro không bao giờ thừa.

@bolzano_1989

mrro có nói đến evercookie => browser của attacker sẽ bị mark bằng 1 cookie đặc biệt, nên nếu attacker ghé thăm các domain mà cxx control thì cxx có thể rút ra một số lượng thông tin kha khá.

Anh conmale cũng có nói đến social engineering, tui nghĩ trong trường hợp này social engineering sẽ hữu hiệu hơn là technical solution. Bởi vậy các bạn chém gió nên chém vừa vừa thôi smilie

( xem phim Mỹ mấy ông cớm hay chơi chiêu hù mấy em giang hồ vặt rồi lượm lặt vòng vo sẽ đến trùm )

@hanam001

bạn nên kiếm sách về compiler và nguyên lý của ngôn ngữ lập trình để hiếu cách con cpu xử lý 1 function như thế nào.

@.lht.
ý bạn nói là http://code.google.com/p/naxsi/ ?

Ý tưởng whitelisting url pattern để chặn các abnormal request cũng khá hay, tuy nhiên việc maintain có lẽ là không dễ khi web app được cập nhật thường xuyên. Tui cũng đang theo dõi coi độ phổ biến của naxsi để lúc nào đó dùng thử.

@mrro
Xin hỏi gửi cho bạn thông qua email nào? Cảm ơn bạn.

kiểm tra application server phía sau nginx đi bạn.

1. Cách ly server và đưa vào môi trường riêng để forensic
2. Dựng maintenance server (@baothu)
3. Trong khi chưa tìm ra why, when, how thì nên rebuild server từ đầu, không restored từ backup
4. Press release: sorry khách hàng, tự nhận lỗi, thông báo tình trạng đang điều tra, điếu đóm báo chí (ở VN phải vậy) PR của Cty hơi bị mệt a
5. Bây giờ đến bước forensic:
5.1 đọc log. Hệ thống có central log server + lưu hash integrity thường xuyên + backup log thường xuyên => chúc mừng, nếu để log trên chính server đó thì chia buồn
5.2 đọc log firewall, ids&ips và packet dump server để xem traffic vào ra server như thế nào
5.3 live memory dump qua 1 máy khác và dùng tool để xem các process nào đang chạy, các file handle nào đang open và các network connection như thế nào
5.4 tắt server, gỡ disk và scan toàn bộ disk kiếm coi có gì nữa không
6. Trả lời được when => restore từ backup trước đó
Trả lời được how => patch, fix và update system & network
Trả lời được why => sửa policy, process, company image
Trả lời được who => call 113
7. Xong hết nên có press release
8. Share kinh nghiêm trên HVA smilie

hoặc cộng đồng chuyên gia để mọi người cùng học hỏi (như apache đã từng làm).

@soidamientrung

bạn đang ở runlevel 3, tức là đang chạy console => không có giao diện đồ hoạ X.

@ptri85
1000 connections đến server có nhiều loại, static và dynamic, static có thể serve trực tiếp từ nginx, chỉ forward dynamic đến apache -> giảm tải. chưa kể reverse proxy có thể gửi đến nhiều backend server -> load balancing (clustering)

nginx handle connections, apache detect anomaly (modsec), app server sau cùng (php-fgci v.v...)

@Ikut3
modsec + core rule set cấu hình hoạt động dạng anomaly score, nghĩa là mỗi lần có alert sẽ có một số điểm nhất định được cộng dồn lại. Sau khi điểm tích luỹ lớn hơn biên độ đặt ra thì lúc đó các rule trong modsecurity_crs_60_correlation.conf mới thực sự ghi log.

Kết hợp với ossec config dạng "nếu xxx match in yyy second" thì sẽ đạt được điều mà @jerrykul muốn.

@myquartz

Tui đã thử modsec với server cùi 128M ram, chạy chậm nhưng vẫn được. snort thì đúng là đòi hỏi resource cao hơn. modsec feeds log cho ossec để tự động cài iptables thì sẽ hạn chế được khá khá các request tự động -> giảm tải đáng kể lên server chứ?

@myquartz

Thắc mắc sao không dùng modsecurity, hoặc nếu được thì tương luôn cái snort

@vuquangkha

Trên windows bạn cài cygwin có openssh server, hoặc là bạn cài CopSSH sẽ có SSH server

bạn search tài liệu về pam_pkcs11

Nôm na như sau:

- PAM dùng để xác thực user log vào hệ thống
- pam_pkcs11 là module của PAM để yêu cầu xác thực thông qua lib pkcs11
- lib pkcs11 là library dùng để giao tiếp với các thiết bị thẻ an ninh (hoặc usb token) có chứa pair public key/private key.

Như vậy bạn sẽ cần: pam_pkcs11, driver & library của nhà cung cấp token/smartcard có hỗ trợ PKCS11.

@mrro

Tui cũng có đăng ký tham dự, hy vọng sẽ có dịp được trau dồi kiến thức thêm với mrro.