Messages posted by: myquartz

Đúng đây, khi có quyền truy cập vật lý, cắm được màn hình bàn phím và tắt bật được máy thì ... làm gì cũng được hết.
Thế nên cái phòng server nó mới phải khóa kỹ, ra vào ghi sổ ký tá nhiều thế.

Solaris bản x86 không phải là bản được support cho enterprise. Nó nhằm mục đích cho quản trị viên Solaris có cái mà thực hành và không phải mua máy Sun chuyên dụng như là HP-UX hay IBM AIX.

Với x86 thì vote cho Oracle Linux hoặc RedHat Enterprise Linux. Với Ngân hàng thì độ ổn định và tin cậy là số 1, và phải được hãng support, đồng thời phải được certified về bảo mật (để còn qua được các kỳ kiểm toán). RHEL (hoặc Oracle là dẫn xuất của RHEL) đạt được tiêu chí này.
SuSE cũng được nhưng không thấy VN có partner nào có thể hỗ trợ.

Các bản free khác như debian, freebsd tuy cũng ổn định, an toàn, dùng cũng được nhưng nói chung lãnh đạo sẽ ko dám chọn đâu, vì chọn = tin vào admin => admin ở ngân hàng thì nhảy việc không phải ít => admin đi là mọi thứ đi theo, hoặc anh ấy bị bịnh không đến công sở được => ko có người bảo lãnh như hãng (RedHat or Oracle). Nên nhớ trong ngân hàng người ta "tin" nhau phải có cơ sở bằng chứng pháp lý chứ không nói mồm khơi khơi được đâu.

Đang thắc mắc nữa 3 cái database server chạy Oracle thì bạn có định dùng Oracle RAC ko nhỉ? Nếu có RAC thì phải có SAN (chắc là Dell??), các OS như debian hay freebsd mình cá rằng không được hãng sản xuất SAN,HBA support tốt như Oracle Linux hay RHEL đâu, và cài cắm cái đó vào server là cả 1 vấn đề đấy.

Ở phía client của bạn truyền lên server có thể quá MTU mà không nhận biết được, PathMTU Discovery không work như mong đợi.
Lỗi này có biểu hiện y chang như bạn mô tả.
Cách xử lý là ... google, fix cứng giá trị MTU của client nhỏ hơn xem.

Tớ vote cho bài này là 1 dạng quảng cáo.

FB, Gmail và Yahoo áp dụng cái này giờ khó rồi.
Đơn giản là hãy dùng HTTPS, cả 3 site trên đều cho phép bật mặc định dùng HTTPS. Mã hoá rồi thì man trên giời cũng ko middle được (dĩ nhiên cũng phải biết tí chút là khi nào SSL Cert bị giả mạo và trình duyệt từ chối nhé).

phuongnvt wrote:

Vấn đề này thấy rõ nhất là trong lĩnh vực viễn thông (cụ thể là điện thoại di động).Khi bạn chuyển vùng từ trạm BTS này sang trạm BTS khác.
ah sẵn đây cho tui hỏi về vấn đề roaming tí xúi, ví dụ tui đang ở vùng giao thoa giữa 2 trạm BTS thì liệu tui sẽ bắt sóng của trạm BTS nào ? vì sao ?

Tớ không phải là dân viễn thông, nhưng thấy cậu bạn chuyên viễn thông nói lại là có thể cả 2 BTS. Nó gây ra hiện tượng có tiếng vọng (của mình) 1 chút. Nhưng nó diễn ra trong thời gian ngắn thôi, khi switch sang BTS kia hẳn.

To khigiadano: bạn chỉ cần đặt giá trị SSID các AP giống nhau (thằng nào cũng có chỗ để đặt cả), và chỉ dùng 1 cái DHCP cho cái mạng LAN đó và nối chung các AP vào 1 subnet. Lưu ý là đừng nhầm AP và Wifi Router nhé (xem trang linksys thì dòng AP có mã hiệu WAP, như là WAP610N).

Không cho ứng dụng chạy quyền admin nữa.
Hoặc cho nó vào cái máy ảo, không có số seri HDD là hết đọc.

Các thiết bị Wifi controller để nhiều AP và 1 SSID (roaming) đều đắt lè lưỡi, không phù hợp với quy mô nhỏ hoặc gia đình.
Bạn vẫn có thể config để nhiều AP chung 1 SSID, tuy nhiên vấn đề là khi nó chuyển sóng sang AP khác, thì kết nối bị tạm thời đứt, YM đang chát văng ra (trừ khi laptop bạn dùng OS là Mac hoặc Linux). Wifi Controller nó giúp cho không bị hiện tượng trên.
Dù sao cách đơn giản này vẫn giúp tăng vùng phủ sóng lên. Tớ đã thử áp dụng với 2 AP. Lưu ý là không để máy ở nơi mà sóng của 2 AP kia cường độ gần như nhau thì hiện tượng up/down nhảy sóng rất nhiều. Nên để AP xa xa nhau sao cho chỉ thu được 1 cái thì ổn.

CPU đời mới của Intel có sẵn cảm biến nhiệt độ ở trên chíp. Chương trình có thể đọc được giá trị này.
Cái cảm biết đó gọi là Digital thermal sensor thì phải. Và nó cần để điều khiển cái quạt làm mát CPU, chạy càng nóng thì quạt càng mạnh.
Ngoài ra còn hàng loạt các cảm biến nhiệt khác nữa tuỳ thuộc mainboard hoặc linh kiện, ví dụ nhiệt của thùng máy (gắn trên main), nhiệt của ổ cứng (nhiều ổ cứng có gắn sẵn)...

Sửa cả 2, sửa cả netmasks để có tác dụng khi reboot lại (nếu có), ifconfig để có tác dụng ngay lúc đó cho đến khi reboot (reboot rồi thì sửa cái file kia là ok).

Cách bạn làm ra 1 Console server đó, về mặt bảo mật thì chính cái Console đó là mắt xích quan trọng nhất. Nếu nó share nhiều người dùng (nhiều admin), việc truy vết 1 ai đó vào Console server rồi ghi lại họ đã làm gì khác (ssh hay vnc, terminal vào server khác) sẽ rất khó khăn, tốn kém. Chưa kể nếu Console server bị compromised thì việc nhập mật khẩu xác thực bước kế tiếp vào đó ko ổn tí nào.
Tớ thấy end-to-end là an tâm nhất, tức là chỉ trust vào cái laptop và cái server, mọi thứ trung gian đều ko tin tưởng.
Mình chỉ áp dụng cái Console server khi cái kết nối thứ 2 là vật lý. Ví dụ console server có nhiều nối dây serial (com) với router trực tiếp, mình ssh vào console server rồi minicom vào tty nối với router thì mới hợp lý.

Về cái mô hình bạn làm ấy, người ta có 1 cái tên gọi là out-of-band remote control hoặc out-of-band management.
Cách mình làm là dựng lên 1 hệ thống private network chỉ sử dụng để quản trị server, độc lập về mặt vật lý với mạng chính (có kênh Internet, VPN gateway riêng, và switch, UPS cấp nguồn... cũng độc lập, tách rời hoàn toàn), và các admin dùng laptop của mình VPN vào mạng private đó trước rồi mới vào được các IP của các server quản trị qua SSH hoặc VNC, RDP. Các máy chủ hầu hết là có 1 management ethernet port riêng cả (dùng để quản lý 1 số phần hardware trước khi boot OS), và server có nhiều ethernet port thì dùng tách riêng 1 interface chỉ để quản trị, phân biệt với các cổng khác chỉ là cung cấp dịch vụ.

Mình cũng có các console server nhưng chỉ dùng để kết nối serial/khác với các thiết bị non-IP (ví dụ hệ thống cung cấp điện, hệ thống chữa cháy, hay là router, switch, tổng đài nội bộ), hoặc là dùng IP KVM nối console trực tiếp vào các server. Console server không bao giờ có thể truy cập tới nếu không vào cái private network đó và phải làm sao để phòng khi mạng chính bị đứt vẫn có kênh riêng vào private network hoặc có cổng dial-up vào được, hoặc có kênh 3G riêng. Do DC cách văn phòng làm việc cả mấy chục km ấy chứ, không phải lúc nào cũng chạy tới mà coi được.

Nếu xài Switch của Cisco, hình như nó có chức năng là DHCP Snooping đấy.
Bind MAC và IP trên DHCP server cố định. Thì client cắm vào sw bắt buộc phải cấp IP qua DHCP Server (được chỉ định) và nếu tự đặt tĩnh, gán lung tung hay kể cả ARP spoofing thì đều không thể vào mạng được.
Cái giá là tiền hơi nhiều 1 chút.

Nếu muốn transparent proxy thì chèn vào giữa con draytek và switch 1 cái server (dĩ nhiên, 2 card mạng, 1 vào sw và 1 vào draytek). Đơn giản nhất là chạy Linux và thiết lập iptables + squid để cache/filter.
Nhưng vì draytek còn làm việc nhiều hơn 1 cái router/NAT, là DHCP Server và có khi cả DNS Forwarder. Do đó 2 chức năng này phải chuyển qua con server đó để làm.
Còn về load balancer thì vẫn để con draytek làm. IP Sec VPN thì phải thay đổi 1 chút để thiết lập định tuyến của con Linux sao cho nó route được mạng nội bộ đến R0 (or R1) và ngược lại subnet VPN đầu xa đến R2. Draytek thay vì route mạng nội bộ đến R0 thì thay bằng đến server. Nếu giữa Draytek R2 và R0 hiện tại lại chạy định tuyến động (ví dụ RIP), thì có khi con Linux cũng phải lặp lại cái vai trò đó (cài RIP router daemon- lâu ko nhớ tên cái nào hay trên Linux).

Còn nếu cậu bỏ cái yêu cầu transparent đi, thì công việc đơn giản hơn (nhưng sẽ tốn công hơn): chỉ cần cài Linux + squid (or Win + ISA), thò 1 chân xuống mạng LAN (nghĩa là chỉ cần 1 lỗ mạng cắm vào sw). Sau đó đi config tất cả client trỏ proxy đến con đó là chạy được. Việc routing + IPSec VPN + DHCP... ko phải thay đổi gì cả. Có thể nếu bắt ép người dùng phải chạy proxy thì phải đặt mấy cái filter trên con Draytek sao cho chặn port 80 và 443 để mọi người ko đi trực tiếp được (và chỉ trừ IP của con proxy là đc chạy tất).

Thử mount thay vì vào /share/dulieuweb, thì mount vào /var/www/share/dulieuweb xem?

Đấy bạn khang0001 thấy không? Phương pháp bảo mật như bác conmale đã giải thích cho bạn nó là phương pháp cân bằng đấy. Không cố sức chroot cho apache nếu như ... nhiều có cái khác quan trọng hơn.
Vấn đề là thời gian, sức lực có hạn, nên dành nó cho những phần quan trọng và không có ai ngoài bản thân bạn phải làm. Chứ giờ bỏ công đi compile lại những gì thiên hạ đã làm thì rất tốn công. Cứ tạm thời tin tưởng đám kỹ sư của RedHat khi họ đóng gói các package, và dành thời gian ra xem code php và sql của web site của mình => phát hiện lỗi để sửa => thì sẽ cân bằng sức lực và sẽ hiệu quả hơn là làm lại việc của người ta đã làm (và được đánh giá là rất tốt rồi).
Khi nào bạn có đủ tài nguyên, ví dụ có hẳn 1 đội 10 người chuyên trách, quần thảo hết các khía cạnh rồi, thì hẵng quan tâm đến cái kia.

Giải thích giùm cho đề bài là "update dữ liệu thường xuyên". Cái từ này nó sẽ giúp quyết định xem nên làm thế nào đối với trường hợp đó.

Bỏ cái dòng Gateway định nghĩa trên eth2 là hết ảnh hưởng. Nó sẽ chỉ dùng gateway được cấp phát bởi DHCP của eth1.

Nói một cách chi tiết hơn, Linux nó thực hiện up cái interface theo thứ tự tên khi khởi động máy. eth1 lên trước, được cấp IP từ DHCP và có gateway ok. cái eth2 lên kế tiếp, nó đặt IP cho eth2 nhưng lại thêm cái việc đặt gateway như bạn khai báo và nó bỏ đi cái eth1 được gán ở thời điểm trước. Trong thiết lập bình thường thì máy Linux chỉ có 1 gateway duy nhất (default route) và nó gắn vào eth1 hay eth2 tuỳ theo thứ tự cái nào sau thì ghi đè cái trước. Bỏ gw trên eth2 sẽ không có gì ghi đè cả. Gõ lệnh ip route list để thấy được bảng định tuyến của nó.

Câu chuyện của bác conmale có thể cải biên thành thế này (just joking).

Một bác già vào tiệm bán xe hơi. Hỏi người bán hàng: chú cho tôi hỏi, tôi nên mua cái xe Civic cũ năm 2007 hay là mua cái xe đời mới năm 2012. Mục đích của tôi là để xài chạy ngoài phố thôi. Tôi nghe nói xe năm 2007 có giá trị lắm, nhiều người đang xài và khen nó. Cái năm 2012 mới quá sợ không ổn, lái không quen, vả lại ngại nhất là bằng lái xe của tôi không phù hợp lắm...
Người bán hàng hỏi: bằng xe của bác là bằng gì mà không phù hợp ạ?
Trả lời: bằng xe môtô 2 bánh chú ạ smilie

).

Bạn chạy perl trên Win. Nó thiếu module. Module ko phải copy file vào như thế vì có thể thiếu các thư viện DLL của nó (nếu module load cái thư viện đó).
Nếu dùng ActivePerl (mọi người thường dùng). Thử dùng lệnh ppm (Perl Package Manager), rồi vào đó gõ install HTTP::WebDav xem.

lệnh du bỏ cái max-depth đi
thay bằng lệnh này xem: du -sch /*

Bài toán này là ông thầy kiểm tra các bạn kiến thức về IP trong mạng Ethernet (LAN) đấy.
Lời giải cũng không khó nếu ai đào xới trong các protocol của TCP/IP stack, lưu ý là chỉ cần chú ý tới layer 3 (IP) thôi nhé, chứ không bridge 2 cái interface của PC2 vào nhau thì không tính. Nó vẫn là layer 3, routing hẳn hoi giữa 2 subnet bị overlap nhau (hay cùng subnet như ví dụ cũng không sao) thông qua PC2.

Tớ gợi ý 1 tí: từ khoá là 1 từ liên quan đến ARP.

Dĩ nhiên là PC2 chạy hệ thống Linux hoặc tương tự.

Không nhất thiết compile thành module (dynamic) rồi thì nghĩa là khi khởi động httpd lên nó sẽ dùng module đó.
Phải có lệnh LoadModule trong file config thì module mới được load lên và sử dụng. Mặc định thì httpd nó khai báo load tất cả các module chuẩn của nó (ngoài các module compile static gắn sẵn, chỉ có ít thôi), mình ko xài module nào thỉ comment dòng load cái đó bỏ đi là xong. Vừa nhẹ bớt cho httpd vừa tránh các lỗi bảo mật.
Người ta thường chỉ compile lại để thay đổi 1 số tham số khác nhau và để dùng các module đặc biệt, chứ ngược lại bỏ bớt thì chả cần làm vậy.

Dưới dây là các module tớ thường cho load (và ko load) cho 1 PHP web.
Code:

LoadModule auth_basic_module modules/mod_auth_basic.so
#LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_alias_module modules/mod_authn_alias.so
LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_default_module modules/mod_authz_default.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
#LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
#LoadModule dav_module modules/mod_dav.so
#LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule info_module modules/mod_info.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule actions_module modules/mod_actions.so
#LoadModule speling_module modules/mod_speling.so
#LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule cache_module modules/mod_cache.so
#LoadModule suexec_module modules/mod_suexec.so
#LoadModule disk_cache_module modules/mod_disk_cache.so
#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule mem_cache_module modules/mod_mem_cache.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule version_module modules/mod_version.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
#LoadModule asis_module modules/mod_asis.so

Bạn Khang chăm chỉ tiến lên với apache linux nhỉ? vẫn tiếp tục với cái đề tài làm sao bảo mật PHP web source kia à?
Bạn cứ ngâm cứu apache, module của nó. Và tiếp 1 thời gian tự compile, build, tự cài theo ý mình... bạn sẽ đúc rút rằng có 1 cách nhanh hơn mà hiệu quả cũng ko hề thấp hơn cái cách làm manually kia (về bảo mật nhá).
Nếu dùng CentOS, hãy yum install httpd, nếu dùng ubuntu thì sudo apt-get install apache2.

Cách mà khang0001 hỏi về việc bảo vệ cho 1 web server (hoặc quy chung là 1 hệ thống server trương mặt ra Internet), phòng khi nó có lỗi bảo mật (tiềm ẩn) nhưng chưa kịp vá hoặc bên cung cấp chưa kịp/chưa biết để cung cấp bản vá. 1 loại trong các lỗi kiểu như thế người ta thường gọi là zero day vulnerabilities (http://en.wikipedia.org/wiki/Zero-day_attack) và nó rất nguy hiểm.
Có nhiều cách chống/giảm tác hại của tình huống này. Tuy nhiên phải phối hợp nhiều biện pháp may ra mới bớt được và việc này tốn kém (tiền của + công sức), không dễ dàng lắm và phải làm liên tục.

Sau đây là mấy gợi ý cho trường hợp của bạn:

1. Về con người: dùng sản phẩm nào thì phải theo dõi nó thường xuyên thông tin lỗi về nó từ nhà sản xuất và các diễn đàn/trang tin tức bảo mật liên quan. Khi có bug được báo cáo nhưng chưa kịp vá, thường thì sẽ có chuyên gia đưa ra vài khuyến nghị để có thể tạm tắt, tạm sửa hoặc cách nào đó để vô hiệu hoá, chờ cho đến khi bản vá phát hành. Web chạy PHP thì khá dễ dàng để vá 1 lỗi bảo mật nào đó. Cái này hạn chế lỗi không phải là zero-day, nhưng với mã nguồn mở + sản phẩm rất phổ biến thì zero-day bug sống thường rất ngắn ngủi, ta hi vọng nó ko rơi rủi ro vào ta.

2. Về hệ thống máy chủ + phần mềm: nên tuân theo các hướng dẫn "hardening" hệ thống, làm triệt để (có nhiều hướng dẫn trên HVA lắm), hoặc lựa chọn các hệ thống nền tảng có khả năng an toàn và phù hợp hơn (Linux thay vì Win). Cái này để giảm rủi ro dù PHP có bị lỗi ở source thì tác hại cũng nhỏ, chỉ ảnh hưởng 1 chút chứ ko lây nhiễm toàn hệ thống. Ngoài việc hardenning với php.ini (rất nhiều hướng dẫn trên HVA), thì web server, OS cũng cần quan tâm. Với Win thì tớ ít thấy có cách nào bảo vệ tốt để chạy PHP, nhưng với Linux + Apache thì kha khá nhiều tài liệu có thể tìm thấy trên Internet. Ví dụ áp dụng SELinux, áp quyền directory/file nghiêm ngặt, áp dụng suexec cho cái phần web PHP + chạy php_cgi thay vì chạy mod... Hi sinh vài thứ để đạt được độ bảo mật cao hơn.

3. Về bảo vệ vòng ngoài (mạng): Firewall nó ít tác dụng vì nó hoạt động ở lớp 3,4. Cái bảo vệ vòng ngoài duy nhất giúp ích được ít nhiều trong trường hợp này là cái IPS (tất nhiên phải mua quyền cập nhật rule cho thiết bị). Đa số các nhà cung cấp IPS thường làm ra rất sớm rule nhận diện và chặn nguy cơ bảo mật dựa trên dấu hiệu tấn công của lỗi, khi mà bản vá lỗi đó còn chưa kịp phát hành. Tất nhiên là hên xui thôi, không phải lúc nào họ cũng nhanh hơn. Nhưng có thì tốt hơn, giảm rủi ro. Điều đáng buồn là chi phí IPS + update thường ko rẻ lắm so với 2 cách trên và chỉ là phương pháp bổ trợ cho 2 cách trên. Nếu chỉ dựa vào IPS thì có ngày ko chết bởi lỗi chưa có bản vá mà sẽ chết bởi lỗi đã có bản vá từ lâu rồi mà chủ server ko thèm áp dụng, IPS lại thiếu sót, hệ thống ko được harden...

4. Các biện pháp khác giảm thiệt hại (sau khi sự việc xảy ra): backup hàng ngày, theo dõi thường xuyên hoạt động hệ thống và log file phát hiện bất thường, vá bản vá nhanh nhất có thể (cho tất cả các thứ liên quan)...

Hi vọng nó không quá rối rắm. Lưu ý nó sẽ ko đảm bảo tuyệt đối 100%, nó chỉ giảm rủi ro đi thôi. Hãy luôn nghĩ đến giải pháp dự phòng (backup/restore) và có sự đầu tư con người, tiền của ... mới mong nó ít tác hại. Một số anh em làm bảo mật ăn tiền (lương) cao nhờ mấy cái công việc phòng chống cái lỗi tiềm ẩn trên đấy, ví dụ mấy tay bảo mật ngân hàng đấy, vì lỗi tiềm ẩn là không thể tránh khỏi và nếu xảy ra tác hại quá lớn nên ngân hàng thường bỏ nhiều tiền chỉ để làm giảm rủi ro.
Nếu chỗ bạn việc chết web 1 vài ngày ko thành vấn đề thì có thể ... bỏ qua. Nếu bạn chỉ muốn học cách, thì cứ tiếp tục ... đào xới kỹ thuật thêm 1 số năm nữa, cỡ chừng anh conmale thì may ra tự tin (cao thủ như anh conmale cũng có lần xảy chân nữa là, nên ko có gì là tuyệt đối cả nhé).

P/s: có thể bỏ qua các post của aod vì nó ít giá trị kiến thức.

conmale wrote:

myquartz wrote:

Không ngờ nhiều hacker non trẻ ngoài tay nghề IT ra mà ngón nghề chửi cũng không thua gì các bậc tiền bối ngoài chợ.
A-di-đà-Phật, thiện tai, thiện tai. Thôi thì quảng gánh lo đi mà vui sống các bác ạ, dẫu phận đời đen bạc, thật giả lẫn lộn...

Lạ thiệt. Những trò ăn cắp, lừa đảo, xâm phạm máy tính cá nhân, phát tán virus, tấn công từ chối dịch vụ..v...v.. đó là chưa kể những trò "bạch hoá" bằng cách thêu dệt, bêu rếu, lăng nhục kẻ khác đều là những trò không những vi phạm pháp luật trầm trọng mà còn là những hành vi phi đạo đức, vậy mà từ trước đến giờ bạn myquartz có bao giờ lên tiếng phê bình những trò bại hoại này đâu? Trái lại, những kẻ phê phán (hoặc chửi bới) những trò bại hoại ấy thì bạn myquartz lại nhảy vô mà chụp cái mũ "nghề chửi"? Bạn đang gián tiếp cho rằng những việc làm bại hoại kia không đáng để chửi và những người đang chửi những việc bại hoại là đáng khinh bỉ?

Bạn có bị đụng chạm, bị tấn công, bị hư hại, bị mất mác đâu mà không thản nhiên? Bạn nghĩ rằng ai đó phá hoại bạn, phá hoại cả một cộng đồng bằng đủ thứ trò thô bỉ và ti tiện đi chăng nữa cũng nên "quảng gánh lo đi mà vui sống"? Xin lỗi bạn, đối với tớ, đây cũng chỉ là một thứ lập luận bullshit. Phận đời đen bạc khỉ gì đây? Ở đây chỉ có một bọn phá hoại bao nhiêu năm nay nhưng tất cả các cơ quan chức năng, báo chí, thông tin đều làm ngơ và một bọn chống lại bọn phá hoại bằng khả năng và điều kiện ít ỏi mà thôi. Ai đó tới nhà bạn, đập phá nhà bạn, bêu rếu bạn và bạn cắn răng mà ta thán rằng "phận đời đen bạc" rồi cam chịu? Xin lỗi bạn, đây là thái độ bạc nhược hoặc không trung thực (vì con người không phải là những con liu điu chỉ biết cúi đầu chịu hèn).

Tớ không thể tin nổi là cả một quốc gia mà lại hoàn toàn im ắng trước sự tấn công triền miên tới vietnamnet. Chỉ cần hốt một mớ log trên hệ thống của vietnamnet, chọn ra một mớ IP addresses rồi liên hệ với ISP để trace ra máy con bị nhiễm malware. Đến vài nơi để lấy mẫu malware, re xong là liên hệ trực tiếp với data center của masterbot. Chỉ cần lấy tư cách vncert chớ đừng nói chi cơ quan an ninh thì các data center sẵn sàng cung cấp thông tin cần thiết. Chộp ra 1 ông thì cách gì mà không lòi ra cả đám?

Những phê phán về khía cạnh đạo đức ở đây trực tiếp đi từ những kết quả kỹ thuật mà ra. Kỹ thuật cũng có đạo đức và phi đạo đức. Kỹ thuật mà không có yếu tố đạo đức thì chẳng khác gì những thằng người máy làm theo chương trình ấn định sẵn. Hãy làm con người và đừng làm người máy!

Kính bác, em ko ngờ bác lại viết ... dài đến thế.
Hehe, quan điểm của em đơn giản lắm, có thể gọi là mũ ni che tai cũng được, nhưng thực dụng và không làm gì tốn công vô ích. Em theo đạo Phật nửa mùa và hiểu 1 số điều: có nhân và có quả. Gieo gió ắt gặt bão. Từ lâu em đã quan niệm XH Internet là 1 kiểu tương tác của XH loài người, sẽ có người tốt, người xấu và đó là 2 cái thiện ác đấu tranh cùng tồn tại như Phật đã dạy. Như thế đi chửi XH nó đầy người xấu cũng như lên Internet chửi bọn xấu thôi, vô ích, tốn nước bọt. XH phải có người xấu và phải có như thế mới tồn tại XH. Và hơn nữa, trong 1 người có thể tồn tại cả 2 hình thái thiện/ác, tốt/xấu lẫn lộn đó. Người chửi STL tưởng là mình làm việc tốt nhưng cái xấu chính là việc "chửi", ngược lại STL làm nhiều chuyện xằng bậy trên Internet nhưng chắc họ cũng có mặt tốt nào đó mà chúng ta ko biết.

Dù sao em cũng vẫn theo sát topic của bạn TQN, xem xem có gì mới trong kỹ thuật của STL để mà học hỏi. Kiến thích này có ích nha, áp dụng nó vào công việc => giảm nguy cơ bảo mật => thu lợi (vì người ta đang thuê mình bảo vệ công việc kinh doanh - ko phải bảo vệ chính trị đâu nha). Em nghĩ các bạn kỹ thuật nên tập trung vào kỹ thuật để học hỏi hơn là phán xét chửi rủa.

P/S: chú thích thêm tí đại ý của em là lên Internet là phải chấp nhận một môi trường không an toàn, luật lệ lỏng lẻo, đầy DDOS, đầy rẫy virus hay lắm kẻ nhòm ngó. Sống chung với lũ và biết cách chế ngự nó, đề phòng, tránh nó hơn là ngồi đó than vãn, quy chụp người Việt thế này, yêu nước thế kia...

Công ty nhỏ (<= 50 người), tự host mail là phí sức và tiền của mà lại không đạt chất lượng cao.

Lý do:
1. Đường cáp quang giá bèo thì thì IP tuy là tĩnh nhưng sẽ nằm trong dải broadband-user dễ không được gửi mail trực tiếp từ IP đó hoặc hay bị các hệ thống mail nổi tiếng khác coi là spam. Việc làm reverse DNS và các động tác kiểu như thế rất tốn công sức. Trừ khi có thêm 1 subnet khoảng 8 IP thì may ra đỡ mệt hơn.
2. Mất công sức + tiền của để duy trì mail server và tính sẵn sàng của nó. Như việc backup chẳng hạn. Với quy mô 30 người 1 năm có thể lên đến 30GB mail => backup nó hàng ngày cũng không phải ko tốn tiền.
3. Chống chọi với virus và spam mail, rồi lại vô số các nguy cơ bảo mật tấn công vào hệ thống mail của mình => tốn 1 ng chuyên trách lo lắng.

Cách hay nhất: Google Apps. Có tất cả các thứ trên mà lại rất tốt. Trừ trường hợp đặc biệt có lý do. Ví dụ Google Apps nó không cho phép thông qua nó để gửi mail quảng cáo hàng loạt (limit 500 địa chỉ/1 ngày).

Không ngờ nhiều hacker non trẻ ngoài tay nghề IT ra mà ngón nghề chửi cũng không thua gì các bậc tiền bối ngoài chợ.
A-di-đà-Phật, thiện tai, thiện tai. Thôi thì quảng gánh lo đi mà vui sống các bác ạ, dẫu phận đời đen bạc, thật giả lẫn lộn...

Cảm ơn bạn. Đúng là lệnh mình cần.

P/S: à cái này nó nhiều hơn cái mình cần 1 tí, đó là nó cho ra cả stdout.

Thử OCS Inventory xem.
Đấy là máy đang chạy ta deploy thêm.

Có cách khác:
Mình ko dùng OpenSuSE, nhưng dùng CentOS. Cách mình "ghost" hàng loạt máy mới là cài theo kịch bản kickstart. OK 500 máy đã xong rồi, chạy rồi.
Máy đang chạy ko muốn cài lại mà lại muốn "thêm package", thì mẹo của mình khi dùng 1 local yum repo chứa tất cả các package cần thiết (A,B,C). Các client khi ghost có 1 local yum repo + thiết lập tự yum update cho client hàng ngày.
Và 1 cái package quan trọng, đặc biệt gọi là "buss-suite" chả chứa gì nhưng require nhiều package kahcs. buss-suite sẽ Requires các package A,B,C cần cho user. Cài buss-suite sẽ kéo theo cài thêm A, B, C luôn.

Giờ tự nhiên muốn thêm D. Thì cách làm là build D, và build lại buss-suite với nâng thêm số phiên bản, có require thêm D. Rồi đưa rpm lên local yum repo.
Khi các client update, nó thấy có buss-suite mới thì tải về và cài, nhưng để cài cần thêm D => nó tự tải thêm D về cài thêm. => có thể thêm bất cứ package nào bằng cách sửa buss-suite.
Nếu khéo làm spec của RPM, cũng có thể remove luôn cả package (ví dụ A) khi tự update.

Đấy là họ nhà yum, họ nhà apt mình nghĩ cũng áp dụng cách đó được.

Hello linux fans!
Mình làm linux/unix khá lâu rồi. Nhưng cái này có lẽ cũng ... chưa được biết.
Ai cũng biết cat là lệnh đọc file (có thể là stdin) rồi đưa ra stdout. Đầu bài của mình có thể giải bằng lệnh cat hoặc các lệnh tương tự bằng cách wwwect stdout ra thành file, lệnh như sau:

Code:

cat - > test

Tuy nhiên, với 1 số điều kiện, mình không thể dùng > để định lại hướng ra của stdout (nhưng vẫn định hướng stdin được thông qua pipe bằng dấu | ), lúc này cách dùng cat hay bất kỳ cách nào dùng đến dấu > để write file đề không áp dụng được cả.
Mình chợt thắc mắc là sao cộng đồng Unix/Linux không nghĩ đến/không cần lệnh nào ngược với cat: đọc từ stdin và ghi thành file nhỉ. Kiểu như:
Code:

echo "test" | inputcat test