banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: Ikut3  XML
Profile for Ikut3 Messages posted by Ikut3 [ number of posts not being displayed on this page: 17 ]
 
ngoại trừ lập trình va đức tính trung thành thì các thứ còn lại đều có cả
đặc biệt la độ quái của mình thì không chê vào đâu được.

vậy gửi cv có đc ko hả bạn
Em nghĩ các Diễn đàn công nghệ nên bắt tay nhau, truyền thông tin này đến tất cả người tham gia thời điểm hiện tại
Nếu quản lí bằng console cảm thấy phức tạp thì có thể sử dụng Webmin. Thao tác thực hiện trên giao diện Web sẽ dễ dàng hơn

Thân
- Xác nhận thời điểm tấn công gần đúng qua file log
smilie Riêng chuyện file log có thể bị làm giả, mất tính toàn vẹn thì em cũng chưa biết sẽ xử lý thế nào ?
 

- Quản lí log tập trung, log dữ liệu không trực tiếp lưu trên máy chạy dịch vụ đó mà mỗi record trong quá trình ghi nhân sẽ được đẩy qua Log Centralize.

- Tuy nhiên nếu Attacker hoàn toàn có thể làm sai log (đầu độc, gây nhiễu, v.v...) trước khi quá trình đẩy log từ máy chủ dịch vụ đến máy chủ lưu trữ log. Đối với vấn đề này, thì mình vẫn chưa có giải pháp nào, mời mọi người cho ý kiến

Ikut3 wrote:
- Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra  


KAi wrote:

Chưa thấy bạn nào đề cập đến việc "làm việc các đơn vị chức năng có liên quan" như "Trung tâm an ninh mạng", "Lực lượng cảnh sát phòng chống tội pham công nghệ cao" nhỉ smilie
 

hứ hứ smilie
Để bảo đảm bảo mật và uy tín của công ty, theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?  


1. Để đảm bảo bảo mật

- Thực hiện việc phân tách hệ thống, nhằm đóng băng hệ thống cũ và xây dựng hệ thống mới. Tránh tình trạng downtime quá lâu

- Xây dựng 1 đội nghiên cứu hoặc thuê bên thứ 3 chịu trách nhiệm truy dấu vết của attacker để lại trên máy chủ cũ.

- Liên hệ với các cơ quan chức năng có thẩm quyền để "rộng" đường trong việc điều tra

- Xây dựng các giải pháp phòng tránh tạm thời để tránh tình trạng hệ thống bị thâm nhập 1 lần nữa

- Rà soát các dịch vụ, lỗ hổng -phần mềm máy chủ đang chạy. Kiểm tra các user / pc nhân viên có thẩm quyền liên quan đến hệ thống

2. Để đảm bảo uy tín công ty

- Trỏ domain hiện tại sang một trang thông cáo, nhằm truyền tải nội dung giữa Cty và khách truy cập. Tránh tình trạng các thông tin từ các phía truyền thông tuyên truyền sai lệch

Hello pntri85

Việc so sánh performance nào cao hơn theo mình tự tay bạn làm kiểm chứng sẽ rõ nhất. Cái này có thể dùng autobench & httperf.
Về mặt performance Nginx đứng trước chịu trách nhiệm front end cho các apache request phía sau mình nghĩ cũng vẫn có mặt hạn chế nếu như các statics cache file làm việc không tốt. Ngoài ra có 1 điểm bất lợi khác mà nginx mắc phải, đó là các file configuration không có dynamically , tất cả các cấu hình ngnix nó store trong file config đó. Vậy nên việc thay đổi có tính áp dụng ngay tức thì sẽ không thể. Theo mình điều này cũng hạn chế ít nhiều đến việc apply hay change trong thời điểm run time. Đặc biệt là các hệ thống yêu cầu có tính ổn định 24/7

Bạn nghiên cứu và so sánh thêm các sản phẩm khác như lighttpd hay varnish xem sao

Thanks
Qua Vncert học ;smilie
Em thì chỉ bị hỏi đúng 1 câu

Em thích trai hay gái smilie
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ứ?
 


em nghĩ việc tạo rules iptables từ log của Application Security như mod sec quả là không nên. Vì log không phải lúc nào cũng đúng, cái này attacker hoàn toàn có thể handle để hệ thống không nhận ra, hoặc nhận ra sai. Không biết anh có giải pháp gì cho việc này ?
Trong slow query log hôm trước mình post lên có thấy rất nhiều câu query lớn hơn 10s,bạn xem lại giúp mình log slow query mình gửi lên xem thử có điểm nào bất thường ko, vì mình cũng đang phân vân ko biết là do mysql quá tải dẫn đến xử lý các câu query đó chậm hay là do bản thân các câu query đó làm cho mysql quá tải.Em cũng còn thiếu kinh nghiệm nên mong mọi người nhiệt tình giúp đỡ.Chân thành cảm ơn 


Hello, theo mình nếu như vậy bạn nên xác định kĩ hơn việc tunning lại thằng MySQL. Mình thấy có 1 số giải pháp caching các câu query thường dùng để performance nhanh hơn. Tuy nhiên cái vấn đề mà mình nghĩ là do cấu trúc, tức là hệ thống MySQL chưa được design tốt. Chỉ 8 rows mà ngốn từng ấy RAm & CPU thì quả thật bất thường ?

Thanks
@pntri85 : Sao bạn không cố kiểm tra trong MYSQL câu query nào đang chiếm nhiều tài nguyên hệ thống nhất ?
keepass 2
 
Go to Page:  First Page 1 2 3 5 6 7 Page 8 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|