Messages posted by: myquartz

Sử dụng kỹ thuật báo nhận. Khi CPU trên board nhận xong gói tin, thì gửi hồi đáp báo xong cho phía gửi.
Phía gửi nếu không thấy có hồi đáp báo xong thì chờ, có thì gửi tiếp, không có trong một khoảng thời gian nào đó thì gửi lại gói (coi như bị thất lạc dọc đường).
Cái này sẽ làm chậm tốc độ nhiều, nhưng đảm bảo gói tin đến đúng và đủ.

Không phải là df -al lại cho ra sda, mà là sda là 1 ổ (là ổ boot hệ điều hành lên) và sdb là một ổ khác (và chưa mount các volume).
Lệnh df cho biết kích thước dùng/còn lại của các volume "đã mount". sda mount và dùng để boot hệ điều hành, swap... nọ kia nên thấy, sdb chưa mount vào đâu cả nên không thấy trên df.
Còn fdisk thì xem partition của ổ. Bạn đã gõ fdisk thì nó tìm tất cả các ổ cắm vào máy là sda và sdb (cắm vào máy không có nghĩa là luôn luôn được mount). fdisk cho thông tin 2 ổ khác nhau còn gì (1 là sda 250G, cái kia sdb chỉ 160G).

Khi một người trong mạng kéo Bittorrent thì băng thông to đến mấy cũng bị nó hút sạch sẽ, không chậm mới là lạ.

QoS thì bạn đọc các hướng dẫn trong quyền Linux Advance Routing and Traffic Control, nhưng việc chống Bit cũng rất khó nếu không áp dụng kiểm soát cả ở mức application. Lý do là ở lớp 4 trở xuống, GW không thể "limit" luồng down (từ Internet về GW), chỉ có thể delay data lại không chuyển cho client và client sẽ không ack và phía nguồn sẽ giảm bớt việc đẩy dữ liệu về. Một số proxy, ví dụ squid, có delay pool và có thể giảm bớt tác hại của torrent (điều kiện là mọi thứ phải qua squid).

Việc dùng RHEL hay CentOS quan trọng là cái update của nó. Không có update thì bất kỳ hệ thống nào cũng dần trở thành kém bảo mật.
CentOS do community lấy source của RH về sửa vài chỗ bỏ trade mark đi compile rồi phân phối cho bà con tải và update.
Với RHEL dù có iso để cài (lậu hoặc ngay cả RedHat cho phép down cái này luôn chả cần down lậu làm gì), thì vẫn cần subscription number để làm cái việc up2date kia. RHEL cũng bán theo năm, mua RHEL chính là mua cái sub number kia chứ không phải mua cái đĩa hay mua bản quyền gì cả.

baze wrote:

Cụ thể hơn tí được không? Bởi về định nghĩa thì:
"The CDE is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data."
=> Vấn đề mình quan tâm ở đây là làm sao (phương pháp/ công cụ, ...) để xác định ra nó một cách chính xác?

Nếu nói đến phương pháp hay công cụ thì chả có gì nhiều. Đơn giản là trong hệ thống của bạn có nối mạng trực tiếp hoặc có thể tiếp xúc vật lý trực tiếp với thiết bị hoặc máy tính có dữ liệu thẻ trên đó thì sẽ nằm trong scope.
Ví dụ là thế này: 1 máy tính của bạn có nối mạng LAN với 1 máy tính khác, tuỳ ý ping, kết nối... trong máy tính đó nó chạy chương trình thanh toán thẻ => cả 2 máy tính và mạng LAN đều nằm trong scope, cả người sử dụng 2 cái máy đó cũng thuộc scope.
Ví dụ khác thế này: dù không có nối mạng gì cả với 1 máy tính có chứa dữ liệu thẻ, nhưng lại để trong cùng phòng, bạn có thể tuỳ ý đi tới đó, login hay tắt bật máy đó => cả bạn, cả cái phòng và cả cái máy tính phải nằm trong scope.

Nếu dùng Linux (Fedora/Ubuntu) thì Luks cũng là cái hay, rất tiện lợi nhất là cắm vào là tự nó mount và (có thể thiết lập) tự giải mã theo mật khẩu đã save trong gnome-keyring chẳng hạn.
Nếu cắm ổ Luks cho Win thì dùng cái này: http://www.freeotfe.org/download.html

Theo định nghĩa thì đó là nhưng thiết bị, máy móc và đường truyền mạng có liên quan đến việc truy cập, xử lý dữ liệu thẻ trực tiếp, không có sự kiểm soát hoặc ngăn cách nào đó với nhau, có thể là ngăn cách logic (bởi firewall) hoặc vật lý (bởi khóa cửa chẳng hạn) và ngăn cách này phải được verify một cách cẩn thận. Cái này bao gồm cả con người tham gia vào quá trình này (tức đụng đến các thiết bị và máy móc đó nữa).
Nói chung PCI-DSS cái phạm vi nó khá rộng đối với tổ chức có dịch vụ thẻ thanh toán, từ máy chủ, máy trạm, thiết bị... mọi thứ đụng đến dữ liệu thẻ.

ram wrote:

Mình có tài liệu này tìm được trên mạng, Sacombank Security Solution, gửi bạn tham khảo thử.

http://www.mediafire.com/?bxml3z57qi5byx6

Tài liệu này cũ và có hơi nhiều yếu tố kinh doanh ở trong này. Do FPT chào cho Sacom chứ ko phải là thực sự cái Sacom triển khai.

Tài liệu kỹ thuật đơn thuần thì 1 là các bank ở VN ... không có, 2 là nó là tài liệu bí mật chỉ vài người được biết (1 cách đầy đủ) do đó ít khi lọt được ra ngoài lắm. Do đó cách tốt nhất là lân la làm quen người có kinh nghiệm và hỏi về các practice của người ta, có thể học được nhiều hơn thế này.

Kiểu kiến trúc này là kiểu kiến trúc router mới, tốc độ cao và ổn định.
Thông thường việc tính toán ra bảng định tuyến với IPv4 hoặc v6, thì tốn rất nhiều resource của router. Chạy giao thức động chẳng hạn đã tốn, còn tốn nữa nếu mỗi gói tin vào interface này ra interface kia mà phải làm thêm việc mò mẫm trong cái bảng đó, với việc so sánh địa chỉ IP, subnet... phép toán and or và chạy bằng soft trên CPU => chậm và có thể ảnh hưởng với tính toán khác.

Do đó, kiến trúc mới họ tách làm 2 phần:
+ Control plane (hoặc gọi là routing engine ở 1 số hãng): chuyên tính toán bảng định tuyến (có thể bằng các thuật toán động như OSPF hay cả tĩnh). Phần này sẽ duy trì 1 bảng gọi là routing table mà show lên ta thấy, bảng routing table này sẽ được diễn dịch ra 1 bảng gọi là forwarding table (FT) cho phần kế tiếp với cấu trúc rất đặc thù. Bất kể giao thức lớp trên là IPv4, v6, IPX hay cái gì thì cuối cùng cũng ra FT. Cái routing engine này phức tạp đa dạng nên người ta thường sử dụng phần mềm và CPU để thực hiện cho tăng tính uyển chuyển.
+ Forwarding Plane (hoặc là forwarding engine): chuyên làm việc nhận và chuyển gói tin đúng như tên gọi. Nó nhận bảng FT ở bước trên, FT là bảng bit/byte viết theo ngôn ngữ máy đặc biệt tối ưu cho công việc xử lý chuyển mạch chip ASIC riêng. Có bảng FT ở trên do control plane nạp xuống, các bộ xử lý mạng ASIC chuyên dụng sẽ đơn giản là nhận 1 gói từ 1 cổng, so với bảng FT này và đẩy tới cổng khác (và có thể làm 1 số thao tác khác ví dụ cộng trừ ở chỗ này chỗ kia, tính toán check-sum lại...), cực kỳ nhanh, chả cần quan tâm đến tại sao lại ra được cái FT đó cả.
--------------------------
Kiểu tách này như dạng là 1 người đưa ra luật còn 1 người thực thi luật độc lập nhau ấy.
control plane có thể "chết" mà forwarding plane vẫn hoạt động. Lúc control chết thì packet vẫn đi nhưng đường đi ko đc điều chỉnh lại nếu có sự thay đổi. Kiến trúc này cũng giúp cho có thể có nhiều control plane để dự phòng lẫn nhau (nhiều chỉ huy, vài người thực thi).
Hơn nữa nếu tăng số lượng forwarding engine lên, tương ứng với số interface/port của router thì performance của hệ thống sẽ rất khủng nhờ sự hoạt động song song của forwarding engine. Trong khi control engine tăng lên thì chỉ tăng dự phòng (vì trong 1 thời điểm chỉ có 1 control được phép điều hành routing table, kiểu như chỉ có 1 chỉ huy trong 1 thời điểm thôi, không thì ai nghe ai?).

Kiến trúc này sẽ giúp cho router/switch có thông lượng tới hàng gigabit một cách dễ dàng. Juniper là hãng đầu tiên áp dụng phương pháp này, và họ cũng là hãng cung cấp router lõi dành cho ISP cực kỳ mạnh mẽ và tốc độ cao. Đến nỗi Cisco thì họ cũng học theo và các dòng cao cấp của họ đã theo cái này luôn.

kết nối https chỉ có client gà không biết mới dính giả mạo thôi. Trình duyệt sẽ cảnh báo ngay rằng cái certificate đó là không hợp lệ (untrusted), nếu client vẫn nhắm mắt "accept and add exception" thì chết là phải.
Cái này chả khác gì việc thằng lừa đảo nó đưa tiền giả cho người bán hàng, máy đếm tiền báo động đây là tiền giả nhưng người bán hàng vẫn cố tình chấp nhận tiền giả và đưa hàng cho nó, rồi lại chửi là "vì dùng tiền nên bị lừa đảo".

docphongm41 wrote:

Cảm ơn bác mquartz, em đã thử như sau:
Code:
RewriteCond %{HTTP_HOST} !^www\.abc\.gov\.vn
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*)$ http://www.abc.gov.vn/$1 [last,wwwect=301]
Kết quả là:
- Có thể tự wwwect với trường hợp test.xyz, trong đó test.xyz trỏ tới IP của webserver của site thật
- Tuy nhiên, nếu nhập thẳng test.xyz/folder/content thì url vẫn không bị rewrite và vẫn hiển thị nội dung y như nội dung của www.abc.gov.vn/folder/content

Không biết pattern của em còn thiếu chỗ nào bác nhỉ ?

Pattern không sai nhưng vị trí đặt cái đoạn đó có thể chưa đúng. Vì httpd nó chia mục theo virtual host hoặc directory. Bạn cần đặt cái đoạn của mình vào đúng nơi định nghĩa <Directory /folder/content> nữa thì mod_rewrite mới bật cho các folder này.
Bạn check xem cái /folder/content của bạn đặt ở context nào?

Thêm mấy câu này vào httpd.conf thử xem:

Code:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^your\.domain\.com\.vn$
RewriteRule ^/(.*)$ http://your.domain.com.vn/$1 [last,wwwect=301]

NetworkManager là 1 GUI trên môi trường Linux đấy. Nó cho phép setup cái OpenVPN cũng như PPTP và Cisco VPN.

Các bạn có yêu cầu, mình xin viết các bước thực hiện demo của mình thế này.
Công cụ:

Máy tính laptop có card wifi tương thích với libpcap (để capture được). Máy của mình là card Atheros tương thích tốt. Các card Intel Pro Wireless cũng được. Nếu đích của mạng cần capture là chuẩn a hoặc n tần số 5GHz thì laptop cũng phải support tần số này nữa. Lệnh lspci ở máy mình nó là loại card này: Code:

Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express)

Cài đặt Linux (mình dùng Fedora bản mới nhất), cài wireshark. tcpdump capture cũng được nhưng để trực quan cả giải mã hơn mình dùng wireshark.
Mật khẩu share secret của mạng Wifi định giải mã, cả SSID tên mạng nữa thì tốt, đỡ lẫn với các tên mạng khác trong khu vực. Nhập sẵn vào Wireshark như là hướng dẫn ở link bài đầu tiên.

Thực hiện:

Dò các băng tần (channel) mà mạng Wifi định giải mã sử dụng, để setup kênh cho bước kế.
Mở cửa sổ lệnh, chuyển wlan interface của mình dang mode Monitor. Nó sẽ chuyển trạng thái thành passive capture của mọi gói tin theo tần số đã định.
Sau đó mở wireshark lên, chọn wlan0 để capture và bắt đầu chờ đợi.

Các lệnh lần lượt là:
Code:

iwlist wlan0 scanning
service NetworkManager stop
iwconfig wlan0 channel 6
iwconfig wlan0 mode monitor
ifconfig wlan0 up
wireshark

Giải thích:

-quét mạng để tìm Channel
-để tắt NM giải phóng wlan cho ta sử dụng capture - chỉ áp dụng với Fedora, Ubuntu thì lệnh tắt service khác
-channel 6 sẽ bị lắng nghe
-chuyển wlan0 sang chế độ lắng nghe thụ động
-bật wlan0 lên để wireshark có thể bắt được
-chạy wireshark

Bạn sẽ thấy ngay dữ liệu truyền trên mạng wifi trong khu vực đó, kể cả AP bạn nhắm tới và không nhắm tới. Có nhiều gói tin rác như là beacon, Probe hay Response. Cái này chỉ là các gói tin trao đổi giữa các AP, station để điều khiển các phiên truyền, nó không chứa dữ liệu.

Mỗi khi wireshark bắt đủ 4 gói tin EAPOL (2 từ AP và 2 từ station), nó sẽ bắt đầu giải mã dữ liệu từ AP tới station ngay trên cửa sổ. 4 gói EAPOL này là thông tin bắt tay trao đổi khóa (mã hóa) giữa AP và station, và thực hiện ngay khi kết nối, nó cũng được lặp lại sau 1 khoảng thời gian nào đó để trao đổi khóa mới (các AP thường set giá trị 1h=3600s).
Bao nhiêu cặp AP-station thì sẽ có bấy nhiều cặp bắt tay EAPOL.

Chú ý là các gói tin multicast/broadcast từ AP gửi, nó sẽ được giải mã ngay khi AP-Station đầu tiên trao đổi. Vì AP/station khi broadcast nó sử dụng 1 key chung gọi là broadcast key, dành cho việc liên lạc broadcast với mọi station với AP và với nhau.
Còn khi uni-cast với 1 station cụ thể thì nó mới dùng key riêng của station đó, lúc đó phải chờ đợi mới giải mã được. Việc capture này là hoàn toàn thụ động, không ai biết có mặt của việc này, và capture được khi ở xa nhưng có thể mất gói.

Lúc nào có chỗ up mình sẽ gửi 1 đoạn file capture ở Tetcon, chỉ là demo thôi ko có thông tin nhạy cảm đâu.

vd_ wrote:

@myquartz

Thắc mắc sao không dùng modsecurity, hoặc nếu được thì tương luôn cái snort

Mod_security hoặc snort thì có nghĩa là tốn thêm tài nguyên để chạy (đôi khi còn tốn hơn cái server chính). Mình chỉ dành nó cho những thứ quan trọng hơn, khách hàng VIP hơn.

Mới đầu nhìn em cũng ớn thật.
2 cái file index.php đó là có tồn tại. Và vào nó nếu sai tham số thì đơn giản là nó in ra cái thông báo lỗi thiếu tham số (từ script), nhưng với HTTP server thì vẫn là 200.

Chắc phải chế thêm cái gì để lọc cho nó đẹp hơn.

Câu trả lời là: Không.
Xác thực Wifi 802.11abgn, kiểu Preshare key, hay viết tắt của PSK (WPA-PSK hoặc WPA2-PSK) là một kiểu xác thực dành cho Home User. Trong đó AP và các station (thiết bị cuối như điện thoại, laptop) cùng nhập 1 giá trị secret chung, có độ dài 8 ký tự trở lên.
Kiểu xác thực này cực kỳ phổ biến tại VN, có rất nhiều tại các gia đình và các quán cafe Internet hay Hotel. Mục đích để cho khách đến ăn uống ở tại nơi đó có cần mật khẩu.
Một điểm nữa là cái này cũng được dùng xác thực cho 1 nhóm người hàng xóm cùng chia sẻ kết nối Internet với nhau qua 1 AP.
----------------------------------------
Nhân sự kiện tetcon.org, ban tổ chức đã tạo ra một số wifi AP để chia sẻ Internet miễn phí cho người tham dự hội thảo, và đồng chí ThaiDN đã đọc mật khẩu (secret) này cho tất cả mọi người.

Với mật khẩu này + một máy laptop có khả năng capture wifi (nếu bắt cùng lúc 1 số kênh thì càng tốt, Tetcon phát trên các kênh 6, 8, và 9), là có thể giải mã gần như hết mọi thông tin truyền giữa các máy với AP dùng chung SSID/secret đó. So với Wifi không mã hóa thì cái này có khó hơn 1 chút là phải bắt được 4 msg EAPOL giữa AP và station, nhưng cũng chả vấn đề gì nếu bắt 1 khoảng thời gian dài.
Với cái tool nổi tiếng là wireshark và với hướng dẫn: http://wiki.wireshark.org/HowToDecrypt802.11 và nguy hiểm hơn việc này hoàn toàn không thể bị phát hiện bị nghe lén (máy tính chỉ lắng nghe sóng radio là đủ).
----------------------------------------------------------
Tớ tham dự tetcon và có nghịch 1 chút, mở laptop và bắt đầu bắt gói. Với 1.5GB dữ liệu bắt được, có tới gần 200MB bị giải mã (wifi), số còn lại là rác hoặc không giải mã được (do thiếu gói EAPOL).

Kết quả cũng không tệ bởi ngoài các dịch vụ bảo vệ bởi SSL/TLS (như của Google maps, talk, gmail... hay của Apple itune - 2 hãng này bảo vệ khách hàng tốt ghê), và 1 bạn nào đó PPTP VPN về cơ quan... thì còn lại có quá nhiều thông tin nhạy cảm đã được thu lại.

Từ danh sách bạn bè trên YM + nội dung chat chit (YM xác thực vẫn qua HTTPS nhưng kênh truyền chát lại là không mã hóa port 5500 - tớ không dám dùng YM từ lâu rồi, nhăng nhít thì được chứ chuyện nghiêm túc thì qua gtalk với TLS mới an tâm).
Thú vị nhất là bắt được mật khẩu của email info@g...host.com (mật khẩu toàn số, hic làm host thế đó ai dám tin) khi bạn này check POP3 (có thể máy tính/điện thoại tự check khi join wifi), cho đến mật khẩu admin trang quản trị nội dung của 1 trường đại học nào đó (quá vô tư khi dám vào từ nơi công cộng này).

Kể cả vài truy cập tới trang hvaonline (bắt được session ID) của 1, 2 bạn nào đó, và cả facebook session ID của 1 số người cũng có luôn (ko thử ko biết của ai). Nếu muốn dĩ nhiên sẽ vào được ngay session của các bạn.

Kha khá nhiều các station là của Apple (iphone or macbook). Dân Việt tiến bộ kinh tế thật.
-------------------------------------------------
Hic, các bạn cứ nghĩ là wifi "chùa" an toàn mà vô tư xài, không sợ nguy hiểm rình rập. Chả phải ở tetcon, vô số các quán cafe, hotel hiên này mà các bạn cũng vô tư thế, nếu ai rảnh đi capture thì khốn có ngày.
Và ở nhà, nếu share wifi cho hàng xóm, ngay cả khi là WPA2 đi chăng nữa thì cũng chả có gì ngăn cản hàng xóm de-crypt dữ liệu của ta - nếu họ biết cách.
Đôi dòng chia sẻ... và hướng tới 802.1x

Bây giờ trên Internet hình như có nhiều mạng bot tự động đi scan các server, máy tính, tìm chỗ sơ hở và và nếu sơ sót là bị chui vào ngay.

Một số hệ thống có báo cáo cho mình, ngày nào cũng ghi nhận vài chục tới hàng trăm, hàng ngàn illegal request/server, test open relay với SMTP và scan mật khẩu của tất cả các dịch vụ có xác thực, nói chung đủ các dịch vụ miễn là nó mở cổng.

Nhất là rất nhiều các fail authen vào SSH (dĩ nhiên 5 phát sai là bị fail2ban chặn rồi), ngày nào cũng đều đặn vài ngàn phát fail không mệt mỏi. Đến nối mình phải đổi port SSH sang số khác cho dù tự tin đặt mật khẩu an toàn (sợ nhất là 1 user nào đó vui tính đặt 123456).
Web thì scan đủ kiểu, ví dụ GET kiểu thế này:
Code:

GET //admin/index.php?_SERVER[ConfigFile]=../../../../../../../../proc/self/environ HTTP Response 200
GET //lists/admin/index.php?_SERVER[ConfigFile]=../../../../../../../../proc/self/environ HTTP Response 200

IP nguồn của nó thì rải rác từ Brazil, TQ, ấn độ, châu Phi, Mỹ và cả Việt Nam không ít. Thế nên chả có gì lạ khi trên access_log có vài cái cố tình làm sai RFC như kia.

Có lẽ cường độ các scan khá lớn, bác nào trương mặt cái server ra Internet, dù chỉ tạm thời trong thời gian setup hoặc thử cái gì đó, mà không tuân theo các quy tắc an toàn tối thiểu như mật khẩu đặt an toàn, bật Firewall và đặc biệt là vá víu lỗi cẩn thận thì chả mấy ngày mà bị đập chết.
Việc scan này đôi lúc làm nhiễu thông tin, admin đôi khi sao lãng và ko chú ý đến các cảnh báo (vì ngày nào chả có ít nhiều), lúc bị làm đích ngắm thật thì lại ko kịp trở tay.

Tớ làm như sau:
1. Cài đặt apache chuẩn của CentOS 6. (gói có tên httpd)
2. Cài đặt php-zts (cho phép php chạy với mod worker).
3. Sửa file config /etc/sysconfig/httpd, bỏ comment (dấu #) cái dòng: #HTTPD=/usr/sbin/httpd.worker

Khởi động lại httpd, thế là chạy dưới worker rồi. Lúc này việc config số lượng client/max request... cho httpd là ở phần:
Code:

<IfModule worker.c>
StartServers 4
MaxClients 300
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>

Bạn phải test ứng dụng của bạn trước. Nói chung nếu là ứng dụng bán hàng viết chuẩn và ko dùng các module linh tinh ngoài thêm vào thì sẽ chạy ngon.

P/S: mình cũng vừa thử test, bật worker lên, module thiếu nhiều lắm khi chạy với php-zts (ví dụ mysql). Do đó có thể bạn phải compile riêng cái này với tùy chọn khác. Mặc định câu lệnh configure nó thế này (với máy mình), nhiều without quá:
'./configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--without-sqlite' '--with-libxml-dir=/usr' '--enable-xml' '--with-system-tzdata' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--disable-dom' '--disable-dba' '--without-unixODBC' '--disable-pdo' '--disable-xmlreader' '--disable-xmlwriter' '--without-sqlite3' '--disable-phar' '--disable-fileinfo' '--disable-json' '--without-pspell' '--disable-wddx' '--without-curl' '--disable-posix' '--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' '--enable-maintainer-zts' '--with-config-file-scan-dir=/etc/php-zts.d'

Cái này có thể phải ngâm cứu thêm 1 chút và build thử.

Hi!
Xem qua thấy có câu lệnh sql này chạy nhiều và lâu:
Code:

select tag.tag from tbltag tag JOIN tbltagitem tagitem ON tag.ID= tagitem.idtag where tagitem.iditem='xxxx';

Nhìn các đoạn code SQL thì có lẽ cái này là Joomla hoặc Mambo. 2 soft này ngốn MySQL kinh khủng. một request của HTTP vào trang có thể tạo ra từ 20-50 SQL query => ko có MySQL nào chịu nổi. Bạn nên đọc 1 chút để tuning tham số trên Joomla, ví dụ tắt bớt logging, tracing... để giảm số query xuống. Google đầy các bài về tuning cái này.

Một việc nữa là về tuning DB, ko cần phải compile lại làm gì, cứ chơi gói chuẩn của CentOS, tham số trong my.cnf thì theo cái file ví dụ huge/large của bộ cài MySQL ấy (4GB RAM khá to đấy). Quan trọng bạn phải analyze các table trong db cần dùng, hoặc chạy optimize các bảng này.
Ngoài ra đánh thêm các index cần thiết (nếu chưa có), ví dụ bảng trên là bảng tbltag, và tbltagitem thì 2 trường tbltag.ID và tagitem.iditem cần được đánh index. Cái này phải dò từng câu lệnh slow để xem cụ thể, để đánh từng cái một.

Về mặt apache, nếu có thể nâng chạy CentOS 6. với php5.3, apache chuyển chạy worker thay vì prefork, php thì có zend engine. Nó sẽ giúp cho apache giảm bớt memory chiếm cho mỗi session, php chạy tối ưu hơn.

Với 300-400 session với joomla mà đã chậm thì là quá ít với server có 4GB RAM, tớ đã đạt con số gấp 4-5 lần như thế với server cấu hình tương tự.

conmale wrote:

Chỉ cần nắm khái niệm tổng quát nhất: backdoor là một phương pháp, cơ chế, phương tiện, ứng dụng nhằm qua mặt cơ chế xác thực để nắm lấy quyền điều khiển.

Backdoor trải dài từ tầng kernel đến những cái script đơn giản trên tầng ứng dụng.

Đó, sự "nhận biết" xoay quanh khái niệm trên .

Nếu chỉ đơn giản là qua mặt việc xác thực, thì phương pháp chống có thể có 1 số mẹo, bằng cách kết hợp việc xác thực nhiều hướng và nhiều "chủ thể" độc lập nhau. Giảm thiểu rủi ro mang lại của việc đó, và tùy thuộc ứng dụng (ở đây là web).
Một số cách của tôi nghĩ là có thể giúp ích ít nhiều, áp dụng tùy trường hợp cụ thể, ví dụ trong trường hợp web site tin tức, như sau:
- Phần mềm web phải có thể tách thành các module độc lập, ví dụ module view tin tức (public) và module quản trị tin (admin page). Mỗi module có thể liệt kê ra chức năng và mức độ ảnh hưởng nếu bị chui vào "back-door".
- Nhốt phần view (ít ảnh hưởng) của PM bằng một phương pháp nào đó sao cho module view không thể đi ra ngoài cái nó thiết kế là hiển thị thông tin trong DB ra. user kết nối DB (ví dụ mysql) chỉ cho view, và chỉ update 1 số bảng nhất định, rồi ngăn chặn việc kết nối ra ngoài, tạo file... bằng SELinux chẳng hạn. Mọi thứ vi phạm giới hạn đều bị cảnh báo cho admin bằng 1 hệ thống độc lập khác.
- Nhốt phần webadmin quản trị (ảnh hưởng lớn) vào 1 chỗ khác (server khác chẳng hạn), một là không public chỗ này (tức không truy cập từ ngoài được vào phần đó), hai là phải có 1 cơ chế xác thực bổ sung độc lập: SSL Cert, hoặc VPN (cơ chế bổ sung này không phải do tác giả PM kia làm, mà là 1 tác giả độc lập khác). Phần này thì cho phép kết nối user (mysql) được ghi, sửa, xóa dữ liệu tất cả các bảng.

Nói chung nguyên tắc của phương pháp này là không tin tưởng 1 ai tất cả mọi thứ, luôn dùng nhiều hơn 1 công nghệ của các đối tác khác nhau và có khả năng kiểm soát khắc chế nhau. Giống như nguyên tắc luôn khám của ít nhất 3 ông bác sĩ với cùng 1 bệnh của mình.
Như trong ví dụ, thì xác thực webadmin của PM do tác giả PM làm, còn xác thực SSL tới trang webadmin đó thì do Apache làm, 2 đơn vị này độc lập nhau và ít ra ta có thể tính rằng rủi ro back-door (về mặt xác thực đối với phần có ảnh hưởng lớn) thỏa mãn cả 2 cùng lúc sẽ thấp hơn nhiều so với 1 ông.

Chủ topic cho biết kết quả của lệnh:

uname -a

Làm admin, đôi khi có những lỗi ngớ ngẩn, quên thay vì cài bản 64bit lại cài bản 32bit mà cứ đinh ninh là mình cài 64bit.

Tớ không rõ lý do tại sao Techcombank lại dùng HTTPS cho trang tin tức, giới thiệu công ty của họ.

Nhưng suy luận thì tớ thấy Techcombank hơi lạ (thế mới đáng suy nghĩ và thảo luận). Tớ thấy top các công ty nổi tiếng trong làng công nghệ (nơi hiểu công nghệ), như Microsoft, Google, Yahoo, Apple, ... lẫn 10 ngân hàng nước ngoài (tương tự Tech) từ Citibank, Standard Charter,... đều không áp dụng HTTPS cho web site giới thiệu về họ. Phải chăng lợi ích Marketing (nghĩa là sự giới thiệu công ty đến với nhiều người nhanh hơn, nhiều hơn với chi phí rẻ hơn) lớn hơn cái sự xác thực cái web site (web server) đó đúng là của ... công ty đó.
Trừ có Paypal, công ty thanh toán trực tuyến, liên quan đến transaction rất nhiều, trang đầu tiên vào đó là HTTPS. Nhưng công ty mẹ của nó, eBay, thì không.

Đổi cái modem khác, modem rỏm không chịu nổi một vài máy PC + 1 loạt laptop của khách đâu. (có lẽ 5 cái tổng cộng là nhiều nhất).
Hơn nữa, cái Wifi Router rẻ tiền cũng không có khả năng kết nối quá nhiều laptop cùng lúc. Nên mua Wifi AP nhé, cái AP nó có khả năng kết nối nhiều hơn so với cái Wifi Router (AP nó khác router là nó thường chỉ có 1 port LAN thôi, và nó đắt tiền hơn hẳn).

Cho hỏi là sao lại mua máy mới và phải share với máy cũ??
Mua máy mới thì có sẵn ổ cứng to hơn rồi, move hết data sang dựng lại samba là xong. Cho con máy chủ cũ thanh lý đi.
Hoặc đơn giản, mua thêm HDD cắm vào con cũ, rồi extend cái volume đó ra sang ổ đĩa mới.

Và có vẻ là SMTP khi gửi client đã bắt tay TLS với server, nên thông tin không đọc ra được.
Xem log của postfix (Zimbra mặc định dùng cái này) xem nó báo gì không?

Em vốn là người hay nhìn và rút ra nhận xét 1 sự việc, sự vật nào đó.

Nhân rảnh rỗi đi dạo Internet, thấy website của ngân hàng Techcombank: http://www.techcombank.com.vn/
Được wwwect sang web chạy HTTPS, chứng thực mua của Verisign dạng EV.

Theo các bác, có nên hay không nên áp dụng HTTPS với website giới thiệu công ty (em không nói Internet Banking). Xét khách quan theo khía cạnh tiện ích, kỹ thuật và bảo mật về việc đó, không phải có ý chê bai gì.

Em thử điểm qua vài cái lợi và bất lợi, theo cá nhân em đánh giá:
Lợi:

Vào website của công ty sẽ thấy tên công ty hiện lên Address Bar nổi bật (nhờ cái EV Cert).
Thông tin từ website gửi tới khách hàng sẽ được mã hóa, đảm bảo không ai nghe trộm (thông tin 1 công ty gửi cho tất cả mọi người thì chắc là không cần). Và thông tin truyền đảm bảo xác thực đúng là từ công ty, không ai trung gian có thể thay đổi được (có vẻ cái này thì có có ích).

Bất lợi:

Web site chạy HTTPS sẽ tốn tiền, tốn máy móc hơn (Web Server phải mạnh hơn để xử lý SSL, phải tốn tiền mua Cert, EV Cert của Verisign cũng cỡ 2000$/năm, đủ tiền thuê 1 VPS/năm đấy).
Các kỹ thuật tăng tốc web, ví dụ browser caching, proxy caching mất tác dụng, đồng nghĩa là vào web site sẽ luôn phải tải lại hết toàn bộ nội dung, chậm và tốn đường truyền hơn.
Client (nhất là mobile client) truy cập SSL sẽ chậm và tốn ... pin hơn.
Không giúp gì cho website (web server) bảo mật hơn, vẫn có thể dính các lỗi SQL Injection, buffer overflow... hay có khi rủi ro hơn vì module SSL dính lỗi.
Vì SSL chạy chậm nên nếu bị DDOS chết sớm hơn so với HTTP là với cùng 1 tài nguyên máy chủ.
Các giải pháp IPS/IDS dạng network (trừ khi tích hợp IPS/IDS + SSL Accelerator) nói chung là sẽ vô nghĩa.

Các bác có thêm ý kiến nào bổ sung không ạ. Em đang phải suy nghĩ về việc setup 1 web site có cái yêu cầu tương tự.

Chủ topic đang nói cần OS cho nền tảng x86 mà cứ IBM AIX với HP-UX, Solaris chạy Sparc thì nói làm gì. Giá bọn đó thì cứ gọi là cắt cổ.

Quan trọng là: OS nào cho máy chủ x86 (ví dụ mua máy Dell, chỉ có mỗi cái loại này, như bác chủ Topic đang có).
Nói ngắn gọn chỉ có 2 lựa chọn ở VN và đảm bảo được cho enterprise:
- Windows Server hoặc
- RedHat Enterprise Linux thôi.

Nếu có quyền root của máy, lại vào được 2 dịch vụ quan trọng là FTP và Web.
Đơn giản là tớ up 1 con shell (đặc biệt) bằng FTP lên 1 thư mục web có thể execute script (ví dụ PHP). Lúc này có thể "gõ lệnh trên server qua web script". Cũng chả cần SSH vì web console cũng gõ lệnh như ai.
Nếu vẫn cần SSH thì có thể nhiều trò khác, đơn giản nhất là tunnel qua 1 proxy script chạy nền web là xong.

Bộ bạn đưa đề bài này ra, vì bạn có quyền root 1 con máy và trộm được quyền VPN vào mạng của Victim à?

CentOS có 5.7 rồi.

Không tìm thấy kernel image thì có thể đĩa hỏng (nếu đang boot để cài). Còn cài xong rồi khởi động lại vào HDD bị thì có thể vì mấy cái sau:
1. Nhầm đĩa, tức là máy có thể đang cắm nhiều đĩa (tỉ dụ USB disk) và cho nhầm phân vùng boot vào 1 cái USB nào đó, rút ra là tịt. Hoặc là bạn cài lên iSCSI Target nào à?
2. Phân vùng (volume) /boot chưa boot image phải thỏa mãn 1 số điều kiện đặc biệt:
1. là phân vùng độc lập, có thể là primary hoặc extended, không nằm trong LVM Vol Group nào cả.
2. nếu là raid mềm (mdraid) thì phải là raid1, ko support dạng raid khác,
3. phân vùng phải format dạng ext3 (hoặc ext4). Nết không grub nó không biết cách load đâu.

=> Nói chung khi cài, các bạn ít kinh nghiệm thì nên để CentOS nó tự chia đĩa. Đừng tọc tọe vào customize thì nó có thể ko boot được đâu.

Không có cái gì sướng hơn cài CentOS 5 hoặc 6 lên các máy chủ IBM xSeries. Không đau đầu về driver, không cần ServeGuide như cài Win (nhưng ServeRAID thì có thể cần ... 1 vài lần). Lại cài rất nhanh, chỉ khoảng 15 phút là đảm bảo có đồ chơi rồi.