Messages posted by: lQ

hi,

- mình phải lấy log đến mức có thể chứ.

- sau khi lấy hết rồi, thì nên tài liệu lại toàn bộ tất cả log mà mình có. Sẽ có cái ban đầu chỉ là lưu trữ và 1 chút thống kê sơ bộ như internet banking web access log; nhưng cũng những thông tin đó sau này sẽ được dùng để làm những việc khác như đánh giá xu hướng sử dụng của khách hàng, xác định các yêu cầu tiêu tốn tài nguyên, phòng chống DDoS... Có những dạng log bắt buộc phải có xử lý đầy đủ như log ARP collision của firewall. Đó là cách làm việc (+phân tích) của anh đ/v log, ko có procedure nào cả.

Chào các bạn,

file đính kèm là nội dung trình bày của mình tại ĐH Khoa học tự nhiên hôm nay 29/04/2011. Gửi các bạn tìm hiểu và thưởng lãm.

Mục tiêu của slide này là:
- Giới thiệu về log + log management.
- Mô tả 1 kiến trúc triển khai log tập trung dựa trên syslog. Mình hi vọng các bạn có thể nhanh chóng xây dựng 1 hệ thống log mức cơ bản.

Chúc các bạn thực hiện thành công và tìm thấy nhiều điều thú vị trong slide này.

protectHat wrote:

TQN wrote:

Không chắc, có thể máy của cậu protectHat dính virus thì sao ?

Em có thử cả với máy win và 1 máy Ubuntu rồi mới hỏi mà anh? Tại vì sợ lỡ như mạng bị dính virus mà nó chèn cái iframe lên đầu trang như vậy mà báo cho bên tuổi trẻ thì phiền nên em mới hỏi mọi người

PS: Hôm nay vào lại đúng là đã được gỡ ra

mình cũng từng gặp tình trạng tương tự như vầy. Có điều nguyên nhân là do 1 máy tính trong cùng mạng của mình bị nhiễm virus dạng ARP poisoning. Tất cả máy tính cùng mạng khi đó đều bị dính iframe khi vào bất kỳ website nào.

thử nghiên cứu IronBee xem sao.

https://www.ironbee.com

vikjava wrote:

Dear anh,

- Em đã restart zimbra rùi, khi có syslog-ng thì trong /var/log/zimbra.log ( MTA,spamfilter...)không có thông tin gì cả. Các log khác của zimbra vẫn bình thường

-Các log về sshd, cron,kernel vẫn bình thường.

- Trước mắt em chỉ cần thu thập các critical log để phục vụ vu PCI DSS

Như mô tả thì em đã cấu hình syslog-ng đúng 1 phần. smilie

Em cần test để đảm bảo zimbra lưu đầy đủ log như sau:

destination d_everything { file("/var/log/everything.log"); };
log { source(src); destination(d_everything); };

Trong đó src là source đã khai báo unix-dgram("/dev/log"); và file("/proc/kmsg");. Còn lệnh log thì không sử dụng filter. Sau đó restart/reload. Nếu file everything.log có cả nội dung của zimbra.log trước đây, thì nghĩa là zimbra đã *đẩy* log đàng hoàng; và em cấu hình syslog-ng cho zimbra chưa chính xác (syslog-ng chưa chọn đúng chỗ lưu log zimbra).

lQ wrote:

Theo anh biết thì 1 số service của zimbra ko support syslog mà chỉ lưu file như các log Pop3SSLServer, Pop3Server, btpool0... nên syslog hay syslog-ng đều ko thể nhận được log này. Còn các service khác của zimbra như postfix, amavis thì có hỗ trợ.

hi,
anh mới phát hiện syslog-ng cũng hỗ trợ lưu tập trung các file log độc lập. Cách thức như sau:

source d_log_files {
file("/path/to/abc.log follow_freq(2) flags(no-parse)); };
};

Sau đó có thể dùng destination nào đó phù hợp để lưu tập trung tại 1 thư mục (destination file) hoặc lưu sang server khác (destination udp/tcp).

vikjava wrote:

- So với nhu cầu đổ log về server log, việc cấu hình syslog-ng cho các service của zimbra hơi bị nhiêu khê và gặp nhiều trở ngại. Em đã remove syslog-ng và install lại sysklogd

- Hiện nay em muốn lấy các thông tin dưới đây để đổ vể log server, vậy syslog.conf có đáp ứng được hết không anh, cấu hình như thế nào để đáp ứng điều này ah?

Successful user login “Accepted password”, “Accepted publickey”,"session opened”

Failed user login “authentication failure”, “failed password”

User log-off “session closed”

User account change or deletion “password changed”,“new user”,“delete user”

Sudo actions “sudo: … COMMAND=…” “FAILED su”

Service failure “failed” or “failure”

Em chưa trả lời 02 câu hỏi đầu của anh.

Anh thấy cấu hình syslog và syslog-ng (mức cơ bản) cũng khá giống nhau. Syslog làm được gì thì syslog-ng làm được điều đó. Em cho xem nội dung syslog-ng.conf.

Đã tập trung log rồi thì tập trung toàn bộ.

em đã thử restart zimbra chưa.

Ngoài ra syslog-ng mới có nhận được local log (sshd, cron, kernel...) hay không?

Theo anh biết thì 1 số service của zimbra ko support syslog mà chỉ lưu file như các log Pop3SSLServer, Pop3Server, btpool0... nên syslog hay syslog-ng đều ko thể nhận được log này. Còn các service khác của zimbra như postfix, amavis thì có hỗ trợ.

Dr. Anton Chuvakin có 1 bài review về cuốn sách này tại địa chỉ http://chuvakin.blogspot.com/2011/01/book-review-security-information-and.html.

Để tránh mất thời gian, tui cũng khuyên như ông Anton là ko nên đọc chương Deploy the Cisco Monitoring Analysis and Response System (MARS). Lý do là vì đám Cisco CSIRT không dùng sản phẩm của nó (MARS) mà lại dùng của hãng khác.

vikjava / Ky0shir0 đọc xong làm 1 bài review rồi chấm điểm (1-5 *) cho cuốn này nhé.

chôm user + pass của router rồi thì chôm luôn cuốn hướng dẫn sử dụng. Thế là vãi hà rồi!!!

vikjava wrote:

Hi all !

Cho mình hỏi ngoài splunk hay lucene-solr thì có những sản phẩm nào tương tự ? Bao gồm phần mềm thương mại và cả mã nguồn mở

Anh cũng thử tìm giải pháp mã mở thay thế, ngoài licene-solr mà mrro đề cập thì anh thấy có OSSIM và php-syslog-ng. OSSIM thì anh chưa thử nhưng thấy cũng có người đang dùng. php-syslog-ng thì khá yếu, chỉ để search log mà thôi, ko đủ tính năng để thay thế Splunk.

Về các bản thương mai thì anh thấy có ArcSight, LogLogic, RSA enVision, Sawmill... cùng 1 số bản thương mại khác cũng có bản giới hạn miễn phí. Nhưng nếu dữ liệu < 500 MB thì có lẽ dùng Splunk Free Version cho khoẻ.

Tui nghĩ cách tui đề xuất đơn giản và có thể xử lý tốt với nguồn DDoS lên đến 300 zombies. Bạn cứ thử rồi theo dõi so sánh performance (CPU, memory, IO, bandwidth...) trước và sau khi áp dụng xem sao.

Àh nhớ iptables có thêm thì cũng nên có *bớt* nhé smilie

.

Chạy crontab Phân tích những access log gần nhất của Apache; đứa nào request nhiều thì DROP trên iptables luôn.

sao lúc nào vikjava đăng bài cũng lôi đông á vào vậy smilie

???

chủ quan của lQ là các cty thanh toán dù sao thì cũng đơn giản hơn so với các ngân hàng. Số lượng sản phẩm dịch vụ tăng thì độ phức tạp để triển khai cũng tăng và tăng theo cấp số nhân. Và ko thể chỉ một mình security làm là xong đâu cho nên đừng đem đội security của cty này kia ra so sánh smilie

.

àh không rõ sếp của vikjava có hỏi triển khai PCI DSS thì có thu được lợi lộc gì ko nhể???

Hầu hết các hệ thống issue tracking system đều hỗ trợ tất cả yêu cầu của quanta đưa ra (cũng là của nhiều system admin) smilie

.

quanta wrote:

Chào mọi người,

Mình đang tìm một cái web-based open source đáp ứng được các nhu cầu:

- quản lý các server: IP, phiên bản hệ điều hành, CPU, RAM, ...
- quản lý các dịch vụ trên mỗi server: server nào chạy dịch vụ gì, mô tả về các dịch vụ đó, sự phụ thuộc giữa một dịch vụ chạy trên server A với một dịch vụ chạy trên server B, ...
- phân quyền cho phép developer thêm các dịch vụ (tự viết) vào và tự động gửi mail cho nhóm sysadmin biết (kiểu như request tracker)

Mình đã thử mấy cái như: OCSInventory, otrs, kwoksys, ... nhưng không đáp ứng được yêu cầu. Ai biết cái nào khác chỉ giúp mình với nhé. Cảm ơn.

hi quanta,

yêu cầu 2 và 3 của em rõ ràng là phải nhập liệu bằng tay, không thể dùng tool tự động thu thập được. Cho nên không dùng các công cụ system monitor như Zabbix/Nagios... và đúng là nên dùng request tracker nhưng phải có phần *request/issue/ticket dependencies*. Không rõ công cụ quản lý của em đã có tính năng này hay không? Anh thì thấy Redmine/trac đã có khá lâu rồi.

"qu" không được xem là phụ âm đầu, nhưng "gi" thì được, vì 02 phụ âm đầu "g" và "gi" không đồng âm - cách đọc khác nhau, trong khi mình không thấy ai định nghĩa cách đọc "phụ âm" "qu" cả. Mọi ng thấy đúng ko nhỉ?

Cái này hình như dùng startup form. Nếu đúng vậy thì giữ phím Shift khi mở file để bypass form này.

conmale wrote:

Bà con tham gia xôm tụ quá . Vẫn chưa thấy ai đề cập đến khía cạnh "risk" ở chỗ HVA forum vẫn còn tồn tại nhưng lại... chết vì nó chẳng còn giá trị và ích lợi gì cả. Cái risk này có không? và để "mitigate" nó thì cần làm gì?

Trời!!! Theo em nghĩ đây là risk nghiêm trọng nhất và cần phải ưu tiên số 1.

Mitigate thì cần:
- Tuân thủ nghiêm chỉnh nội quy diễn đàn và quy định gửi bài.
- Hạn chế tối thiểu đăng các thắc mắc đã có trả lời ở diễn đàn hoặc có nhiều hướng dẫn / trả lời trên Internet. Thay vào đó, tích cực đóng góp các bài viết dạng mở rộng một vấn đề hoặc một sản phẩm, giải pháp IT/Security.

02 khoản này cần sự tham gia của tất cả thành viên. Và cần số lượng 'nhân sự' như vầy, thì chi phí (thời gian, chi phí đào tạo hoặc tự đào tạo,...) bỏ ra là không ít, tuỳ khả năng mỗi người. Do đó mình mới khằng dịnh đây là risk nghiêm trọng nhất và ưu tiên cao nhất.

Anh conmale gừng già có khác smilie

.

Bác louis có lẽ khá rành ISMS. Nhờ bác liệt kê các bước cho đúng quy trình để hoàn tất câu 1 của anh conmale. Làm như các post nói trên, thể nào cũng đưa thiếu risk.

gamma95 wrote:

có ai giải thích được ko?

Nhóc gamma e sợ có nhiều em dùng search engines lão luyện hơn nên có thể dành phần thắng (quán quân). Do đó thủ đoạn của gamma là cắt luôn cái này cho mọi người không dễ gì có trợ giúp.

Nó là những dạng web proxy thì làm sao mà chặn cho hết. Những đứa dạng này theo anh cũng ko nhiều lắm, và để hoàn toàn tương thích FB thì hầu như phải trả phí hết. Truy cập FB theo dạng free cũng chả được bao nhiêu nội dung hoặc tính năng.

Về dạng proxy thuần tuý thường dùng squid, thì anh thấy nhiều hơn, nhưng thường không ổn định, lúc kết nối được lúc ko.

Cho nên anh nghĩ cấm ip như em vậy là đủ rồi. Lâu lâu end users mới vào FB được vài lần cũng đâu có sao smilie

.

gamma95 wrote:

nó tunnel qua ssh thì chặn thế nào được ?

công ty anh chỉ cho phép đi ra ngoài theo port 80/8080 và phải là protocol http smilie

. Cho nên tunnel theo proto ssh ở đây là bị chém liền ;-|.

@vikjava:
cụ thể họ vào bằng cách nào vậy? Và sao em phát hiện?

Abe wrote:

- Từ *đầu vào* là 10.000 IP DDoS, (sau một loạt biện pháp nghiệp vụ), đùng một cái đưa ra ngay chính sách và chạy script để lấy những IP có tần suất là 100 request/s (con số thực sự rất lớn - IMHO - ngay cả trong tâm bão). Nên mình nghĩ là trong quá trình này phải có một loạt các động tác thì mới đạt được kết quả như ý, và con số 100 req/s sẽ phải thay đổi liên tục và liên tục được làm mịn thì mức độ hiệu quả mới thật sự cao.

- Như trên mình đã nói, nếu chỉ giải quyết như vậy thì mình nghĩ biểu đồ nó sẽ tương tự như thế này, vì việc làm của mình là offline chứ không phải online và tần suất chạy cronjob (như mrro nói) cũng không dày.

Abe đọc chưa kỹ bài đầu tiên của mrro rồi. Trích 1 đoạn:

Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninh mạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không mà không phải thực hiện thêm bất kỳ thao tác nào. ...

Cái hình đó cũng ... đúng, nhưng chỉ khi mình phải phân tích bằng tay, rồi cập nhật danh sách blocked ip dần dần. Nhưng đúng ra cũng không được 'nhọn nhọn' smilie

kiểu đang tăng lập tức giảm đi 1 chút, mà phải là lên cao và giữ nguyên độ cao, cho đến khi các chuyên gia cập nhật danh sách blocked ip lần đầu thì bắt đầu giảm smilie

.

để mình trả lời một số ý của LVH:

LeVuHoang wrote:

Thái cho hỏi là syslog/udp, có giải phảp syslog/tcp nào không?

Theo như tui hiểu, điều cốt lõi trong mô hình của mrro là log central và analyzer. Analyzer server sẽ tiến hành kết nối vào log central, phân tích, tổng hợp, đưa ra IPs có hơn 100 request/s rồi đưa ngược trở lại vào iptables để ngăn chặn. Những IP này có thể được unblock theo thời gian định trước.

Bài giới thiệu của mrro có phần hơi chung chung quá, mrro có thể giới thiệu kỹ hơn về server offline analyze kia không?
Cụ thể là, chặn ở tầng network và application như thế nào? Có còn chặn ở tầng nào khác hay không?

Ngoài ra, như ý tui đã nói ở phần trước, nếu 1 net cafe vài trăm users đang sử dụng. 1 user DoS site khách hàng, IP của net cafe đó sẽ được đưa vào blocked IP. Vậy tất cả các người dùng khác đều không thể truy cập được?

syslog-ng cũng đã support syslog/tcp, nhưng bản trên Linux thì có free, còn bản trên Windows thì phải trả phí. Có điều, khi nào cần đến tcp thay cho udp, hay thậm chí khi nào cần đến tcp+ssl, thì tuỳ hiện trạng và nhu cầu của mỗi doanh nghiệp. Cũng nên nhớ một số thiết bị cực kỳ quan trọng như firewalls, IDS/IPS, cũng chỉ support syslog/udp.

Nếu đã chọn syslog-ng để thu thập dữ liệu, thì cũng nên chọn agent của nó, đỡ mất công tìm hiểu phần mềm khác cho khoẻ smilie

.

Đã block trên firewall thì hiển nhiên phải có bước unblock. Nguyên tắc unblock thì cũng có nhiều lựa chọn. VD nếu như ip bị block, trong khoảng 1 tiếng, không truy cập (và hiển nhiên sau đó bị block) nữa thì gỡ khỏi danh sách block ip.

Giải pháp nào nếu triển khai, cũng sẽ có hạn chế, thậm chí khi kẻ tấn công biết được nguyên tắc của giải pháp, thì cũng sẽ tận dụng để tránh khỏi bị phát hiện và 'phán xét'. Ngược lại, việc block nhầm vào IP của khách hàng cũng hay là IP chung của khách hàng và của zombies vẫn có thể xảy ra như thường. Đành chịu khó tiếp điện thoại từ Trung tâm dịch vụ khách hàng, để gỡ IP đó khỏi danh sách, hoặc cập nhật vào whitelist. Đơn giản phải ko smilie

?