Messages posted by: IT0405

Chắc là trong các tut local attack. Hiểu về HTTP Protocol đi rồi hãy nghĩ đến chuyện bypass nó smilie

sasser01052004 wrote:

Đây có phải là anh Lê Vũ (codenam3) không nhỉ

Nhận nhầm hàng rồi bố trẻ. Bố cũng hay nổ vs chém gió lắm đấy nhá.

panfider wrote:

Mình đang đọc mã nguồn của 4.3BSD gốc. Bất tiện là nó chỉ hỗ trợ cho kiến trúc VAX mà thôi.
Nên mình định tìm hiểu luôn kiến trúc này. Mình định giúp nó hỗ trợ cho x86_32 hoặc lên luôn x86_64
Mình sẽ đặt tên cho BSD của mình là eBSD( nghĩa là enterprise BSD)
Nếu ai có ý định giúp mình thì giúp cho trót.
Nếu muốn tải src nguồn thì lên google gõ "4.3BSD src"

Gió rất là mạnh rồi đó, smilie

Chào các bạn,

Hiện nay mình đang nghiên cứu về vấn đề performance tuning cho system của mình. Các system ở đây chủ yếu là webserver, sử dụng mô hình Nginx + php-fpm + mysql + memcached. OS thường dùng là CentOS 6.3. Để việc performance tuning được hiệu quả, thì đối với mình việc tính toán tài nguyên để cấu hình hệ thống là rất cần thiết. Cụ thể các thông số mình cần tính toán bao gồm :

1. Thời gian trung bình một php script được thực thi ? Có công cụ nào để testing vấn đề này không ?
2. Lượng RAM trung bình một php script được thực thi ? Làm thế nào để tính ra được ?
3. Time out trung bình của một sql query ? Có thể dựa vào đâu để tính toán ?

Cám ơn các bạn đã tham gia topic.

Chào các bạn,

Hiện nay mình đang cần một free billing system để quản lý client, khoảng vài trăm đến tầm 1000, các các Billing system này chạy trên Linux, nếu là web application thì càng good nữa. Các bạn nào từng sử dụng qua hoặc biết về các free billing system này thì vui lòng giúp đỡ mình, xin được hậu tạ sau. Mình có ngó qua một vài free billing system như BoxBilling, WHMBill,

Cám ơn các bạn đã xem topic.

=> Có khái niệm IDS layer 7?!?

Ý mình là một IDS có thể hiểu các protocol ở layer 7 ấy mà. Trong trường hợp này là HTTP.

=> Vui lòng chứng minh vì sao nó không khả thi!

Thực ra nếu dùng mod_securty thì vẫn được, về performance thì mình chưa testing trong điều kiện khó khăn như HVA nên chưa biết rõ liệu cái nào hay hơn. Nhưng nếu dùng một application chuyên dùng làm IDS như snort thì sẽ hay hơn, smilie

@ conmale :

Giả sử như mấu chốt vấn đề nhận dạng được bot và client hợp lệ được giải quyết, em có vài thắc mắc về hệ thống của HVA liên quan đến việc cấu hình trên những ông gác cổng.

1. Anh triển khai việc nhận dạng đó trên hệ thống như thế nào ? Theo em thì có lẽ trên những ông gác cổng anh sẽ dùng một IDS, có thể là Snort, vì một khi attacker đã lến đến layer 7 thì em nghĩ là cần phải có một IDS có thể hoạt động ở layer 7, nên em chỉ nghĩ đến Snort và Mod_Security. Mod_Security theo em không khả thi, nên em nghĩ là anh sẽ chọn Snort, đúng không anh ? Và nếu đúng là chọn Snort, thì việc với nhiều ông gác cổng như vậy, thì việc đồng bộ hóa và chỉnh sửa các rules anh thực hiện như thế nào, có cần thông qua một management system nào không hay là thủ công ? hoặc giả sử anh không dùng snort thì anh sẽ dùng gì vào trong trường hợp này ????

2. Tương tự với Iptable cũng vậy, sau khi IDS nhận ra được attacker, việc tiếp theo là cho attacker này vào trong black list. Với một hệ thống gồm nhiều ông gác cổng như vậy thì việc đồng bộ hóa iptables rules anh sẽ giải quyết như thế nào ? Dĩ nhiên theo em nghĩ thì nếu một trong những ông gác cổng block thì những ông khác cũng phải block theo thì mới hiệu quả. Hoặc giả sử không sử dụng iptables thì anh sẽ sử dụng gì ?

Nhiều bạn không quen với vi thì có thể dùng nano cho tiện, đơn giản hơn vi nhiều lần đối với người mới. Thực ra thì mình dùng nano cũng được vài năm rồi và đến giờ thấy vẫn phục vụ công việc bình thường, smilie

Load Balancing hay Cluster còn phụ thuộc vào trong system của bạn dùng làm gì, phục vụ cho những đối tượng nào. Ví dụ như dùng phục vụ chủ yếu cho việc đọc, thường có nguy cơ bị tấn công DDoS thì nên đầu tư vào trong cơ sỡ hạ tầng và Load Balancing, nói chung là phần front-end bởi vì cản từ ngoài và cản ngay từ đầu thì vẫn tối ưu hơn. Còn nếu ngược lại system của bạn có nhu cầu với dữ liệu động nhiều, xử lý nhiều và ít gặp những vấn đề liên quan DDoS thì nên chú trọng vào cơ sỡ hạ tầng và nên sử dụng Cluster. Còn nếu phục vụ nhiều, bị ddos nhiều, dữ liệu thay đổi nhiều thì phải làm tốt tất cả mọi thứ.

Vì trả phí thì được support nhiều hơn ??? Hoặc là system đây cần sự ổn định và nói chung là các yêu cầu CIA đều cao, cho nên cần được support nghiêm túc và bài bản. Hoặc đơn giản hơn có thể là bạn ấy đang setup một website chi sẽ file online và dùng antivirus để scan các file được member upload lên.

http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/

Cái này bạn thử qua chưa ? smilie

Compile từ source mà không change path thì cứ list ra các package rồi install gói tương ứng vào mình nghĩ sẽ không có chuyện gì xảy ra cả.

Ngoài cách của quanta thì còn cách nữa là sử dụng pecl

Muốn modem không open port để có thể bị exploit thì cứ dmz thẳng vào trong một ip nào đó ví dụ 127.0.0.1.

Sao các luận cứ nghe tào lao vậy em smilie

Muốn biết tấn công vào tầng nào trong mô hình OSI thì căn cứ vào trong đối tượng tấn công, xem nó nằm ở tầng nào. Mà muốn biết đối tượng nằm ở tầng (hoặc những tầng) nào thì dựa vào trong giao thức nó sử dụng.

Nhìn sơ qua là biết tại caching rồi. Remote toàn bộ cache trên VPS đi rồi sẽ được thôi.

Nếu dùng Kloxo hay bất kì cái server control panel nào khác thì nên install khi máy "sạch", tránh việc đụng độ này nọ với các application đã install trước. smilie

Mình thường dump các package rồi phân tích, sau đó đưa ra rules thích hợp cho snort chứ không làm ngược lại smilie

anonymousvn wrote:

Tôi nghĩ bạn nên học C trước vì C++ là nâng cấp của C nếu bạn không học C trước thì khó mà hiểu được C++.

Chứng minh đi bạn ??

C hay C++, cái nào trước cũng được. Còn trinh biên dịch thì còn tùy, trên Windows khác, trên Linux khác. Trên Linux thì người ta thường hay dùng GCC.

Author : vkholodkov
Website : www.nginxguts.com

Link : http://www.nginxguts.com/2011/01/phases/

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Nginx processes HTTP requests in multiple phases. In each of the phases there might be 0 or more handlers called. In the Nginx source code phases have specific constants associated with them. Here is a list of all phases:

1. NGX_HTTP_SERVER_REWRITE_PHASE — the phase of request URI transformation on virtual server level;
2. NGX_HTTP_FIND_CONFIG_PHASE — the phase of configuration location lookup;
3. NGX_HTTP_REWRITE_PHASE — the phase of request URI transformation on location level;
4. NGX_HTTP_POST_REWRITE_PHASE — request URI transformation post-processing phase;
5. NGX_HTTP_PREACCESS_PHASE — access restrictions check preprocessing phase;
6. NGX_HTTP_ACCESS_PHASE — access restrictions check phase;
7. NGX_HTTP_POST_ACCESS_PHASE — access restrictions check post-processing phase;
8. NGX_HTTP_TRY_FILES_PHASE — try_files directive processing phase;
9. NGX_HTTP_CONTENT_PHASE — content generation phase;
10. NGX_HTTP_LOG_PHASE — logging phase.

On every phase you can register any number of your handlers. Exceptions are following phases:

- NGX_HTTP_FIND_CONFIG_PHASE. On this phase no handlers are called, instead a search for configuration location is performed and “Location” request header is filled.
- NGX_HTTP_POST_ACCESS_PHASE. On this phase no handlers are called, only the result of access checks is interpreted and applied. The phase is required to implement directive satisfy all/any.
- NGX_HTTP_POST_REWRITE_PHASE. On this phase no handlers are called, instead request URI transformation post-processing is performed;
- NGX_HTTP_TRY_FILES_PHASE. On this phase no handlers are called, instead Nginx processes the try_files directive.

Each phase has a list of handlers associated with it. Once registered on a phase, handler can return one of the following values:

- NGX_OK — the request has been successfully processed, request must be routed to the next phase;
- NGX_DECLINED — request must be routed to the next handler;
- NGX_AGAIN, NGX_DONE — the request has been successfully processed, the request must be suspended until some event (e.g., subrequest finishes, socket becomes writeable or timeout occurs) and handler must be called again;
- NGX_ERROR, NGX_HTTP_… — an error has occurred while processing the request.

In order to register a handler you need to find the configuration of ngx_http_core_module and add the handler to one of elements of phases vector. Example:

Code:

static ngx_int_t
ngx_http_sample_module_init(ngx_conf_t *cf)
{
ngx_http_handler_pt *h;
ngx_http_core_main_conf_t *cmcf;
cmcf = ngx_http_conf_get_module_main_conf(cf, ngx_http_core_module);
h = ngx_array_push(&cmcf->phases[NGX_HTTP_CONTENT_PHASE].handlers);
if (h == NULL) {
return NGX_ERROR;
}
*h = ngx_http_sample_module_handler;
return NGX_OK;
}

The vector phases has one entry for each phase. Each entry contains a field handlers which is a vector of handlers that are registered on this phase.

Handlers are called in reverse order. Therefore the last handler registered at configuration time will be called first at runtime.

As you can see, the order of actions in request processing has nothing to do with the order of directives in configuration file. Phase handlers are called regardless of what configuration the user has specified. Hence a phase handler must be able to determine when it is applicable and return NGX_DECLINED when it is not and do it as fast as possible to avoid performance penalties.

The phase NGX_HTTP_ACCESS_PHASE calls handlers that restrict access to resources. In this phase the order in which handlers are called is determined by directive satisfy. The values, that handlers return, have additional meaning:

- NGX_OK — handler allows to access the resource specified by request URI;
- NGX_HTTP_FORBIDDEN, NGX_HTTP_UNAUTHORIZED — handler does not allow to request the resource specified by request URI.

In case of satisfy all all handlers must return NGX_OK in order to proceed with the next phase.
In case of satisfy any at least one handler must return NGX_OK in order to proceed with the next phase.

Nginx uses the phase NGX_HTTP_CONTENT_PHASE to generate a response. Whenever a location configuration of ngx_http_core_module has handler field initialized, all requests on content phase are routed to this handler. The handler that is specified by handler field is hence called content handler. When content handler is not set, request is routed to handlers of content phase in main configuration.

How to override content handler? Here is an example:

Code:

static char *
ngx_http_sample_module_command(ngx_conf_t *cf, ngx_command_t *cmd, void *conf)
{
ngx_http_core_loc_conf_t *clcf;
clcf = ngx_http_conf_get_module_loc_conf(cf, ngx_http_core_module);
clcf->handler = ngx_http_sample_handler;
return NGX_CONF_OK;
}

The content handler has following specific properties:

- It is not resumable. That is, it’s not going to be called again if it returns NGX_AGAIN or NGX_DONE. Instead the handler must change read and/or write handlers of the request;
- Each location can have it’s own dedicated content handler;
- If content handler returns NGX_DECLINED, Nginx routes request to content phase handlers.

How do you find out which phase to put your handler on?

Although this blog is not to criticize Nginx, here seems to be a bit of a problem. According to my feelings and to Igor Sysoev comments, phases are legacy from Apache. They are not as flexible for a module developer as you would expect. Clearly this point could be improved (and it will be), but for the moment here are suggestions, that you can use in order to figure out what phase you need to put your handler on:

- Your handler needs to be manageable by satisfy directive (e.g. access restriction checks) — put it on access phase;
- Your handler does resource limitations — put it on pre-access phase;
- Your handler changes URI or manipulates variables than need to be accessible in set directive or rewrites — put it on rewrite phase;
- Your handler generates content — put it on content phase, take care of the handler registration order;
- Your handler does logging — put it on logging phase;

When you should use content handlers?

What is the difference between content phase handler and content handler?

- the content phase handler is promiscuous: it is called for every request that reaches the content phase and this particular handler. The content handler is called only for those requests that reach a location with configured content handler;
- more than one content phase handler can be called per location. Only one content handler can be called per location.

A combination of these two types of handlers are employed by nginx mogilefs module for doing PUT requests:

Main location is handled by a content phase handler. This handler has 3 stages that correspond to create_open command, storing the resource on storage node and create_close command. On each stage content phase handler does a subrequest. When subrequest finishes, it wakes up the main content phase handler. In case of create_open and create_close commands subrequest is routed to a hidden location that has a content handler set up in it. This handler implements communication with MogileFS tracker using upstream module.

Nguyên tắc này em nghĩ dễ làm cho người đọc nghĩ rằng sẽ build một đống rồi không dùng cái gì sẽ turn off cái đó. Điều này không đúng chút nào và cũng không nên xây dựng hệ thống theo nguyên tắc trên.

Bạn có thể phân tích rõ hơn nguyên tắc thứ 2 mà anh ấy đề cập không đúng ở chỗ nào và tại sao được không, REASON ?

Mình không nói nguyên tắc của anh conmale là sai, mình chỉ nói rằng nguyên tắc đó có thể làm người đọc lầm tưởng rằng ý của anh conmale là xây dựng một hệ thống theo kiểu all-in-one, rồi sau đó tắt những thứ không sài. Việc này sẽ vừa tốn thời gian và vừa sót đối tượng. Theo mình security không phải chỉ nằm trong phạm vi quản lý hệ thống mà bao gồm cả việc thiết kế và xây dựng. Đừng xây dựng xong một hệ thống rồi mới nghĩ đến security mà phải nghĩ đến security ngay trong lúc thiết kế và xây dựng.

Khi bạn cho rằng "chỉ install những thứ chắc chắn là sẽ dùng", mình nghĩ là còn sót 1 vế vì những thứ này sẽ cung cấp những DỊCH VỤ đảm nhận nhiều chức năng khác nhau - tuỳ vào đối tượng cụ thể nhé

"những thứ" ở trên có thể hiểu là "dịch vụ" hoặc là "công cụ". Mình chỉ install những dịch vụ mình sẽ triển khai (webserver : nginx, mail-server: postfix, ... etc), những công cụ mình sẽ sử dụng trong lúc làm việc (htop, ...). Ngoài ra thì không install gì thêm.

2. If not used, turn off (nếu không dùng, tắt bỏ).

Nguyên tắc này em nghĩ dễ làm cho người đọc nghĩ rằng sẽ build một đống rồi không dùng cái gì sẽ turn off cái đó. Điều này không đúng chút nào và cũng không nên xây dựng hệ thống theo nguyên tắc trên.

Em thường xây dựng hệ thống của em từ “blank page”, có nghĩa là từ không có gì, và xây dựng bám sát vào trong nhu cầu cụ thể. Không dùng cái gì thì không install, chỉ install những thứ chắc chắn là sẽ dùng. Dĩ nhiên việc này sẽ mất sức nhiều hơn nhưng bù lại việc quản lý hệ thống sẽ dễ dàng hơn vì người xây dựng sẽ có sự am hiểu về những gì chạy bên trong hệ thống của mình. Điểm yếu duy nhất của cách này có lẽ là việc build cứng một giải pháp thế này nếu cần mở rộng thì thường phải đập ra xây dựng lại (mất sức, mất tiền, mất thời gian), và công việc này chỉ phù hợp cho những người giàu kinh nghiệm. Tuy nhiên nếu xét về bảo mật thì sẽ mang lại hiệu quả rất cao.

Nói chung thì em nghĩ điểm thứ 2, nên chuyển thành : Xây dựng từ blank page sẽ phù hợp hơn.

@ Ikut3 : Nhưng trong topic này Nginx được chủ topic nhắc đến chắc chỉ dùng có mỗi chức năng caching thôi. smilie

Chống DDoS không nhất thiết phải có reverse proxy. Cái reverse proxy chỉ có tác dụng cache static pages, ngoài ra không có tác dụng gì nữa. Nếu reverse proxy cho một lượng lớn request ập vào mà webserver bên trong không chịu nổi thì cũng crash.

Chống DDoS không phụ thuộc nhiều vào webserver mà phụ thuộc vào những biện pháp cản lọc, trãi dài từ layer 3 lên 7. Apache có một điểm lợi là có mod_security, cái hay của mod_security có nhiều topic đề cập rồi.

Nói chung là bồ nên nghiên cứu về webserver, cách vận hành, cách nó handle một request rồi hãy nghĩ đến chuyện chống DDoS, đánh giá, ... etc.

+ Tối thiểu là 5.000 user.
+ Kinh phí thì không giới hạn, max khoảng 3.000$ (không tính phần cứng). Nhưng ưu tiên dùng các giải pháp free.
+ Nhất thiết phải là FreeBSD.

linet wrote:

Các chú mới ra trường hay có ảo tưởng về lương lậu. Còn không so sánh được với ngành khác đâu, cứ thử ra ngoài làm ăn buôn bán sẽ rõ, mới thấy quý cái nghề sysadmin này.

Mình thì sau khi ra làm riêng không dám mơ về system admin nữa smilie

Hiện nay mình đang xây dựng một Mailserver trên nền FreeBSD, yêu cầu của Mailserver là chịu tải được càng nhiều càng tốt. Làm sao để đáp ứng được lượng người dùng càng nhiều thì càng tốt. Server chỉ chạy Mailserver, không chạy Web hay bất kì services nào khác.

Hiện nay mình cũng đang hình thành nhiều giải pháp nhưng chưa có kinh nghiệm nhiều nên không đánh giá các giải pháp đó tốt được. Nên hy vọng mọi người có kinh nghiệm trong vấn đề này hãy chia sẽ kinh nghiệm.

Cám ơn các bạn đã đọc topic smilie

Dùng Slackware đi bạn. Slackware mới đúng là distro Linux tốt nhất cho hacker. Hoặc là dùng Gentoo cũng được, smilie

Mình nói thể này, dữ liệu ở đây giống như thể xác. Phương thức là linh hồn. Nếu bạn nói hướng đối tượng chỉ cần dữu liệu không nhất thiết phải có phương thức thì đó là một sai lầm lớn. Việc này chẳng khác gì một thân xác bất động. Phương thức giúp ta tương tác với dữu liệu một cách an toàn và linh hoạt. Phương thức và dữ liệu đều thật sự cần, và thật sự quan trọng.

Bạn ấy nói đúng mà, đôi khi không cần phương thức, cũng giống như đôi khi người ta cần cái xác hơn là một con người hoàn chỉnh. Cái hay của IT là chúng ta có thể tạo ra những cái ... thậm chí chẳng để làm gì smilie

Ví dụ tạo ra một đối tượng không có phương thức.

Trong các doanh nghiệp nhỏ, thường System Administrator, Network Administrator, System Engineer và Network Engineer là cùng một người hoặc nhóm người. Công việc thường làm của họ bao gồm : Compile/Install Software, Start/Stop/Restart/Reload Service, Debug/Audit Service, Monitoring, Security, Troubleshoot, Maintain, Design, Planning and Development, ... etc. Nói chung là kiểu All-in-one. Trong trường hợp này thì Security có nghĩa là Security cho tất cả những thứ sẽ làm việc, bao gồm system, service, production, ...

Còn trong các doanh nghiệp lớn có sự phân chia rõ ràng thì các công việc trên cũng sẽ được chia ra rất rõ ràng phù hợp với từng vị trí.

Ví dụ một anh System Administrator thì công việc thường thấy bao gồm : Compile/Install Software, Start/Stop/Restart/Reload Service, Debug/Audit Service, Monitoring, Troubleshoot, Maintain, ... là xong. Còn các công việc như Design, Planning and Development, ... là của System Engineer.

Cho nên trong mức của System Administrator thì họ chỉ quan tâm đến security cho system, services, ... xong chuyện. Còn System Engineer thì sẽ quan tâm đến security cho các mô hình thiết kế của họ, ví dụ việc áp dụng các giải pháp thế nào thì sẽ an toàn nhất, khả năng chịu tải tốt nhất, giải pháp nào bền lâu nhất, ít tốn kém nhất (còn áp dụng cụ thể thì System Administrator lo).

Nói tóm lại, nói đến Security thì phải nói luôn là trong môi trường như thế nào, vị trí công việc như thế nào. Chứ mang Security ra so lung tung thì rất khó so sánh.