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: quangteospk  XML
Profile for quangteospk Messages posted by quangteospk [ number of posts not being displayed on this page: 0 ]
 
Hi mọi người

Mình có nhiều web server chạy nginx + php-fpm (web app của mình là php+mysql), phía trước mình có một proxy để đẩy vào các web node, db nằm trên một node khác

Vấn đề là web server mình cũng có cấu hình khá mạnh, RAM tối thiểu 16GB, CPU thì 1 vài con E3 1230, vài con E5-2620. Khi user của mình vào một url dạng http://abc.xyz/hvaonline (page này có cache bằng memcache) nhưng traffic tăng chỉ tầm gấp đôi, gấp 3 là bị 502 bad gateway liền

Mình có theo dõi trạng thái server thì thấy RAM sử dụng rất ít, tầm 8GB nhưng CPU thì tăng khá cao, đây là một đoạn mình ngắt ra

Code:
$ vmstat 2 20
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
37 3 62768 369728 329080 6315536 0 0 0 6 0 0 8 0 92 0 0
40 0 62768 430356 329080 6315420 0 0 0 86 27305 9211 96 3 1 0 0
37 0 62768 426024 329080 6315428 0 0 0 0 24632 6733 98 2 0 0 0
38 1 62768 414368 329080 6315436 0 0 0 8 25024 6717 98 2 0 0 0
31 0 62768 373828 329084 6315440 0 0 0 62 24578 6477 97 2 1 0 0
33 0 62768 404016 329084 6315444 0 0 0 348 25252 7493 95 2 2 1 0
34 0 62768 401508 329088 6315560 0 0 0 46 25392 7085 97 2 1 0 0
32 0 62768 400996 329088 6315576 0 0 0 0 25860 7565 97 2 1 0 0
33 0 62768 385920 329088 6315588 0 0 0 62 25969 7512 96 2 2 0 0
38 0 62768 375628 329092 6315596 0 0 0 62 25362 6995 97 2 1 0 0
37 0 62768 319960 329092 6315704 0 0 0 2 24897 6506 98 2 0 0 0
37 0 62768 355300 329092 6315664 0 0 0 0 26884 8337 95 2 2 1 0
34 3 62768 353408 329092 6315704 0 0 0 116 30260 11883 91 2 5 2 0


Và page này cũng không xử lí gì với phía Database

Nhờ mọi người tư vấn dùm mình có thể làm gì để tuning tình trạng này, cảm ơn mọi người
Namespace là gì thì tớ cũng ko rõ, nhưng tớ có đọc qua Docker nên trả lời vài ý

Docker thì thật sự tin tức về nó chỉ gần 1-2 tháng đây mới nhiều, tràn ngập twitter, hacker-news thế nên tụi Tây nó tung hô nhiều mà VietNam mình ít nhắc tới chắc là vì ... mới quá, chả ai biết

Mình chốt được vài ý (theo mình tìm hiểu đc ) về Docker như sau:

Nếu bạn muốn build một môi trường mới độc lập và nhanh thì bạn thường làm gì? Ví dụ mình tạo một máy ảo VM và đóng gói nó lại, ai xài thì copy cho, nhưng vấn đề là VM thì nặng và tốn tài nguyên

Docker nó giúp bạn tạo một môi trường linh động và độc lập nhưng lại tiêu tốn ít tài nguyên, tại sao nó lại tiêu tốn ít tài nguyên bạn đọc về LXC - Linux Containers, Chroot, Jail sẽ hiểu (tất nhiên cũng có ưu, nhược điểm)

Nó giải quyết bài toán vận hành-ảo hóa (tôi muốn build ngay 1 web-node trong một thời gian ngắn nhất) h

Giải quyết bài toán vận hành (môi trường dev tới production) -> đóng gói, chia sẻ, cập nhật

Host bạn xài OS gì, sao ko vào tự kiểm tra, còn có khả năng ssh hay remote desktop không? mà có vẻ bên đó thiếu trách nhiệm nhỉ, quăng cho cái đó thì cũng thua không biết là cái gì?
Hưm, thời gian gần đây đúng là HVA có đi xuống, một phần cá nhân mình nghĩ là "sai lầm" khi chuyển thành một group trên Facebook (để đến việc hỏi con chuột bị hư cũng vào đó hỏi).

Mình thì ko thấy trên diễn đàn có bài mới nào về việc share link cả, HVA đi xuống là do các bài viết hay giảm đi nhiều thôi. Nhưng đó là tất yếu, đành chấp nhận.

Facebook đăng ký cũng dễ, lại tiện lợi vì vừa kết bạn, chat chit bây giờ lại có thể vào HVA, thành ra không còn cái cảm giác `khó khăn` khi vào HVA nữa, cũng ko còn cái cảm giác ngồi viết một comment dài, xóa tới xóa lui rồi suy nghĩ, rồi phản biện nữa. Facebook đơn giản, comment vài chữ, lại có like, cái gì cũng tiện. haizzz
Dùng mỗi cái minimum 300MB là đc rồi, cài thêm thì cứ yum thôi.
Bạn dùng thử nginx đi, đơn giản, dễ config, chịu tải cũng tốt hơn, nginx+php-fpm rồi dùng ab benchmark thử smilie
Đừng dùng nhiều màu sắc khi viết bài như vậy:

Câu hỏi của bạn còn tùy vào nhiều yếu tố bạn nên cung cấp các thông tin như:

Website của bạn mã nguồn gì, VPS chạy OS gì, chịu tải bao nhiêu thì cần phải load-test mới biết đc
Mình thấy có gì đó không đúng ở cách tính chịu tải dựa trên bandwidth thì phải.

Ví dụng mình dùng pingdom-tool để đo thử trang vnexpress, page size vào home-page là 3.9MB.

Giải dụ vnexpress thuê bw là 1Gbps (khá cao), tương đương 128 Megabyte/s vậy tính ra với băng thông đó, chưa tính mức độ chịu tải về hardware thì chỉ với xấp xỉ 33 req là hết băng thông. Không biết có gì sai ở đây không nhỉ?

Còn tùy server của bạn chạy service gì chứ, btw nhìn như web service, nguyên cái đám IP dưới 66.171 dòm như đám bot của Google vậy nhỉ
Tham khảo: /hvaonline/posts/list/37620.html
Có vẻ như nguyên nhân là mình dùng gói php trên repo remi, gói này có vấn đề vì khi mình build lại bằng tay từ source thì ko gặp nữa
Mình setup php, php-fpm từ repo remi.

Cấu hình server của mình là: 4GB RAM, CPU 2 core, VPS

Config fpm là

Code:
listen = /var/run/php-fpm/www.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0660
user = nginx
group = nginx
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 10
pm.max_requests = 200
slowlog = /var/log/php-fpm/www-slow.log


Tuy nhiên rất hay bị mất connect, check log thig thấy như thế này.

Code:
[pool www] child 15556 exited with code 1 after 752.796762 seconds from start


Bạn nào biết cách giải quyết, xin chỉ mình với smilie
Bạn phải hiều một điều rằng muốn làm ngập lụt băng thông (1 trong các dạng tấn công từ chối dịch vụ) thì băng thông mạng của bạn cũng phải tương đương với băng thông mạng của VPS.

Tình trạng của bạn là do bạn flush một số lượng gói tin + kích thước vượt mức cho phép đối với mạng của bạn, dẫn đến tình huống mạng của bạn `chết trước`, nên đã chết thì ko gửi gói tin ra ngoài đc => VPS vẫn sống bt.
Câu trả lời của bạn tạm chấp nhận được dù nó có vài điểm chưa chính xác.

Snort có hai cách chính để detect một mối nguy hại

1. Phát hiện dựa trên sự bất thường (anomaly based ID) (thực ra cái bạn nói protocol cũng chính là thằng này). Cái này đơn giản hiểu là cái gì không bình thường -> bất thường. Vậy định nghĩa như thế nào là bất thường -> không theo chuẩn, ko theo rfc, ko theo protocol.

Ví dụ, gói tin ICMP có kích thước 65.535 bytes là bất thường, TCP Handshake req đầu tiên là cờ FIN, RST gì đó là bất thường.

2. Phát hiện dựa trên mẫu (misue/sign) hiểu đơn giản là tôi có một mẫu, cái gì giống với mẫu thì cảnh báo

Ví du: Nếu có chiếc xe nào màu đỏ đi qua cách cổng thì chuông reo

Ở đây `xe màu đỏ` là dấu hiệu dùng để nhận biết.

Nhận diện dựa theo pp này còn có thể chia làm 2 loại nhỏ

- Theo biểu thức, theo mẫu (như ví dụ trên)
- Dựa theo phân tích chuyển trạng thái (ví dụ đúng theo mẫu là a -> b -> c, bạn phát hiện nó lại là a -> b -> c, sai, cảnh báo)

Còn về câu số 2, bạn đã biết dấu hiệu là gói tin đó quá lớn thì coi như biết dấu hiệu của kiểu tấn công đó rồi, tương tự với các kiểu tấn công khác, để viết rule thì học cách viết từ đây http://manual.snort.org/node27.html


Trong thực tế thì Snort cung cấp cho bạn một bộ rule miễn phí có giới hạn, và nhiều rule hơn nếu bạn trả tiền, ngoài ra còn nhiều chỗ khác cũng có thể cung cấp rule cho bạn nhưng Snort cũng như những nơi đó không đảm bảo cho bạn là nếu bạn có bộ rule đó thì có thể chặn tất cả các loại tấn công.

Mỗi môi trường, hệ thống sẽ gặp những kiểu tấn công khác nhau, hình thức khác nhau, nhiệm vụ của bạn là tìm cách, học cách phân tích và viết rule, viết rồi điều chỉnh, điều chỉnh rồi lại phân tích. Đó là các bước để bạn phân tích và xây dựng một hệ thống IDS

Theo thông tìn ACB, Từ 19h ngày 06/6 - 24h ngày 08/6/2014 họ bảo trì hệ thống Core Banking, khả năng là hệ thống chưa recover lại được chứ chẳng DoS điếc gì cả.
Mục đích của bạn khi sử dụng Cain & Abel là để làm gì?
Với bài viết này bạn có thể bị "mất vé" tham dự hvaonline và bị move vào Trash đấy
Bạn thử đọc quyển sách của bạn và trả lời vài câu thử nhé.

1. Có mấy phương pháp để Snort xác định một request là "nguy hai" hay bình thường

2. Giải thích một trường đơn giản là Ping of Death (loại tấn công này ko còn tác dụng với các OS sau này) so với Ping bt và viết một rule để detect các request PoD.
Hình như bồ chưa đọc một chút xíu gì thì phải, kiếm quyền sách nào về Snort đọc nhé, có đầy đủ câu trả lời trong đó rồi.
Mình có vấn đề cần nhờ mọi người tư vấn:

Mình có một ứng dụng cho phép user upload một số định dang file nhất định (pdf, epub). Mình sử dụng thư viện Dropzone.js cho việc upload file.

Hiện tại server mình chạy nginx, php-fpm, và mình cũng tách thư mục lưu trữ các file này ra một subdoman khác dạng static.xxx.vn và lưu trữ ở một thư mục khác với document-root của frontend. Hiện mình đang có vài thắc mắc.

1. static của mình list file ra dạng mirror, có nên làm như thế không?

2. upload mình hầu như ko limit file size, vì muốn user thỏai mái trong việc upload -> có nên làm thế ko hay nên giới hạn để bảo vệ server của mình

3. Khả năng mình bị tấn công bằng cách POST hoặc tấn công vào chính chỗ upload (up nhiều file, file siêu nặng) làm hệ thống của mình treo thì có cách gì để phòng ngừa và ngăn chặn hay không. Theo mình thấy nginx có module limit speed/IP ko biết có khả thi không.

Nhờ mọi người tư vấn dùm
Nếu vấn đề là quá lười thì xin hãy tin tưởng 1 điều là bạn chẳng thể làm được bất cứ thứ gì chứ ko chỉ riêng ngành bảo mật.


em muốn đi theo bảo mật ạ , Nhưng hiện giờ em chưa biết gì về nó
nói thật em học 1 trường cntt thì chỉ học để cho có cái bằng thôi, em toàn nhờ người đi học
chứ chẳng học hành gì! giờ em muốn mình phải thực sự học và làm được việc
 

Đến việc học những thứ cơ bản (nhưng cực kỳ cần thiết) mà bạn còn ko học hành tới nơi tới chốn mà vẫn còn nghĩ tới việc học bảo mật thì thật ảo tưởng, hình như bạn muốn học cách "tấn công" hơn là "bảo mật" thì phải.
@StartGhost: Thực ra lúc đầu em nghĩ việc hash ở client mới là chính xác (lúc đầu nghĩ là chỉ cần hash ở client hoặc server thôi). Vì nghĩ nếu chỉ
hash ở server thì password truyền đi trên đường truyền cũng đã là ở dạng plaintext rồi.

Tuy nhiên theo em nghĩ nếu hash ở client sẽ gặp 1 số vấn đề như sau:

- Hash bằng JS thì cũng chỉ làm đc cái việc đó là attracker ko thể thấy password dễ dàng, về bản chất attracker sniff đc password
đã hash thì vẫn có thể edit JS (remove hash func) và submit đi bình thường.
- Không phải trình duyệt nào cũng hỗ trợ JS, chưa kể nhiều người tắt JS đi vì mục đích an toàn.

Còn việc hash ở client, nghĩa là trên server phải lưu một chuỗi là hash(hash(password) đúng ko anh? (tạm bỏ qua salt) cho đơn giản,
em ko nhớ chính xác nhưng hình như việc hash 2 lần một chuỗi không được khuyến khích thì phải.

Hiện nay có SSL thì ko nói, nhưng em vẫn tò mò trước đây ko có thì coi như ngta chấp nhận sự rủi ro? Và theo quan điểm của cá nhân anh, đối
với các website thông thường ko có SSL làm sao để user có thể tự bảo vệ chính mình (nhiều ng có thói quen dùng chung user/pass và truy cập wifi public tự do)
E rằng là sao nhỉ, sao bạn ko thử lookup domain đó và gửi kết quả lên đây:

Cấu hình của bạn post thiếu file phân giải nghịch rồi. Thêm nữa trong cấu hình của bạn có đoạn
Code:
forwarders {8.8.8.8;8.8.4.4;};


Nghĩa là khi các máy client của bạn tìm tới 192.168.1.5 để phân giải, nếu ko tìm thấy nó sẽ nhờ một DNS server khác ở bên ngoài tìm kiếm dùm, ở đây là DNS của Google. Thế nên có thể nó trả về một ip public
Giả sử một website ko có SSL, vậy cơ chế nào để người dùng đảm bảo rằng password của tôi đi trên đường truyền không bị sniff.

Các mã nguồn mở như vBB, Xenforo mình thấy việc băm password đều thực hiện ở phía server, nghĩa là password truyền đi từ Client tới Server là ở dạng plaintext. Vậy với hầu hết các website thì ko phải website nào cũng đủ chi phí để mua SSL -> chấp nhận rủi ro cho người dùng?

Mình có biết SRP protocol, nhưng đọc một số bài thì giao thức này khá cũ, ra đời năm 1997, và cũng chẳng ai dùng cả. Vậy câu hỏi là trước khi SSL ra đời, ngta làm cách nào để bảo vệ password truyền đi, và hiện tại, nếu ko thể mua SSL thì làm sao để bảo vệ password truyền đi.
Mình nghĩ là Socket 1 thì chưa nói lên được điều gì. Mình từng bị lỗi RAM như thế này

Code:
mc0: csrow1:[color=red] CPU_SrcID#0_Channel#1_DIMM#0:[/color] 1 Corrected Errors
sbridge: HANDLING MCE MEMORY ERROR
CPU 0: Machine Check Exception: 0 Bank 5: 8c00004000010091
TSC 0 ADDR 223cabac0 MISC 2040282886 PROCESSOR 0:206d7 TIME 1397173447 SOCKET 0 APIC 0
EDAC MC0: CE row 1, channel 0, label "CPU_SrcID#0_Channel#1_DIMM#0": 1 Unknown error(s): memory read on FATAL area : cpu=0 Err=0001:0091 (ch=1), addr = 0x223cabac0 => socket=0, Channel=1(mask=2), rank=1

Thì mình cũng chỉ dám phỏng đoán là thanh có index = 0 (tức thanh số 1) của rãnh đầu tiên => cũng chỉ là phỏng đoán thôi.

Mình có làm việc với một số nhà cung cấp server thì thường khi mình báo lỗi và ko thể xác định đc thanh nào lỗi họ thưởng đổi cho mình cả 4 thanh luôn. Nên mình nghĩ ko có vấn đề gì khi bạn ko thể xác định thanh nào lỗi, chỉ hơi phiền là bạn ở tỉnh thôi.
Lỗi này bồ search trên stackoverflow hoặc serverfault có rất nhiều kết quả. Nguyên nhân là PHP giới hạn memory, có thể form submit của bồ có quá nhiều Object dẫn đến việc load tốn nhiều memory, bồ chỉ cần tăng giá trị
Code:
memory_limit = 256M

trong php.ini thêm là được, nếu vẫn thiếu thì tăng thêm nữa, tuy nhiên bạn nên xem xét việc tăng quá cao giá trị này, tìm hiểu xem tại sao PHP lại ngốn nhiều RAM đến như vậy.
Tốt nhất nếu bạn bị tình trạng trên (server bị treo), và nghi ngờ lỗi phần cứng thì nên liên hệ với nhà cung cấp để họ kiểm tra và đổi phần cứng cho bạn, đừng có tìm hiểu làm server bị down-time
Nhiều khả năng họ chỉ cho phép các truy cập vào trang login của họ từ một số IP nhất định (ví dụ IP từ Office của họ) - Mục đích ngăn ngừa các rủi ro về bảo mật. Khả năng trang trên là trang báo và khách hàng hay user thường ko cần login, chức năng login chỉ cần cho người post bài nên ko nhất thiết phải cho bên ngoài đăng nhập.
Hi all,

Hệ thống bên mình ở mức nhỏ, mình muốn audit một số vấn đề về security cho hệ thống như chưa biết bắt đầu như thế nào, Mục tiêu là cần một list những thứ cần làm và tiêu chuẩn để đánh giá process đó pass hay fail. Không biết trên HVA có ai có kinh nghiệm hoặc tài liệu về vấn đề này có teher chia sẻ giúp mình với.

Hệ thống bên mình chủ yếu là web app, tất cả đều là Linux. Mình có xem qua checklist để audit security của https://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents nhưng chỉ nói về Web App, mình cần ở mức thấp hơn bao gồm Hardward, OS, base-service (ssh, telnet, vpn...)

Cám ơn mọi người nhiều
Nguyên tắc rất đơn giản của Snort, so sánh các đặc điểm về gói tin khi sử dụng DosHTTP và các gói tin thông thường.

Viết rule dựa trên những điểm khác biệt và bất thường đó, add vô snort, và chạy lại DosHTTP để kiểm tra alert của Snort.

Sau đó có thể viết một script tự động lọc ra IP của dấu hiệu đó, đẩy vô iptables để chặn.

Ý tưởng là vậy bạn có thể thử để biết kết quả.
 
Go to Page:  2 3 4 Page 5 Last Page

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