Messages posted by: myquartz

Cũng cái hình vẽ trên, nếu vật kết nối trung tâm là Hub (đời cũ, không thông minh) thì có thể gọi đó là Bus. Còn nếu vật đó là Switch, thì đó là Star. Bus đời cũ nữa mới là dây đồng trục nối liền các card mạng.

Hiện tại mạng Bus trong kiến trúc mạng lẫn máy tính người ta dần không dùng nữa vì Collision (xung đột) của nó rất cao, tuy tiết kiệm linh kiện, thiết bị rẻ tiền hơn. Tất cả giờ hầu hết đều là Star. Về ví dụ thực tế, khó kiếm cái nào còn dùng mô hình đó.
À, có 1 ví dụ chính là Wifi. Wifi chính là kiến trúc mạng Bus, sóng wifi 1 điểm phát ra không khí thì tất cả các end-point gần đó đều nhận/thu được. Không có chuyện 2 end-point cùng phát một lúc vào 1 channel (1 dải tần), sẽ xung đột nhiễu sóng. Mạng wifi cũng chia sẻ băng thông của 1 channel y như mạng dây đồng trục. Cái share nhau (tức là cái bus) giữa cái Wifi end-point chính không gian gần nhau và cùng channel được chọn sử dụng.

P/S: chủ topic nếu học và viết báo cáo ở trường, thì nên theo lời của mrhoangha ở trên, ở 1 phạm vi hẹp ở network. Trả lời của tớ chỉ là tham khảo để hiểu bản chất về cái gọi là bus hay star thôi, chứ khái niệm học thuật nó cũng mang tính ước lệ, đơn giản cho dễ hiểu. Thực tế cái tưởng là star thực ra nó là bus (trường hợp cái hub).

Nói 1 cách ngắn gọn: chia VLAN là phân chia mạng LAN ở layer 2 (data link), do switch hoặc Ethernet Interface đảm nhiệm. Còn Subnet là phân chia mạng nhìn ở layer 3 (network), do TCP/IP stack thực hiện.

Lâu không đọc lại bài viết này. Có thêm 1 ít í kiến:

NAS và SAN hiện tại nó tiệm cận tính năng với nhau. NAS như NetApp giờ cũng có cổng FC, và SAN của Dell/EMC, HP hay IBM giờ cũng có module mạng với Gigabit LAN. Còn lại thì tính năng cũng hỗ trợ đa dạng như nhau thôi.
Tuy nhiên NAS thiên về mặt "file share", còn SAN thì mạnh hơn về "Shared Block Device". FC hay LAN giờ cũng chỉ là phương thức kết nối (khác nhau đắt or rẻ tiền). Trừ ra LAN cho phép hỗ trợ File Share còn FC thì không (hoặc có nhưng chắc không dễ xài đâu).
Do đó, nếu mục đích của bạn là File Share, NAS sẽ hiệu quả hơn (về mặt tốc độ), tiết kiệm tiền hơn, và sự đảm bảo về redundant cũng tương đương (cũng 2 controller, cũng multi-path, đĩa cũng RAID và đặc biệt đĩa loại FC thường dùng cho SAN cũng đc support).
Với mục đích block device, NAS cũng làm được (và tốt) nhưng thua SAN.
Ngược lại SAN thua NAS về file share (nếu dùng trực tiếp, chứ ko tính có thêm 1 vài cái server cực mạnh ở giữa thì NAS thua).

Và quá lâu rồi, một số thông tin không up2date lắm.
Dạo này phong trào đào mộ ở HVA có vẻ rầm rộ nhỉ?

Nói về mặt kỹ thuật, thì XMPP an toàn (mã hoá TLS/SSL) và mở (nhiều soft client/server, mã mở mã đóng có hết nếu ko tin tự viết riêng).
Skype được biết cũng được cho là an toàn (cũng có mã hoá) và hiệu quả, nhưng lại đóng (chương trình của nó bố ai biết nó làm gì bên trong). Protocol này cực đóng nên ngoài Skype client ra chả còn cái nào khác.
YMSG kém an toàn (phiên bản mới hiện tại việc xác thực đã qua HTTPS, nhưng chat chit hay webcam vẫn lồ lộ không mã hoá). Protocol này cũng hơi đóng nên ít client hỗ trợ tốt được như YM.
Các cái khác không ngâm cứu không biết.

Kết luận: tớ thấy Gtalk dễ xài hơn cả, chuẩn mở + nhiều tính năng + an toàn.
YM thì quá phổ biến ở VN nhưng nay có vẻ lép vế.
Skype chất lượng tuyệt nhất nhưng cũng cũng vừa lòng chuyên gia bảo mật.

Đã xem lại.
Web Server của bạn chắc chắn có vấn đề, bị xâm nhập hoặc bị wwwect có điều kiện. Bạn hãy xem đoạn capture này:

Code:

GET /ksjdflskdf HTTP/1.1
Host: dteahleo.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.6.13-1.fc14 Firefox/3.6.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: vi,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 115
Connection: keep-alive
HTTP/1.1 302 Found
Date: Sat, 01 Jan 2011 16:17:33 GMT
Server: LiteSpeed
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
Location: http://www.google.com.vn/#sclient=psy&hl=vi&q=hoc+sinh+thpteahleo&aq=f&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=986b226ed7ee6cfa
Content-Type: text/html
Content-Length: 389

Mình cố tình get 1 URI chắc là không tồn tại trên server đó (GET /ksjdflskdf), dùng Firefox thì bị trả về cái Location như trên. Nội dung location là cố ý query cái chuỗi "hoc sinh thpteahleo".
Nếu dùng wget hoặc Chrome, hoặc telnet nhưng đổi cái User-Agent sang cái khác thì không gặp vấn đề này.
Xem:
Code:

GET / HTTP/1.1
Host: dteahleo.com
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: bb_lastvisit=1293898611; bb_lastactivity=0; AVIM_on_off=1; AVIM_method=0; AVIM_ckspell=1; AVIM_daucu=1
HTTP/1.1 200 OK
Date: Sat, 01 Jan 2011 16:25:22 GMT
Server: LiteSpeed
Connection: close
X-Powered-By: PHP/5.2.13
Set-Cookie: bb_lastactivity=0; expires=Sun, 01-Jan-2012 16:25:22 GMT; path=/
Cache-Control: private
Pragma: private
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Content-Length: 31727

Không rõ server LiteSpeed là server nào? thuê share host?

Query mà có mấy cái LIKE %xxx% kia và lại có cả OR thì tớ sợ lắm. Câu đó kiểu gì cũng tốn CPU hoặc IO vì nó phải lấy cả table ra so sánh.
Nên ép chủ cái trang có câu đó sửa lại, không được LIKE mà phải là = (hoặc hạn chế like), hoặc chí ít thì LIKE "prefix%" chứ ko được LIKE "%xx%".

Một là các đồng chí không nên đào mồ topic.
Hai là các vấn đề này nên đọc kỹ và hiểu về TCP/IP, thì sẽ không có gì thắc mắc nhiều.
Ba là tớ nhầm DrDOS, tưởng là Doctor DOS (Disk Operating System), tên của 1 hệ điều hành cũ, nên click vào, và vào thì cũng nên reply lăng nhăng 1 tí.

Đang xài SSD, cài Fedora 13, rất mỹ mãn về performance.
Để giảm tác hại việc ghi/xoá file temp/log, tớ sửa file /etc/sysconfig/readonly-root và thay tham số như thế này:
Code:

# Set to 'yes' to mount various temporary state as either tmpfs
# or on the block device labelled RW_LABEL. Implied by READONLY
TEMPORARY_STATE=yes

Từ nay, chỗ lưu mọi file log và temp đều được Fedora tạo trên RAM mỗi khi khởi động. Dĩ nhiên là RAM phải lớn 1 chút không thì sẽ thiếu temp space cho nhiều tác vụ (RAM của tớ là 2.5GB).

conmale wrote:

Hì hì, thấy vậy mà khác đó em .

grep đọc từng dòng trong file để match pattern.

cat đọc trọn bộ nội dung file.

Nếu cat trước rồi mới grep thì grep sẽ tìm các matching pattern của thông tin đã được cat (lưu trên memory).

Đối với file có nội dung không thay đổi nhanh chóng thì grep thẳng luôn hoặc cat rồi grep cũng gần như nhau. Tuy nhiên, đối với file có nội dung thay đổi liên tục thì cat trước, grep sau sẽ bảo đảm ở một thời điểm nào đó thông tin được grep có thể hiện diện vì thông tin đó đã được tạm thời lưu trên memory chớ không thay đổi liên tục nữa.

Em nghĩ cat không đọc trọn bộ. Vì em đã từng cat 1 vài file to đùng hàng GB mà mem vài trăm Meg có làm sao đâu.
cat có thể đọc theo từ block để ghi buffer thôi, và nó nhớ vị trí nào là kết thúc file nó đọc tới rồi stop, chứ không phải là nó read từng line kệ cho file có tăng thêm. Có lẽ nó read từng line khi đầu vào dạng character device thay vì block device thì phải. Muốn biết cụ thể chắc phải xem source của nó.

conmale wrote:

huynhtronghoan wrote:

conmale ơi, vì lượng online user của xuongphim rất lớn, tầm 2500-4000 http://whos.amung.us/stats/l7ujg4dannls/), thì liệu dùng iptables & mod security của apache có chống đỡ nổi hông, vì số lương IP rải rác khắp nơi và lượng truy cập đồng thời lại cao nữa. Anh có cao kiến gì để phòng thủ trong trường hợp này không.

myquartz ơi, cách của bạn rất tuyệt.

Cám ơn 2 bạn nhiều nhé.

Cách tốt nhất là bồ thử nghiệm và đưa ra kết luận xem "có chống đỡ nổi không". Đặc biệt, bồ cần hiểu chính xác những gì tớ đưa ra là gì (và có tác dụng gì). Tớ không có thói quen đưa ra giải pháp cho vui .

PS: cỡ mod_security và iptables mà còn sợ "đỡ không nổi" thì mấy giải pháp dùng "basic auth" và "rewrite" trên apache thì làm sao mà chịu nổi.

Đừng dùng mod_evasive vì nó đang đóng góp cho việc "từ chối dịch vụ" đó.

Hihì, cách của em không phải để chống đỡ cuộc tấn công, mà tấn công lại bằng các hộp thoại cho các user vào site bị dính x-flash. Đây là cách để gây khó chịu cho user, user phàn nàn với chủ site và giảm sự hấp dẫn của site, kết quả là chủ site phải loại bỏ flash lỗi và sẽ giảm sức ép lên mình. Em thấy bên xuongphim.com đã loại bỏ flash tấn công vuvu.mobi rồi đó, hacker có thể tìm site khác để tránh kiểm tra refer, ta lại chạy đua với họ.
Cái này vẫn phải kết hợp với mod_security và iptables. Ngoài ra, để hiệu quả hơn thì cần là việc chạy đua vũ trang nữa, tăng sức mạnh phần cứng của mình lên, tối ưu hệ thống hơn. Ví dụ với 4000 client của xuongphim.com, thì máy chủ của ta sẽ phải gánh được tầm bằng ấy. Chứ nếu chỉ gánh được tầm 1000 là xong đời mình trước khi gây khó chịu cho user.

Phim ảnh nó chả giống thật đâu. Nhiều cái vô lý ng ta đã nói hết cả. Không chỉ xài đồ cũ, mà việc hack rồi nhập liệu cực kỳ vô lý. Ví dụ gõ bàn phím cả chuỗi dài mà không nhập dấu space. Chữ trên màn hình máy tính thì cực to, virus nhiễm vào máy tính thì hình ảnh màn hình tự nhiên bị ăn mất, hoặc việc copy dữ liệu (ko rõ dung lượng) chỉ diễn ra có vài giây, cho dù xài ổ đĩa ... mềm.
Chuyện hack mới kinh, hacker trong phim là tài nhất thế giới. Ví dụ trong phim Công viên kỷ Jura, em gái học cấp 3 nói là "biết hệ thống này là Unix" và chỉ trong vòng có mấy phút đã xâm nhập và điều khiển nó (để điều khiển cả 1 hệ thống cửa, khoá, điện đóm... của công viên).
Hoặc là đoán mật khẩu trên phim, kinh khủng. Gõ gõ vài cái là ra, thử ngày sinh, tên người yêu ghét hoặc tên nơi sinh, nơi ở (hic, kể ra cũng có thể đúng, cơ mà đối với các hệ thống siêu quan trọng như thế mà mật khẩu dễ đoán thế, chắc là chỉ có ở trên ... phim).

À, có 1 cái ở trên phim mà các bạn làm IT VN ít người biết tại sao, đó là truy cập mạng (trái phép hoặc từ xa) thông qua ... bốt điện thoại công cộng hoặc bất kỳ cái điện thoại nào, thông qua 1 thiết bị gắn vào ống nghe và ống nói. Ví dụ Phim Terminator 3, con robot gái đưa cái điện thoại lên miệng ò í e 1 tí là truy cập hết cả vào mạng của cảnh sát...
Đố các bạn biết nó sử dụng kỹ thuật gì đấy?

Bạn thử áp dụng giải pháp sau:
1. Tắt KeepAlive đi (Off) nó, cái này sẽ giúp cho mỗi child process của httpd giải phóng tài nguyên ngay khi kết thúc request và đón thêm connection khác. Tuy nó sẽ làm khách hàng truy cập chậm hơn 1 chút nhưng ko tệ quá đâu.

2. Sửa config và thêm 1 đoạn cho httpd như sau:
Code:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} xuongphim\.com
RewriteRule ^/ /youarevictim.html [L]
<Location /youarevictim.html>
AuthType Basic
AuthName "Xin ra khoi xuongphim.com"
# (Following line optional)
AuthBasicProvider file
AuthUserFile /tmp/passwords
Require user victim
</Location>

3. Tạo 1 file password để bắt phải xác thực:

Code:

htpasswd -c /tmp/passwords victim

Mật khẩu thì bạn đặt đại 1 chuỗi nào đó chỉ bạn biết.

Cách này, nghĩa là nó ép những client vào xuongphim.com mà laij refer sang web của bạn, thì trình duyệt sẽ bật hộp thoại bắt xác thực. Càng nhiều request gửi đến, việc xác thực càng nhiều, mọi người sẽ khó chịu với nó mà có sức ép với chủ site (bị hack hoặc cố tình) buộc họ phải thay đổi.
Cửa sổ xác thực cũng giúp ngăn chỉ có request đầu tiên là tới, các request kế tiếp sẽ phải cancel hộp thoại hoặc ok đại.

Kiểu này giống kernel panic. Thường dính phát này thì server ko thể lưu gì vào log được, nó chỉ phun ra lên màn hình 1 vài thông tin, core dump, stack trace.
Bạn có thể nhờ cậy bên ISP chụp lại cái màn hình máy bị treo (dù máy ảnh kỹ thuật số chụp cái màn hình vì dĩ nhiên ko thể thao tác với server đuwọc rồi). Có cái này mới có thể tìm được nguyên do.

Khả năng kernel panic rất cao là do từ hardware có vấn đề, có thể đĩa cứng (dùng smarttools là tìm được bệnh), có thể là memory (cái này phải đến tận nơi check), hoặc 1 PCI card/thiết bị nào đó ko ổn định (khó check). Nếu server to tiền 1 chút, ví dụ IBM, Dell, trong BIOS của nó sẽ logging lại vấn đề lỗi này (nó nằm ở service processor nên ko bị ảnh hưởng bởi OS).

Ở HCM nè nhưng không đi xem. Đi xem rồi lại thất vọng thôi.

Thiết kế mạng người ta không cần cái gọi là kỹ năng, chỉ làm kỹ thuật viên vận hành mới cần kỹ năng (or năng lực kỹ thuật). Người thiết kế mạng được gọi cái tên ngon lành hơn: kiến trúc sư mạng, người có thể không cần có các bằng CCNx nhưng cần có lý thuyết cơ bản và kiến thức rộng rãi, không cần kỹ năng tốt mà cần tầm nhìn và kiến thức rộng, nhưng cũng hiểu biết sâu sắc về lý thuyết mạng.
Hiện công việc xây dựng các mạng thiếu các kiến trúc sư, vẫn do các kỹ thuật viên CCNx làm. Đẻ ra cái hội thảo "Kỹ năng thiết kế vận hành" thì cho vui thôi.

Theo như cái hình chụp Paypal lỗi ở trên. Lỗi là expire. => giờ của máy tính bị sai nên cái Cert của paypal dù đúng về mặt được CA trong trusted CA store của Firefox xác nhận, nhưng thời gian không khớp.

Các trường hợp khác, nếu báo chung chung bị untrusted, có thể vì các lý do sau:
- website bạn truy cập dùng https cert không hợp lệ hoặc CA chứng nhận cho nó không nằm trong CA trust store của trình duyệt (ví dụ HTTPS Server tự tạo chẳng hạn).
- Nếu các domain nổi tiếng, bạn vẫn truy cập hàng ngày tự nhiên bị vậy thì: 1. kiểm tra lại thời gian của máy tính, 2. có thể 1 thằng nào đó ở trung gian giữa bạn và server đang giả mạo server (ví dụ xài Cain giả mạo HTTPS server chẳng hạn), 3. chính site đang truy cập của bạn bị trục trặc và bộ key/cert trên đó đang gặp vấn đề (thường là trường hợp cert bị expire mà chủ site chưa kịp mua cái mới, các trường hợp khác như cert site bị revoke hoặc bị chiếm dụng thì hiếm xảy ra hơn).
- Website của bạn dùng CA tự tạo, nhưng CA đó nó ko available vào lúc truy cập, đặc biệt là khi bạn xài USB Security Token của công ty, nếu công ty có CA riêng, khi cắm token vào thường thì CA lưu trong token tự động được add vào CA Trust Store của trình duyệt. Nhưng bạn không cắm token và không có cái CA đó thì website tự nhiên là untrusted.

Trong 3 lý do trên, trừ khi bạn chắc chắn rằng website bạn truy cập không có CA trusted thực sự (nên kiểm tra 1 chuỗi gọi là Thumb Print so với cái bạn đã biết về web site đó), còn không thì đừng bao giờ accept nó, không add Exception cho nó. Nếu không có thể bạn bị a man in middle tấn công đấy.

Haha, conmale sắp phát khùng với đám kid hacker này rồi. (lạc đề tí).
Bạn gì kia nên học thêm đi, để hack được (hoặc chống được), người ta phải học nhiều nhiều lắm. Nếu muốn biết có thể tấn công cái web gì xài md5 đó, nên học kỹ về HTTP, HTML, rồi thì web browser hay web client... rồi hẵng chiến đấu.

Bổ sung cho xnohat.
Khi nắm vững mô hình client-server, thì xem xem với Anti-virus, client làm gì, server làm gì thì hợp? Chắc là dạng client vớ được con virus nào thì gửi báo cáo cho server để nó "diệt" hay làm gì đó?. tìm hiểu đi..

halowen3456 wrote:

Đúng như bác này nói. Tuy Static route nghe có vẻ khá đơn giản. Nhưng đi sâu vào thì nó lại là một vấn đề không hề nhỏ. Tình hình là em đang tìm hiểu về nó nhưng là thiếu tài liệu.

Vậy nên bác nào có tài liệu thì cho em xin nha

Google và Web, chỗ đó hàng vạn tài liệu. Phải đọc hiểu xong viết thành cái của mình, chứ chờ 1 cái tài liệu đầy đủ rồi đem dịch ra nộp cho thày thì còn lâu mới có.
Nên xem 1 số nơi sau: www.cisco.com (chú ý đến các tài liệu mô tả hoặc "how it work" của nó), web site 1 số trường đại học .edu (tìm các đồ án đã làm), giáo trình của thày Hải Bách Khoa HN về cơ bản mạng máy tính thì phải (cái này tớ nhớ là lý thuyết rất cơ bản, ko có thiết bị cụ thể nào cả)... Vô số cái đấy.

shell-command wrote:

Telnet khi gởi GET /index.html HTTP/1.1 nó không hề cung cấp giá trị "Host" trong HTTP header của request cho nên dịch vụ web của server sẽ nhận và không thực thi công tác xác định request ấy thật sự muốn lấy thông tin từ "virtual host" nào mà chỉ cung cấp index.html của 210.245.86.192 (nếu có). Bởi vậy, với đoạn màu đỏ ở trên thì server không có cách gì "biết" hết (nếu dùng telnet để request).

Vậy mà ông thầy cháu hỏi , làm sao mà phân biệt được, 2 trang web cùng trên một server cùng địa chỉ IP, không có virtual nào hết(mặc dù cháu chưa hiểu về cơ chê này lắm), cùng hoạt động trên cổng 80, chỉ bằng với câu lệnh sau mà server vẫn phân biệt được:
Code:
telnet vnexpress.net 80
GET /index.html HTTP/1.1
Câu này nó sẽ trả về index.html của vnexpress.net
Hoặc
Code:
telnet ngoisao.net 80
GET /index.html HTTP/1.1
Câu này sẽ trả về index.html của ngoisao.net
Hỏi lại thì ông không trả lời , . Cũng không hiểu ra làm sao nữa

Sao với dăng cái gì. 2 domain vnexpress.net và ngoisao.net nó có IP hoàn toàn khác nhau, dù có chung server đi chăng nữa. Server trong trường hợp này nó phân biệt bằng IP (mà client kết nối đến). Nó chả cần Host: nữa.
Trường hợp phân biệt bằng Host: thì chỉ khi 2 web site chung 1 IP, chung 1 server thôi.
Thế nên có chuyện dịch vụ hostinhg 2 loại Virtual Host IP-base hay Virtual Host Share IP/Domain Name-base, dạng IP-Base đắt tiền hơn vì phải thuê IP và có thể dùng lệnh HTTP/1.1 què cụt như trên chú em thử nghiệm vẫn được đấy.

Bạn chủ topic nói đúng nhưng mà ko ... hiểu thực tế.
Đúng là nếu bạn đăng ký được làm chủ sở hữu .com.vn thì bạn sẽ có toàn quyền cấp cho tintuc.com.vn, hay hva.com.vn... vô tư, thu tiền theo ý của bạn miễn là tuân theo pháp luật...
Nhưng hiện tại, mấy cái tên quan trọng như .com.vn, .net.vn, .org.vn hay .gov.vn đều có chủ sở hữu cả rồi. Mà chủ nhân của nó lại sở hữu vĩnh viễn (không hết hạn), độc quyền với tên miền phụ (ko ai khác được phép kiện cáo về việc cấp phát tên phụ), được quyền bán dịch vụ tên miền phụ (tức là cấp phát tên miền dưới .com.vn), được quyền thu hồi nếu khách hàng vi phạm. Chủ nhân đó là VNNic, đồng thời cũng là chủ nhân của .vn luôn.
Như thế thì bạn sẽ ko thể đăng ký với VNNic (chủ nhân của .vn) rằng cho tôi tên miền com.vn được (dù là có thể khác .com.vn thì ok, ví dụ com1.vn, com2.vn), họ sẽ từ chối bạn vì .com.vn của họ rồi (và họ ko bán).
Thế là trả lời câu hỏi của bạn chưa?

Static route đúng là hơi ít, so với dynamic routing.
Nhưng ở mức bài tập lớn hoặc là khoá luận tốt nghiệp, nó cũng lắm cái để mổ xẻ đấy chứ.
Ví dụ: metric/preference trong static route. Rồi policy-based static routing (cái mà dynamic ko có bao giờ).
Hoặc là static route với interface status, tuỳ theo up/down của nó. Hoặc nữa là liên quan đến fail-back (hay backup) static route...
Đó là áp dụng cho IP, chứ còn static route cho IPX hay MPLS hoặc bất kỳ 1 packet-base switching/routing nào khác chẳng hạn.
Nếu đào sâu, cũng đc 1 cái khoá luận kha khá nhiều cái để nói đấy.

shell-command wrote:

Thầy em có câu hỏi thế này. Dù ngẫm nghĩ nhiều nhưng vẫn chưa trả lời được mong các bạn trả lời giùm:
- Có 2 trang web trên cùng một server, cùng địa chỉ IP , cùng hoạt động trên cổng 80. Ví dụ vnexpress.net và ngoisao.net ( mặc dù 2 trang web này không cùng IP, chưa chắc nó cùng một server..., nhưng cứ ví dụ vậy đi).
-Vậy khi chúng ta gõ vào trình duyệt
Code:
http://www.vnexpress.net
 http://www.ngoisao.net
=> Cổng của 2 trang web này là 80. Như vậy dựa vào đâu mà server trả về đúng là trang của vnexpress.net hay ngoisao.net

Bạn nên nghiên cứu giao thức HTTP, giao thức truyền dữ liệu của web.
Bạn sẽ thấy nó không có gì là khó cả. Trong header của HTTP có 1 field có tên là Host:
Ví dụ bạn truy cập vào http://www.vnexpress.net thì client sẽ gửi cho web server trường Host: www.vnexpress.net
Nhờ trường này, mà web server biết bạn truy cập vào web site nào, trả về đúng nội dung web site đó.

Đúng vậy, Mobile Attack là xu hướng mới, với nhiều thiết bị di động thông minh hơn nên nền tảng bị tấn công cũng phổ biến hơn.

Tuy nhiên, tớ vẫn đánh giá mã độc, với cách lây lan qua trang web (bị nhiễm độc) rồi từ đó dụ người dùng web browser vào sẽ vẫn duy trì sự tăng trưởng. Bởi ý thức "update" phần mềm của người sử dụng vẫn còn rất kém, ấy là riêng ở VN tớ cảm thấy thế.
Tấn công vào web browser tăng thì cũng có thể mạng XH, các hình thức giao lưu, giải trí sẽ tăng theo tỉ lệ thuận.

Các mảng khác ví dụ mã độc lây qua USB, vẫn còn tồn tại, với lỗ hổng "shortcut" mới, chứ auto-run đã là cách phổ biến và cso nhiều công cụ chống.

Những lỗ hổng kiểu như shortcut, đồng nghĩa với việc lợi dụng các lỗ hổng của ứng dụng view hay edit tài liệu, để tấn công vào phần mềm, cũng sẽ gia tăng, khi các con đường thâm nhập vào PC của người sử dụng ngày càng khó.

Theo tớ, tấn công trực diện vào web server, hoặc tấn công vào PC qua mạng, không tăng mà có thể sẽ giảm hoặc đi ngang. Do hiện tại những hệ thống này càng ngày càng khó hơn. PC giờ hầu hết là firewall mặc định, các dịch vụ mạng ngày càng khắt khe. Vì thế con đường sẽ thay đổi từ khai thác lỗ hổng dịch vụ mạng thành khai thác lỗ hổng ứng dụng thông thường.

JW wrote:

Dù ta tắt pin điện thoại vẫn có 1 nguồn như kiểu cmos của máy vi tính ấy. Nó dùng để đếm thời gian và có thể cả vào việc khác mà người dùng thường ko biết. Nothing impossible

Đã lập topic hỏi về vấn đề này, lại reply là biết hết rồi thế này, thì còn hỏi làm gì nữa smilie

.
Cứ thử đi, dùng USB 3G tấn công vào các mạng quan trọng của quốc gia, hoặc xâm phạm an ninh quốc gia mà xem. Xem CA họ có tìm ra ko.
Trên thực tế, có 1 chú dùng SIM rác quấy nhiễu cảnh sát 113 (gọi cả ngàn cuộc) đã bị tóm cổ và bị phạt tiền rồi đấy.

P/s: chú thích thêm 1 tí, vui thôi, cái thằng gọi quấy nhiễu cảnh sát 113 vì rảnh rỗi đó, năm 1992 đã quấy nhiễu 1 lần rồi. Chú này được xác định là có dấu hiệu tâm thần nhẹ, nên mới làm 1 việc ngu ngốc đến vậy. Xem báo đăng nè: http://www.baomoi.com/Info/Mua-sim-rac-de-quay-roi-tong-dai-113/104/4101596.epi

Không kể chú bên trên này, còn 1 vài chú khác nữa: http://www.maivoo.com/2010/09/09/Goi-4-000-cuoc-dien-thoai-quay-roi-Van-phong-TW-Dang-n227024.html

Wifi cũng có khả năng Roaming, và phải có Wifi Controller tập trung như bạn trên vừa nói.
Làm trong phạm vi 1 trường học hoặc 1 khu vực như công viên, khu công nghiệp, thì việc tính toán, bố trí các AP sao cho phủ sóng bao hết, và các kênh sóng không can nhiễu nhau là việc mất công sức nhất. Chuẩn a/b/g/n cũng được tính toán đến.
Thứ nhì là việc kết nối AP về trung tâm là đau đầu thứ 2. Nếu các AP cách trung tâm 1km thì kênh truyền ethernet ko tới, chơi cáp quang là ngon nhất (nhưng tốn kém nhất). Nếu kết nối bằng cáp đồng với tốc độ thấp (ví dụ 2Mbit của G.SHDSL chẳng hạn), thì sẽ chỉ đủ để truy cập Internet mà thôi.
Làm được smooth cái mạng AP đó, thì cũng là việc không đơn giản. Ví dụ vừa nói chuyện skype (bằng điện thoại di động có wifi chẳng hạn), rồi đi ôtô di chuyển từ cell này sang cell kia, mà ko bị gián đoạn cuộc gọi, thì bạn đã có thể coi là chuyên gia Wireless rồi.

JW wrote:

Xin hỏi cái máy cầm tay đó gọi là máy gì nhỉ? Nó có tồn tại trên đời này ko?

Có đấy, máy cầm tay đó được nhập khẩu theo đường của Bộ Công An và Quốc Phòng. Không những máy cầm tay, mà còn cả cái ôtô đặc chủng có gắn ăn ten định hướng quay quay (nguỵ trang bằng 1 cái hộp tròn che kín) cũng có khả năng xác định vị trí khá chính xác của điện thoại di động.
Nguyên tắc của nó đơn giản (nhưng chế tạo ko đơn giản), nó là cái máy thu radio có anten định hướng, và nhắm vào cụ thể 1 nguồn phát radio, thí dụ như điện thoại di động.
Có điều, nếu điện thoại di động ở trạng thái standby, ko gọi, thì sau mấy chục second nó mới phát ít 1 sóng báo cho BTS là nó vẫn "alive". Ở trạng thái này, để detect vị trí bằng cái máy cầm tay kia là khó. Nhưng khi đt hay USB 3G ở trạng thái kết nối (gọi điện, nhắn tin, vào net...) thì nó bắt đầu phát sóng mạnh, chính lúc này là lúc vị trí của mobile dễ dàng bị phát hiện. Chả thế mà trong 1 số phim trinh thám, cứ phải dụ đối phương gọi điện thoại là vì thế. Ngay cả hacker lừng danh Kevin Mitnick cũng bị tóm cổ khi đang sử dụng kênh truyền dữ liệu qua điện thoại di động để đột nhập vào đâu đó và khi cảnh sát gõ cửa, đã không kịp làm gì để phi tang cả.

VN chắc là cũng có mua 1 số lượng nhất định thiết bị định vị mobile. Nhưng trang bị đến mức độ nào, số lượng ra sao thì ko rõ. Tốt nhất là cẩn trọng nếu muốn làm việc xấu và cực xấu qua USB 3G đấy.

B 0 0 B wrote:

à

@myquartz: cái browser mình vẫn thương dùng google.com.vn hàng ngày, nhưng khi tớ lấy 1 ip proxy nào ở us hay nước nào khác bỏ vào, thì google sẽ wwwect tới mấy nước đó ?

ko thấy dựa theo thói quen nào cả, thử 3 browser vẫn vậy

Chắc là bạn dùng anonymous proxy nó lọc bỏ cookie rồi.
Bạn thử thêm tiếng Việt vào prefer language trong trình duyệt, cho lên đầu tiên trước các ngôn ngữ khác nhé.
Sẽ thấy hiệu quả.

Tuy là độc lập, nhưng 2 thiết bị OTP token và máy chủ OTP có thể sinh ra cùng 1 mã (hoặc kiểm tra mã OTP Token có đúng không) đều chia sẻ 1 số thông tin chung:
1. Giải thuật sinh mã là giống nhau. Theo tớ nhớ là có 1 số giải thuật tiêu chuẩn cho việc này hoặc hãng tự làm.
2. trên server OTP có giữ CSDL chứa key có trong mỗi OTP Token nó xác thực. Do đó từ cùng 1 nguồn thông tin (thời gian 2 bên giống nhau hoặc sai lệch tí chút, hoặc số lần bấm nút giống nhau), 2 bên sẽ sinh ra 1 số giống nhau. Dĩ nhiên việc này phức tạp hơn 1 chút do có 1 số yếu tố nhất định để đồng bộ offline với nhau dễ dàng hơn.

OTP chỉ được xem là phương pháp xác thực nhân tố thứ 2 dùng trong iBanking hoặc bất cứ cái gì, nó cũng chỉ phù hợp với cá nhân, ít khi áp dụng cho việc xác thực doanh nghiệp. Nó không có khả năng chống từ chối như chữ ký điện tử dựa trên khoá công khai.
Xem thêm ở http://en.wikipedia.org/wiki/One-time_password

Cái hide IP chạy rồi, ip2location mà sai thì Google nó cũng detect vị trí qua IP cũng sẽ sai theo. Chả có cách nào hay hơn ip2location đâu.
Google nó detect vị trí user ko phải theo IP (dù cũng là 1 cách). Vì dùng trình duyệt, trong đó nhiều thông tin hơn và nó ưu tiên về sở thích, chứ ko phải vị trí user. Các cách gồm: prefer language (nếu bạn prefer tiếng Việt thì thường được đẩy về google.com.vn), cookie (đã vào google và chọn language setting). Ngoài ra một số trình duyệt còn hỗ trợ detect location qua GPS gắn trong máy chẳng hạn.
Google nó ưu tiên sở thích user hơn vị trí. Chả thế mà laptop mình hay xài google.com.vn, dù có đi Singapore hay sang China dùng Internet, gõ google.com nó vẫn về trang VN, chứ ko cho vào trang sg hay cn, hk gì cả.
Trường hợp của bạn thì ip2location đúng, google ko đúng, nếu bạn ko xài 1 tool hide IP nào cả.