Messages posted by: BachDuongTM

Mình rất thích bài viết của bạn.

Việc chèn thêm cookie là một lựa chọn hay giúp server loại bỏ mấy bọn DDOS đáng ghét.
Tuy nhiên firewall này vẫn còn hơi yếu yếu một tý nên mình bơm thêm cho nó mạnh nhé

1. Bạn đừng cản bằng cookie mà nên cản bằng url có kèm theo session. Vì có những trường hợp cookie không toàn vẹn, trong khi url thì ít bị chỉnh sửa hơn.

3. Session không cần quá phức tạp, tuy nhiên nên áp dụng session là một loại mã hoá 1 chiều cho các biến số : thời gian + IP nguồn + url cần xem + TTL + khoá mã bí mật.

Với
- thời gian fix cứng, nếu quá 15 phút chẳng hạn thì session không có giá trị
- IP nguồn fix theo IP của client, nếu đối IP khác thì session không giá trị
- url cần xem fix theo request client, nếu đổi URL khác thì session không giá trị
- TTL tuỳ theo nhu cầu người dùng, giảm dần nếu request gọi đến liên tục trong khoảng thời gian, và tự nâng lên
- khoá mã bí mật nằm ở phía server

Cuối cùng là việc kiểm tra session này không nên dùng PHP để check, thay vì thế bạn nên cài nginx lên máy chủ linux và kiểm tra session với ngôn ngữ LUA, hoặc một dạng extension tích thẳng nginx. Ngoài ra bạn có thể lựa chọn ngôn ngữ C thuần với một số thư viện để tự mình xây dựng proxy check session.

Hơn nữa, việc check này chỉ tốt với số lựong request ở mức 100k request/s, tưong ứng với khoảng 400Mbps đường truyền. Nếu lớn hơn, e là bạn phải áp dụng một số kỹ thuật cao hơn gồm

- Tạo các kết nối nửa vời: nếu client là 1 tools ddos thuần, nó sẽ dễ bị phát hiện khi bạn cố tình kết nối nửa vời đến nó.
- Tạo các bộ điều hứong phân giải, khi client kết nối đến máy chủ, nó bị điều sang máy chủ phân tích gần nó nhất, để từ đó thống kê xem nó có phải là kẻ tình nghi không
- Áp dụng biện pháp xác thực người dùng cuối. Như là một kiểu kết hợp 2 key server và key client, trùng khớp mã thì vượt qua quá trình xác thực. Việc này nghe có vẻ tiêu tốn tài nguyên, nhưng nó rất tốt cho việc xác định nhanh đâu là Client đâu là mạng botnet tấn công, từ đó khoanh vùng ảnh hưởng

Chào bạn

1. Hosting nào cũng có log truy cập gồm IP và thời gian request
2. Từ host 4 có thể tìm ra request của host 3 => host 2 => host 1 và ra IP cuối của bạn
3. C50 là một tổ chức có thẩm quyền cao, mình không biết nhưng đoán họ có thể gửi yêu cầu các ISP về kiểm tra IP và thời gian để tìm ra cá nhân sử dụng tưong ứng. Hoặc nếu hosting đó ở nước ngoài, C50 có thể gửi yêu cầu sang Interpol để trợ giúp tìm nguồn truy cập. Họ cũng không phải là cao siêu đến mức gì cũng biết
4. Mọi truy cập internet là có lưu vết, đừng truy cập là đừng có vết. Mình có những máy chủ mà log nó ít ít nên lưu 5 năm chả xoá file nào, rảnh cần xem lại giờ nào cũng có.
5. Nhu cầu ẩn danh là có thực, đơn giản chỉ là sở thích mang tính cá nhân. Nhưng nếu bạn hy vọng rằng mình ẩn danh để làm 1 cái gì đó vi phạm pháp luật, thì rất tiếc, bên máy tính, bất kỳ thiết bị nào cũng đều có riêng rất nhiều các ID xác định còn gọi các địa chỉ, nó là riêng và duy nhất trên thế giới. Nên sớm gì thì bạn cũng bị tìm ngược ra thôi.

Tự nhiên nhớ câu xã hội phát triển theo hình xoắn ốc và ngẫm nghĩ :
1. Tù túng thông tin rồi sinh ra Internet
2. Tự do internet rồi sinh ra những kẻ nổi loạn như đám này thách thức đe doạ
3. Internet rồi lại bị kiểm soát, một kiểu tù túng internet
4. Và một mạng thông tin mới sẽ ra đời, hoạt động song song hoặc độc lập với internet smilie

Về mạng botnet này nếu 300Gbps / 5Mbps = 60.000 pc thôi. Thời đại cáp quang đến rồi, nên mức 5Mbps không tính máy chủ tham gia chắc là vừa.

Cách thức đối phó với dám botnet này theo cá nhân mình là phân vùng quốc gia lại. Ở VN thì đặt cụm máy chủ chỉ phục vụ VN, cụm US thì chỉ phuc vụ US. Chết cụm nào ráng sửa cụm ấy

Mình đã xài FTTH rồi, từ hồi mới bắt đầu có gói 20Mbps chứ không phải là 8 hay 16 Mbps.
Về tốc độ thì trong nước luôn đạt full 20 Mbps, down game võ lâm với thế giới hoàn mỹ test đường truyền hoài.

Về kết nối quốc tế thì dĩ nhiên kém hơn,được khoảng 500KB/s thôi, xài tháng dis 1,2 lần gì đó.

Kết luận là dùng cũng ổn, và cũng tùy từng vùng vì bản chất FTTH kết nối và tuyến cáp cùng với ADSL và không được đảm bảo như thuê bao riêng

http://www.muchhalasworld.com/2006/03/24/cpanel-webspace-exploit/

cPanel WebSpace Exploit

Before we begin just take a look at those two screenshots of my cPanel account. My host Frihost gives 250 MB of web-space and I made it 1.25 GB first and then took it to 2.5 GB before bringing it back down too 250 MB again...

Bài viết từ 24/03/2006

Các phiên bản linux thì file quota này owner là root vì vậy các member không có bất kỳ cơ hội gì, không hiểu vì sao Cpanel là move vào trong home của member và cho owner để có quyền đọc ghi. Mình không bình luận gì thêm về bug này.

Và cuối cùng, đề nghị bạn đừng nên lôi topic đi lung tung 1 cách không cần thiết như thế. Nếu bạn chưa nắm được topic đang bàn về vấn đề gì...bạn nên vui lòng đọc lại trang 1, quanta đã có nói rõ là topic này đang bàn về vấn đề gì.

Nếu không có thông tin gì về thời gian xử lí cũng như performance của 2 cách biên dịch php trên, bạn có thể đi một vòng google và kiểm chứng, mình chắc là có rất nhiều người có dư kinh nghiệm hơn cả bạn và mình rất nhiều cũng viết ra những bài tương tự như so sánh 2 cách biên dịch trên từ rất lâu, nhưng với tất cả những gì mọi người nói ra ở trên thực sự chưa đủ cho bạn thấy là bạn đã sai hay sao?

Tôi đề nghị bạn nên nghiên túc xem xét lại...kiến thức của mình!

mình trân trọng những ý kiến này và sẽ ghi nhớ để bổ xung lại nghiêm túc kiến thức của mình thay vì nói những điều mình không chắc chắn cho dù mình đúng hay là sai

Một ký sự mới, chà, vẫn hồi hộp dù được dẫn dắt một phần.

Sry trước vì em đã từng bị mắng là không biết thì dựa cột mà nghe, mừ nghe mà không chịu nói thì dốt vẫn hoàn dốt. Trong loạt bài ký sự này của anh, em vẫn thấy một cái gì đó không ổn ổn trong suy nghĩ của Mr Commale. Để diễn giải rõ ràng thi hơi khó, HVA bị tấn công, anh đưa ra luật chống lại sự tấn công đó, kẻ thù thay đổi, anh cũng thay đổi, điều đó thật tuyệt vời ngoài việc anh bị động khi cố gắng tìm ra dấu hiệu của kẻ tấn công và nhận diện dấu hiệu đó để phòng thủ.

Dấu hiệu trên không rõ ràng, để em cố diễn giải xem được không.

iptables -t nat -A PREROUTING -i $IF -p udp -s 0/0 ! --sport 53 -j REDIRECT --to-ports 9

Luật này khá rõ ràng, nhưng sẽ không hữu dụng khi gói tin đó bị lột mất thông tin về port

iptables -t nat -A PREROUTING -i $IF -p udp -s 0/0 ! --m length 47:0xffff ! --dport 65431 -j REDIRECT --to-ports 9

Luật này sửa đổi của luật trên, cụ thể hơn, chi tiết hơn nhưng nặng nề hơn, sẽ cần bao nhiêu CPU xử lý cho một luật này ? Và nếu kẻ tấn công thay đổi một trong số các giá trị trên, giả sử không phải giao thức UDP, anh sẽ xử lý thế nào ?TCP, ICMP, hay etc nào đó.

Em thử đề xuất xem sao :

- nếu ip nguồn=ip dns server ==> accept
- mọi thứ còn lại ==> null

Luật trên chỉ xử lý so sánh IP, bỏ qua các công đoạn so sánh về giao diện mạng vào, về loại gói tin,về cổng,về chiều dài về tính phân mảnh, liệu có khả quan hơn, tổng quát hơn, và quan trọng là thời gian xứ lý nhanh hơn chăng?Nếu lo ngại về việc giả mạo IP nguồn, liệu có thể lựa chọn IP dns từ một nơi xa xăm nào đó trên www hoặc đặt thêm tham số limit với IP này, 3 p/s chẳng hạn.

1. Module chỉ phải load 1 lần chứ không phải mỗi khi có request là load module!

Nếu php được build static với apache thì điều này thậm chí là không còn, tuy nhiên thời gian để khởi tạo thành công 1 process lại lâu hơn. Còn nếu ở dạng modun động, apache cần time để phân loại request rồi mới quyết định có gọi php modun hay không. Sau khi đã load ổn, thì tiến trình đó sẽ vẫn tiếp tục hoạt động tốt, tuy nhiên nếu phải khởi tạo lại apache process thì quá trình trên lại lặp lại.Và vì thế, việc nạp hay không nạp vẫn luôn làm thời gian tiêu tốn nhiều hơn là việc khởi tạo sẵn tiến trình và chờ đợi request xử lý.

4. PHP chạy trên lighttpd như bạn nói là ở mode FastCGI. Apache HTTPD cũng hỗ trợ FastCGI, tuy nhiên với cài đặt mặc định thì thường lighttpd + FastCGI nhanh hơn Apache + FastCGI vì lighttpd nói chung là lightweight hơn Apache. Nhưng bạn cũng thấy đây là vấn đề của webserver + FastCGI, đâu có dính gì nhiều tới PHP

Nếu tính PHP chỉ là thời gian từ khi php biên dịch đến khi biên dịch xong, thì mình không có thông tin gì về time giữa modun và cgi, chắc là như nhau. Suy cho cùng, vậy topic có kết luận gì về các cách biên dịch php. Thời gian chỉ là 1 trong số nhiều yếu tố .

Vì topic lập nên để thảo luận về việc build LAMP, tức là build Apache+PHP, vì thế ngay từ đầu mình đã sai khi cố gắng tranh luận điều không đúng ở topic.
Tuy nhiên với tinh thần muốn học hỏi , mình hy vọng sẽ chia sẻ được chút ít thông tin cho mọi người.

- Trong mô hình LAMP hiện tại, apache mỗi khi gọi file .php sẽ hoặc dùng modun của PHP, hoặc dùng cơ chế CGI để tạo tiến trình php rồi từ đó dịch file .php và trả về kết quả. Tùy theo cơ chế apache hoạt động, tuy nhiên khi dùng CGI, bắt buộc cần có thời gian cần thiết để khởi tạo tiến trình php hoàn tất rồi mới dịch mã. Và đó là lý do vì sao CGI lại chậm hơn so với dung kiểu modun.

- Trong các mô hình khác, một trong số mình cài đặt là sử dụng lighttpd + php , khi đó quá trình khởi tạo php được tiến hành ban đầu, các tiến trình php đựoc khởi tạo và ở trạng thái chờ. Ứng với mỗi request, lighttpd không gọi modun php mà chuyển giao trực tiếp qua socket đến tiến trình php đang đợi sẵn. Và vì không cần thêm các quá trình trung gian nữa, nên thời gian đáp ứng request của PHP nhanh hơn 20% so với kiểu load modun apache.

- Một trong những lý do nữa mình ủng hộ biên dịch php kiểu CGI là khi đó mỗi tiến trình php sẽ được khởi tạo với một UID riêng biệt. Điều này là rất quan trọng về phương diện bảo mật, mình có thể sử dụng UID này để thắt chặt giới hạn truy cập của thực thi php vào cấu trúc site thư mục.Nếu là share host thì sử dụng UID khác nhau sẽ tránh được local acctack.

Chính xác là bị hỏng, không phải là sự cố hồi tháng mười mà ở một thời điểm khác, em nhớ có đọc trong một bài viết nào đó về ký sự ddos .
Về việc hỏng network card thì hồi trước em có down torrent bằng desktop, sau đó phải thay network card khác, cũng không biết có phải do quá nhiều connection hay vì card rởm nên bị hỏng.

Vấn đề em muốn hỏi là có biện pháp nào phòng trừ việc này không, Network card bị hỏng mà không làm gián đoạn dịch vụ của mình, cũng như nếu bị ddos ở mức cao nhất, liệu network có bị hỏng không vậy.

OK OK

Tớ sai tớ sai rồi, tớ thực sự sai rồi. Mong tha lỗi cho tớ.

Lỗi của mình rất là to lớn , đó là việc đang bàn xem php ở dạng module với CGI thì lại đâm ngang apache, và thế là mỗi người một ý sai lệch. Và vì nó lệch nên mình cũng bàn xéo một tý nhé

- Với apache : chạy theo kiểu CGI sẽ nặng hơn , điều này hoàn toàn đúng, nhưng chỉ đúng với apache thôi, chính xác hơn là đúng với cơ chế xử lý hiện tại của apache. Mình đang bàn về web service mà, ngoài apache còn một số khác nữa chứ.

- Về RAM: tớ nhỡ lời, ai lại đem con máy nhỏ 4 G ra làm gì,người ta máy chủ 64G còn chả giám nữa là smilie

.Vấn đề là tại thời điểm hiện tại, nút thắt của một máy chủ web thông dụng và đơn lẻ nằm ở ổ cứng chứ không phải là RAM hay CPU nữa.Vì thế nếu nói về biên dịch php để tiết kiệm RAM hoặc biên dịch PHP hoạt động thế nào đó tốn ram hơn thì vấn đề đó không phải là quá quan trọng,mà quan trọng là khả năng đáp ứng chung .

Về performance: module > CGI-like
Cụ thể hơn thì module = thread, CGI = process; thread thì light-weight hơn process cái đó rõ rồi. Còn cụ thể như thế nào thì lại...tùy vào OS

Cái này còn phải xem lại àh nha. Khi nói php là modun thì được hiểu là nó là một thành phần của web service, còn việc web service chạy theo kiểu nào thì còn xem xét tiếp. Apache có thể chạy theo kiểu proc , theard hoặc hybird đó nha.

Nói rằng thread chạy nhanh hơn process chỉ đúng với điều kiện process đó shutdown và start liên tục, nếu process đó không bị kill mà ở trạng thái idle đợi request thì cũng chưa bít đâu.

Về bảo mật: chia ra làm 2 trường hợp
* Shared hosting:
- module: quên chuyện bảo mật với nó đi
- CGI: bảo mật tốt hơn, nhưng vì dạng CGI khá "nặng", cho dù là với FCGI-like cho nên với các shared hosting "rẻ tiền" thì CGI không được ưa chuộng lắm vì chẳng mấy chốc là nó làm server "sụm bà chè".

Sure, CGI nặng hơn , tuy nhiên nặng về RAM và hiện tại RAM không hẳn là yếu tố đắt đỏ với 1 server 4g- 8g- 16g .Server sụm chủ yếu do hightload hoặc giới hạn về số request xử lý thôi.

* Dedicated hosting:
Module lightweight hơn CGI-like nhiều, nên tôi thì sẽ luôn chọn dạng module (ít ra cũng...chống DOS tốt hơn smilie

).

Cái này thì nghĩ cả ngày cũng không ra nó liên quan gì đến DOS, khổ chủ vào giải thích xíu

mR.Bi wrote:

BachDuongTM wrote:

- PHP theo dạng modun, được webservice gọi đến để dịch mã .php , có thể kể đến như .so của apache, hoặc .dll bên IIS window.

Về phương diện bảo mật, việc config Apache và php theo mình nghĩ mới là quan trọng, hơn nữa trong quá trình cài đặt, nhưng vấn đề về bảo mật cho apache *nếu được ngó tới* cộng với việc chú ý php, thì ở mức modile và ứng dụng không khác là mấy.

Vì thế này nên request mới được xử lí chậm hơn chứ, việc khởi tạo một module của một ứng dụng với việc khởi tạo riêng một ứng dụng thì mình nghĩ về trước làm hao phí tài nguyên server ít hơn

Đó là sự khác biệt giữa đọc tài liệu và test thực tế. Có nhiểu recommed khác nhau và recomend của mình là đừng vội tin thằng nào hết <theo logic là gồm cả mình smilie

>

Việc khởi tạo php ứng dụng trước sẽ làm hao phí tài nguyên hệ thống mà cụ thể là RAM , tuy nhiên web service sẽ không cần triệu gọi modun php mỗi khi có request cần biên dịch mà chỉ cần xoay mình kê chân đá gót cho php proc đồng thời dạo mát một vòng đợi nó trả mã về. Với server 4G hoặc 8G ram hiện tại thì tốn vài trăm không là vấn đề gì, vấn đề là mức tải server và thời gian để trả lời request. Trong triển khai thực tế, 1 server mình thường cài không phải 1 mà là 3 tiến trình khác nhau gồm web service chỉ trả lời static request, web service trả lời script và php proc .

Bảo mật là bài toán vô cùng, cá nhân mình chú trọng mức thấp nhất là OS cụ thể ở mức tiến trình và quyền truy cập file, giả định apache hoặc php bi bug thì hệ thống ít bị phá hoại nhất có thể.

Xin thông báo cùng các bạn diễn đàn đã bị gián đoạn từ sáng 28/10 đến chiều 29/10/2008 vì lý do kỹ thuật. Network card chính của firewall bảo vệ hệ thống HVA bị sự cố nên trọn bộ thông tin lưu thông ra vào đều bị cắt đứt

Vấn đề này tạm thời post vào box này để mọi người cùng thảo luận...

Có vẻ như sự cố cháy card mạng của HVA không phải diễn ra lần đầu tiên,và câu hỏi của em là vì sao bị như vậy ?

Nếu xét về mặt logic, card mạng là một bảng bo mạch vi tính và thông tin là các packet gửi dồn dập đến, vậy có khi nào một luồng dữ liệu đó lại có thể gây hỏng hóc vật lý như làm méo hoặc mềm chảy card mạng được hay không ?Theo cá nhân em là không thể, hệ thống ít nhất được thiết kế để chịu đựng mức độ hoạt động 100% chứ nhỉ.Vậy thi suy logic ra phải chăng card mạng hỏng vì quá nóng do không được làm mát tốt . Một card mạng hỏng có thể gây ra treo toàn server hay không, có cách nào để LB 2 network card hay không cũng như hệ thống HVA có server dự phòng cho việc này.Và tại sao cũng luồng dữ liệu đó, router định tuyến của ISP lại vẫn hoạt động để chuyển nguyên cú đấm thép đó đến server HVA mà không quang tèo.

Just for finding a slution ... Vì em e ngại biết đâu home server còi nhà mình cũng bị tấn công từ 50 000 IP khác nhau chẳng hạn

conmale wrote:

guardianknight wrote:

Mình đang làm đồ án chuyên ngành "Tìm hiểu cơ chế lần theo dấu vết phát hiện sự xâm nhập trái phép vào hệ thống máy tính trên Linux".

Nhiệm vụ ban đầu của nhóm mình là tìm hiểu về File .log và Tripwire.

Có ai có tài liệu gì liên quan tới File .log và Tripwire thì share cho mình tham khảo nha. Hoặc có anh chị nào biết về vấn đề này hay đã từng làm đồ án này thì cùng thảo luận chung nha.

Các bạn có thể cho mình biết kỹ hơn về File .log và Tripwire. Hoặc có thể cho mình tài liệu về 2 cái đó.

Thêm nữa là bọn mình mới tìm hiểu về Linux thôi, còn noob lắm, có gì thi nói kỹ kỹ tí nha các bạn.

Thanks advance !!!

File .log của.... cái gì tạo ra?

Tripwire thì: google tripwire và vào trong box "Các tài liệu hữu ích" mà hỏi thăm xem ai có cuốn tripwire nào không.

Riêng việc làm "đồ án chuyên ngành" về mảng "phát hiện sự xâm nhập trái phép trên Linux" mà lại "mới tìm hiểu về Linux" thì 99% là vất vả và không có kết quả tốt được. Đồ án này đòi hỏi sự nhuần nhuyễn với Linux, nếu không, bồ không thể thực hiện được. Có chăng là chắp vá thông tin lấy từ sách hoặc những nơi khác (theo tôi, thế thì không thể là đồ án được).

Đồng ý với anh là bạn vừa hỏi chưa có nhiều kiến thức về linux.

Nhưng câu không thể làm đồ án được có gì làm em hơi nóng mũi .Lý do thì vì ở trường không được dạy nên 90% bọn em phải tự học bên ngoài <về linux chẳng hạn>, đó là lý do vì sao chất lượng đồ án môn học bảo vệ xong là cho vào kho cất. Và có vài chục % buồn khi đồ án của em làm về FreeBSD ứng dụng hoạt động gateway như là một security gateway ,các thầy hỏi rất ít để cho qua người tiếp theo <bị quay chín khi làm về chứng thực CA>

Đây là 1 public .apsx webshell được công bố khá rộng rãi, tên K-shell chắc chỉ là sửa tên choi vui thôi.

Quay lại vấn đề chính, câu hỏi đặt ra là bạn muốn fix thế nào ?Nếu là delete file shell thì đơn giản, nhưng để bảo mật không bị tấn công lần nữa thì khó hơn. Ít nhất tại thời điểm hiện tại, bạn không biết vì sao shell được upload lên server và nó còn là cái thòng lọng treo đó .

Về kinh nghiệm server 2k3 mình có xíu chia sẻ :

1. đảm bảo code viết tốt nhất có thể, tốt về hoạt động, và tốt về bảo mật.
2. Hoàn thiện code ở local
3. Upload code lên thư mục web trên server và tiến hành phân quyền lại hợp lý
4. Thư mục code chỉ có quyền đọc với user site , hoặc thường là IIS guest .
5. Thư mục code có quyền đọc ghi với FTP user để có thể tiến hành chỉnh sửa lại code
6. Thư mục code có thêm 1 thư mục upload, thư mục này là thư mục đặc biệt, User site có quyền ghi và xóa trên đó, tuy nhiên IIS chỉ hoạt động ở chế độ no script với thư mục đó, tức là cho dù uload mã .aspx lên đó thì IIS chỉ đối xử như là một file text thường, thư mục này sẽ đựoc sử dụng để upload nội dung từ member.
7. Với mã .php thì chỉ ở trên là đủ để đảm bảo an toàn site nhưng mã aspx được hoạt động đưới một định danh riêng, mình từng kiểm chứng thấy ngang quyền system, vì thế đúng là họa vô đơn chí, add system deny edit lun thư mục code.Và hy vọng chính sách của mình không có lỗ hổng.

8. Cầu nguyện
smilie

phân quyền cho dù chặt chẻ đến đâu cũng chỉ có nghĩa trong một ngữ cảnh nào đó mà thôi (ở đây là OS cài trên ổ cứng). Bạn thoát ra khỏi ngữ cảnh đó thì phân quyền sẽ không có nghĩa lý gì nữa.

Hi ,đúng theo câu nói này nè.

Để có thể được hoặc không được truy cập 1 file. bạn cần hỏi hệ điều hành tại thời điểm đó rằng tôi có quyền đọc file không, và nếu mang một LIVECD ra thì bạn không còn là hỏi OS logic ở trên nữa mà đang hỏi OS của LIVEcd. Và vì 2 OS là khác nhau nên không sẽ trả lời khác nhau.

Với một server online 24/24 trên mạng thì chmod 700 là đủ để giới hạn truy cập file, nhưng nếu ở nhà thì cần có những cơ chế khác để xác thực truy cập. Mã hóa chỉ là 1 kiểu, nếu trong win2k3, bạn có mã hóa dữ liệu thì admin vẫn được cung cấp các cơ chế khác để đoạt quyền và giải mã dữ liệu <hoặc cũng không thể giải mã được smilie

>

Có những cách nào khi biên dịch PHP?

Trả lời có 151134368435435643543564354 Cách biên dịch PHP khác nhau. Khác nhau về thư mục cài đặt, về loại trình biên dịch, về hệ điều hành, về NƠI CÀI ĐẶT, về tên file thực thi,...

Mình đã từng cài PHP theo vài lối mòn sau :

- PHP theo dạng modun, được webservice gọi đến để dịch mã .php , có thể kể đến như .so của apache, hoặc .dll bên IIS window.
- PHP dạng thực thi CGI hoặc FastCGI, không thực sự hiểu sâu về nó, nhưng nôm na là PHP hoạt động ở dạng thực thi,tự chạy tiến trình để dịch mã .php và có các cơ chế khác nhau để trả ngược kết quả về webservice

- PHP hoạt động như ứng dụng smilie

<có nghịch chơi thôi >

Về phương diện hoạt động và hiệu suất thì không thể nói miệng mà phải trực tiếp test bằng tools để kiểm chứng. Xét về phương diện bảo mật :
- PHP dạng modun, vì được webservice triệu gọi nên hoàn toàn dịch mã .php với định danh tiến trình của web service. Điều này cũng không có gì đánh giá về bảo mật cả, tuy nhiên nếu trên phương diện share hosting, chạy toàn bộ các site với cùng một mức truy cập như nhau là điểm yếu về bảo mật khi có localacttack.

-PHP chạy dạng thực thi, tự php sẽ có định dang tiến trình riêng,hoàn toàn khác biệt với web service,có nhiều cách để kích hoạt PHP chạy , với Apache có thể thực thi CGI mỗi khi request cần xử lý, cũng có thể có các cơ chế khác để kích hoạt tiến trình PHP chạy sẵn và ở chế độ chờ mỗi khi có request xử lý mã. Quan điểm cá nhân mình thích kiểu này hơn vì nó phân tách được request web đâu là chế độ static <hoàn toàn không nguy hại > và đâu là các srcipt có thể được lợi đụng.

- Cái cuối là chạy mã .php nhưng không tạo mã HTML mà để chơi cờ caro chẳng hạn smilie

- Xét về bảo mật, mình coi phân quyền cấp OS là cao nhất, cụ thể ở mức tiến trình và quyền truy cập file <có gì sai tên gọi chăng> vì thế mình hay sử dụng cách thứ 2 hơn, tiến trình apache và php được triệu gọi riêng biệt, các mã .php được php xử lý còn file static thì apache trả lời luôn. Hơn nữa do được khởi tạo sãn nên cách này có vẻ hiệu quả và bền bỉ hơn việc cứ mỗi request đến lại một lần triệu gọi và nạp php vào bộ nhớ. Hơn nữa, tiến trình PHP được spawn với ID riêng biệt nên có thể giới hạn vùng truy cập và tránh làm ảnh hưởng giữa các site với nhau.

More

Vẫn là câu nói quen thuộc nhưng cần nhắc thêm lần nữa : bạn cần hiểu rõ điều mình đang làm, thấy bạn đặt câu hỏi lủng củng quá.
Về mình có một vài trợ giúp hy vọng có ích với bạn.

1. Yêu cầu công việc của bạn yêu cầu phải sử dụng NAT, và bạn chỉ có 1 public IP mà thôi.
2. Bạn có 2 local server là web và mail , tương với khi public ra internet 2 dịch vụ đó là web.com và mail.com.

- Về mô hình, vì bạn có 1 public IP và chỉ muốn hoạt động trên 1 cổng dịch vụ là 80, nên NAT chỉ cho phép bạn hoạt động với 1 local server <==> Internet. Tương ứng với việc khi truy cập từ internet thì yêu cầu đó sẽ được chuyển tiếp đến 1 local server duy nhất mà thôi.

Và vấn để ở đây là dù web hay mail local server thì vẫn phải chấp nhận 1 server sẽ đứng ra nhận request và chuyển tiếp đến server tương ứng.Hoặc bạn làm theo hướng dẫn ở trên hoặc mình có một số gợi ý :

1. 1 server nhận tất cả request, sau đó sẽ lọc request đó tự chuyển tiếp và sử lý đến chính nó <nếu nó là nó> hoặc chuyển tiếp đến server còn lại nếu không đúng.

2. 1 server sẽ nhận 2 loại request và sử lý cả 2, không nhất thiết phải đặt mail <webmail > trên đúng mail server , có thể cài webmail trên server web được.

3. Nếu public server sử dụng IPtables, không có lý do gì bạn không cài được một proxy ở đây, apache là một ví đu. Proxy sẽ nhận request và trực tiếp phân phối lại cho localserver.

4. Sao không thêm 1 public IP nữa và thực hiện Nat 1:1

5.

bạn có thể tìm hiểu thêm về những thắc mắc của mình ở đây

http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html

http://www.zzee.com/solutions/linux-permissions.shtml

Khi bạn đã thấu hiểu những điều trên, chúng ta sẽ bàn tiếp về web, về shell và hack

Dear Dabu

Mình không biết chi tiết triển khai hệ thống của FPT, tuy nhiên là một kỹ thuật viên mình có đủ cách thức để redict mọi trang bạn ghé thăm về trang portal và hình như là thêm cả vnexpress nữa.

Vấn đề này chắc liên quan đến network, cũng như có một hệ thống lọc nào đó trên FPT chứ không chỉ đơn giản là redict DNS server. Nếu bạn không tin , hãy gán IP tĩnh trong file hosts của win, mình đoán vẫn vô ích thôi.

Giang Hồ Mạng wrote:

Trong các ký sự của đại ca con ma le lé (đừng lấy dép chọi u đầu em) nếu anh trai cho đám nhỏ, đàn em như em file tcpdump khi bị tấn công đem về nhà phân tích thì quá tốt

Hi

nếu như có file đó rùi, cần chi nữa không ? file config firewall nha ?

Thực ra mình kô nghĩ điều đó là cần thiết, vì Mr Commale cũng miêu tả rõ ràng rồi mà. Hơn nữa, sao bạn không thử chơi cờ tưởng nhỉ, hacker là mình thì sẽ DDOS nè, rồi mình sẽ chống thế này nè smilie

Ask for more hay Deep thinking

hi hi

Xem ra Mr Khoai gần tìm được ra đáp án rồi. Rõ ràng các làm này tối ưu hơn nhiều so với route null rồi. Em chỉ còn chút thắc mắc về việc xử lý với 1000 IP 1 lúc, rõ ràng để lập nên list các ip là một việc khó,lưu lại và kiểm tra list IP này với delay nhỏ nhất chắc còn nhiều việc để phải suy nghĩ sâu nữa.Không biết anh commale có thể gợi ý chút xíu gì không

Em đề nghị dừng thảo luận về giải pháp ở đây, để có anh commale còn vốn viết tiếp hồi sau nhỉ smilie

Em có đọc qua tài liệu về route null, cụ thể có link minh họa ở đây

The difference between iptables DROP and null-routing
http://www.tummy.com/journals/entries/jafo_20060727_140652

Trong bài viết, tác giả cũng viết khá rõ ràng, rằng nếu sử dụng iptables thì hệ thống ít nhất cần so sánh các tham số như ip gói tin, loại gói tin, port ,.... trong khi nếu sử dụng route null thì chỉ cần thông số duy nhất là IP mà thôi.

Nhưng có 2 vấn đề trở ngại là :
- phải biết đích xách IP nguồn gửi, vấn đề này tưởng dễ mà không dễ nếu như chúng ta bị 1000 host tấn công một lúc
- gói tin cần qua iptables trước khi được route, phải chăng cần stop iptables để xuống thẳng firewall ?? hoặc tệ hơn chút là iptables chỉ check ip và accept ngay khi có IP nguồn hợp lệ <trùng với ip block> để cho nó xuống thẳng route và nhét vô route null. Cho dù vậy, xét thấy nó vẫn cứ thế nào ấy, ít nhất vẫn cần iptables check IP nguồn rồi route lại check tiếp ip nguồn, 2 lần check.

Thực ra kỹ thuật này không có cái gọi là /dev/null để redict gói tin đâu. smilie

dear bebedeptrai1109

Khi bạn sử dụng tools CuteFTP có chế độ lưu mật khẩu đăng nhập, tên tài khoản sẽ hiện thị rõ, tuy nhiên mật khẩu thì bị ẩn đi. Những dấu *** đó thực chất là các ký tự thay thế mà thôi. Nó không có nghĩa cũng không có cái gọi là ẩn đi. Hãy nghĩ rằng nếu chỉ việc copy ra chỗ khác một cách dễ dàng, thì đó không có chút gì bảo mật cả.Và vì bảo mật, việc đó không dễ dàng

Vậy làm sao để có thể biết đươc nội dung pass ? Vì mình đâu có nhập vào mà nó vẫn có được, chứng tỏ CuteFTP có lưu bản sao , hoặc một dạng khác của mật khẩu ở đâu đó trên hệ thống, vấn đề là lưu ở đâu, lưu thế nào,và làm sao để đọc ngược ra dạng tường minh sẽ là một bài toán để bạn nghiên cứu tiếp. Sao không thử lên mạng để tìm hiểu nhỉ ? nhiều điều thú vị lắm

More: quanta & louisnguyen27 : sao 2 người lại có thái độ khó chịu vậy, ai cũng hiểu về câu hỏi, nội dung câu hỏi và người gửi câu hỏi, đừng làm người khác không vui vì mình không vui

em có vài điều băn khoăn ở đây

với thiết kế của HVA mình phần firewall, sao lại thực hiện cản lọc chi tiết vậy anh. Điều này có gì đó trái với suy nghĩ của anh về việc thiết kế firewall chỉ cho phép các ứng dụng hợp lệ và loại trừ mọi phần còn lại.

vd với UDP, ngoại trừ cho phép kếi nối UDP đến một IP dns nào đó mà ta tin cậy, mọi udp khác cần bị drop. Suy nghĩ của anh về một rule drop null port sẽ mang tính là ứng dụng với tình huống hiện tại chứ chưa phải là cho phép loại trừ tổng quát <sry vì hơi khó diễn đạt >

Em có check thử thấy hva open 3 port là 80 25 và 5555,em nghĩ với các cổng này, chỉ giao thức TCP là được phép truy cập với trạng thái thông thường nhất <đủ port, đủ IP, state hợp lý và rate trong hạn>, mọi giao thức khác cần xóa bỏ.

More: với một server thường, bảo mật được như HVA là tốt rồi, tuy nhiên em băn khoăn về khả năng HVA chống chịu tấn công phá hoại. Với ví dụ trên ,sao HVA chưa tích hợp thêm firewall phần cứng hoạt động chế độ tranfarent lọc cản các gói tin không hợp lệ trước khi đi vào HVA server với firewall iptables. Cụ thể anh đã phải nhờ vào can thiệp của ISP để cản lọc ở phần router và hầu hết các tác vụ cản loại thực hiện ở OS <và cho dù như vậy, hva vẫn hoạt động thật tuyệt vời.>

Cảm ơn BachDuongTM đã quan tâm và chia sẽ với sunrise_vn. sunrise_vn đặt ra vấn đề để nhập được sự chia sẽ của các thành viện trong HVA. Vấn đề đặt ra ở đây tại sao Solaris(risc) của SUN rất đắt, có giao diện người dùng rất tệ mà tại sao lại được nhiều người (đa số là rất giỏi) dùng. Trong khi đó FreeBSD hay Linux rất rẻ tại sao lại không chọn. Cộng thêm Mac Server cũng không tồi. Vấn đề chính mình nêu ra là ở chố đó. Một vấn đề phụ (conmale nói sunrise_vn mới biết) đó là không ai dùng Solaris(Intel) để làm máy chủ cả.
Thân ái!

1. SUN được dùng chủ yếu ở đâu vậy ? và những nơi đó có sự khác biệt gì với những nơi bình thường khác. Đừng nói Linux hoặc FreeBSD không được chọn, đúng hơn là những hệ điều hành đó phù hợp với các môi trường khác hơn.

Vấn đề mấu chốt là tùy theo môi trường thì lựa chọn hệ thống thích hợp. Và mỗi hệ điều hành có điểm mạnh của riêng mình, bạn cần biết điểm mạnh của từng hệ để sử dụng hợp lý. Ví dụ với các máy chủ vận hành trong ngân hàng hoặc viễn thông như máy chủ tính cước điện thoại chẳng hạn, ngoài các yếu tố phần cứng vật lý, hệ phần mềm vận hành trên cũng phải cực kỳ ổn định , có khả năng sử lý nhiều tác vụ đồng thời một lúc, cấp phát và thu hồi tài nguyên triệt để, có khả năng nâng cấp bảo trì không cần shutdown có thể chạy cụm nhiều máy tính ,... Với những tính năng này,SUN được thiết kế và test phục vụ nhiệm vụ này.

OKIE, hãy so sánh , winxp và 2k3 , đó là sự tương phản cực kỳ rõ nét, có thể dễ dàng kể ra cả chục tính năng win2k3 có mà XP không thể vận hành được . Tương tự như vậy , Linux , FreeBSD hoặc SUN cũng có khác biệt. Những khác biệt này không quá rõ nét vì nó không thể hiện ra GIAO DIỆN mà nằm sâu ở thiết kế bên trong. Và điều này đợi chờ bạn tự mình nghiên cứu khám phá ra đó. Hãy tìm xem FreeBSD có thể vận hành những máy chủ nào , với bao nhiêu CPU, bao nhiều RAM, HDD ,... đó là sự đánh giá sơ bộ khi so sánh với SUN hoặc Linux, chưa kể các khác biệt khác nữa.

Một chút thông tin về điểm test hệ thống
http://www.sun.com/benchmarks/software/solaris.xml#web

sunrise_vn wrote:

BachDuongTM nói rất đúng. Theo bạn mình đang cần xây dựng một máy chủ Web, hỗ trợ PHP, JSP, ASP.Net, MySQL vậy nên dùng OS nào để hiệu năng tốt nhất, chi phí thấp nhất, độ tin cậy cao nhất?

Với Web PHP+ MySQL mình thử đề xuất bạn sử dụng Ubuntu test thử xem sao , dễ triển khai và vận hành hệ thống. Hãy bắt đầu với những điều đơn giản, sau đó bạn sẽ dần dần tự mình có những trải nghiệm thú vị với từng hệ điều hành. Mọi điều mình nói bây giờ chỉ là bắt bóng xem hình, làm sao có thể biết chính xác nhu cầu bạn cần mà lựa chọn.

Một điều nữa bạn cũng đừng nên quá bận tâm giữa tốt và tốt nhất, việc vận hành một máy chủ yếu tốt đầu tiên và then chốt là sự ổn định điều này bao hàm nhiều yếu tố khác nữa. Đó không cần là mạnh nhất, mở rộng cao nhất, hay hỗ trợ nhiều nhất, đơn giản chỉ cần sự ổn định.

sunrise_vn wrote:

Dĩ nhiên là về khả năng làm máy chủ của Solaris so với các HĐH khác rồi. Sunrise_vn đưa các con số đó để nhấn mạnh rằng các HĐH khác cũng có khả năng quản lý tốt các tài nguyên đâu thua kém gì so với Solaris. Một vài mặt khác sunrise_vn cũng muốn thẻo luận nữa( đã nêu trên) là về phần mềm, tiêu thụ điện năng, khả năng tương thích phần cứng.
Mong cùng được thảo luận với các thành viên.

Đại dương sâu bao nhiêu vậy bạn hiền ?? 5m , 20m hay 2000000000m ?

Vấn đề là bạn nghe nói rằng solaris tốt cho máy chủ, vậy chỉ khi vận hành hệ thống máy chủ bạn mới có thể nhận định chính xác vấn đề đó được. Điều quan trọng ở đây là bạn phải biết môi trường mình đang cần để test, nghe các nhận định là việc tiết kiệm thời gian , nhưng bỏ sức ra test thực tế sẽ đem lại kết quả đúng nhất.

Với mình, mọi OS đều tốt, miễn là bạn áp dụng vào môi trường phù hợp.

Mình băn khoăn tự hỏi sao phải cố đoán HVA chạy cái gì , như thế nào , ở đâu nhỉ.

Giả sử một vị sư đưa đến 1 cái hộp kín và bảo con đoán vật tròn bên trong là gì đi, cái mà chúng ta có được là thông tin vật đó là hình tròn, nhưng nó LÀ CÁI GÌ thì không thể biết. Nếu đã không biết thì hoặc cố mà hỏi thêm để đoán tiếp , hoặc bỏ qua nó vì mục đích chúng ta không phải tìm ra NÓ LÀ GÌ mà là ĐẬP BẸP NÓ .

Với HVA, có thể tự vẽ lên sơ đồ kết nối rằng sẽ có 1 web service nhận request , gửi các yêu cầu kết nối đến database, nhận lại thông tin và sinh mã HTML. Cho dù web service đó có là IIS , apache , lighttp, hoặc 1 cái tự chế bằng java đi chăng nữa, nó phải nhận request và xử lý, đó là chân lý không thay đổi. Vậy lại phải đọc rfc về mấy cái http xem nó như mô, làm sao nó phân biệt ai với ai , có điểm yếu nào trong việc xử lý này không, để có thể deface, để có thể edit, để có thể DDOS. Tất nhiên nếu không biết web service đó là chi thì biết tìm điểm yếu ở chỗ mô ? nhưng cho dù biết đi nữa, cái mà ta gọi là "điểm yếu hay bug" chắc đã được "fix" , cuối cùng thì vẫn là tìm ra lỗ hổng mới.

Đại khái mình muốn nói rằng, HVA là black box nên không cần tốn quá nhiều time để tìm xem box đó là gì, coi nó như 1 web service chuẩn với đầu vào ra giả định , và công cuộc đi tìm điểm yếu xuất phát từ nơi yếu nhất, nơi được test kém nhất trong mọi nơi : code forum.