banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: Mr.Khoai  XML
Profile for Mr.Khoai Messages posted by Mr.Khoai [ number of posts not being displayed on this page: 5 ]
 
St Konqueror,

Khoai thì thấy bất cứ desktop manager nào cũng có thể bind một key với một action nào đó. Cái cốt lõi của vấn đề là: Bind được 100 cái keyboard shortcut, nhưng bản thân mình sử dụng được bao nhiêu (và nhớ được bao nhiêu). Còn các application shortcut thì sao?

Bài viết rất chi tiết. Khoai ủng hộ bồ viết thêm về mấy trái tricks này.

khoai

superthin wrote:

quanta wrote:

Ừ, ý anh là muốn bàn thêm về key fingerprint, long key ID, normal key ID và lưu ý cách import key ID cho mỗi distro ấy mà. 

Tại sao lại phải rối rắm thế nhỉ? Mình không rõ mấy cái key này dùng để làm gì? Nó có giống chìa khỏa mở cửa nhà chúng ta chăng? Không lẽ mỗi một server trên mạng là một cái cửa / két sắt à, và chúng ta cứ phải kiểm chìa khóa tra vào để mở? Sao người ta không dùng đơn giản như các trạm Anonymous FTP cho tiện nhỉ? Các bạn giải thích giúp nào. 


Thử nghĩ mình download một cái SSH server từ một site repo.ubuntu.khoai.net, làm sao biết cái ssh server đó có phải của Ubuntu hay không? Hay là khoai đã sửa lại source, thêm một cái backdoor rồi publish lên mạng. Bạn tìm hiểu thêm về public key infastructure và cái digital signature để biết rõ các key được sử dụng như thế nào. Nói chung chung là cái key được import vào sẽ được dùng để xác thực gói binary hoặc source mà bạn tải về là thật sự từ phía Ubuntu cung cấp.

khoai
Con số đó là tùy. Một site lớn như ebay hoặc google sẽ có số khác, còn một site như HVA sẽ có số khác. DoS không phải chỉ có flooding, còn nhiều dạng khác, với số lượng gói tin nhỏ, mà ảnh hưởng thì cao.

khoai
Câu trả lời là còn tùy host đó hỗ trợ upload như thế nào. Tìm mà tìm không chính xác cũng như không. Nên tìm tại website của host đó để xem họ hỗ trợ những gì.

khoai
Đề nghị các bạn không chit chat trong box kỹ thuật nhé. Đúng như ham_choi nói, topic đã đi khá xa mục đích ban đầu. Nhưng khoai thấy nếu tiếp tục thảo luận về mạng cũng không có hại gì.

khoai

H3x4 wrote:
Sau đây là list mà mình đã sử dụng trong 3 năm qua :
1/Intel manula volume 3 : system programming
2/TCP/IP illustrated
3/ C programing language
4/Shellcoder's handbook
5/Hacking : art of exploitation
6/Linux memory management
7/Windows Internal
8/Reversing: Secrets of Reverse Engineering
9/Hacker diassembling uncovered
 

Trong vòng 3 năm qua, so với bạn thì khoai thấy thật xấu hổ: Chỉ đọc được 2 cuốn sách trong số các quyển sách của bạn (mà cuốn nào cũng rất hay) là cuốn số 2 và số 5. Riêng cuốn sách số 2 khoai đã đọc đi đọc lại ít nhất 3 lần rồi smilie

Nếu đã đọc được nhiều vậy, hy vọng khoai sẽ thấy nhiều bài thảo luận chất lượng trên diễn đàn.

khoai
Cái gì làm được thì nên tự làm. Nếu không biết PHP có thể tìm hiểu trước rồi mới quản lý một PHP site. Nếu biết rồi thì càng đáng trách, google một phút thì ra cả đống links, thậm chí có cả code chỉ việc copy và paste. Nếu việc đó mà làm không được, còn phải chờ người khác làm cho mình thì không biết bạn làm được cái gì.

Cá nhân khoai không nghĩ bài này sẽ có ai trả lời.

khoai
hm, cái hydra này lạ chỉ, build error từa lưa mà toàn...ignore smilie Bạn coi có file INSTALL hoặc README không? Và xem chúng nói gì. Bạn có thử chạy đỷa từ trong /usr/local/bin/hydra chưa?

khoai

zu4er wrote:
lúc này có IP rồi client sẽ hỏi MAC address của server mỹ đó là gì 

Cái này không chính xác. Client ở Úc không hề quan tâm đến MAC address của server ở Mỹ là gì.

zu4er wrote:
2. Những hop trung gian, hop 2-9 ko thể arp spoof, vì nó chỉ làm nhiệm vụ routing ko biết đc ip thực của client và server, và nếu nó spoofing, có thể sẽ phải xử lý ( arp spoof) toàn bộ traffic của hàng triệu request qua nó, mạng sẽ rất chậm 

Các hop từ 2-9 bắt buộc phải biết IP của client và server. Không biết thì lấy gì mà route?

Câu trả lời cho câu hỏi "Các hop nào có thể sproof ARP được?" của anh conmale là....tùy: Tùy coi người tấn công ở đâu trong topology tên.

Ban cũng nên xem lại cách thức một switch và một router hoạt động thế nào. Từng bước một, một IP Packet chẳng hạn đi từ A đến B, thông qua các switch và các router trung gian thì điều gì sẽ xảy ra, các fields nào của packet, của segment, hoặc của frame sẽ được thay đổi, và thay đổi ra sao.

khoai

H3x4 wrote:
Nói thiệt là em chả có hứng thú gì với mí cái topic làm sao .. làm thế nào ... để hack vào máy người khác smilie Thấy nó nhảm nhí gì đâu nên cũng ko thích post bài chi. Mí cái người hay đề nghị ra mấy cái topic này cũng chả đọc bài post của mình làm gì ( bởi lẽ nếu họ quan tâm thì chả có rảnh đâu mà đi hỏi mấy câu như thế ) . Còn cái IP , Router hay NAT thì có trong giáo trình CCNA hết .  


Hì, vẫn chưa trả lời câu hỏi của bạn StarGhost nhá. Trả lời cho hay đi đã rồi hãy tính tiếp. Bạn đừng nghĩ những câu hỏi cơ bản chỉ "có trong giáo trình CCNA" hết. Khoai có biết vài người đã có cả CCNP, đang làm cho Cisco mà vẫn không biết data encapsulation là cái gì kia.

khoai
rs,

Đó đâu phải là lỗi. Đó chỉ là thông báo không tìm thấy librfc thôi. hydra sẽ vẫn được build và install nếu bạn tiếp tục make, nhưng module sapr3 sẽ không được kích hoạt (không xài được).

Nếu muốn, bạn có thể cài cái librfc rồi configure lại lần nữa.

khoai
HaiNam.No.Other,

Theo khoai được biết, PDU là protocol data unit, nghĩa là phần data (payload) của một protocol. Ví dụ, ở layer 2, một Ethernel frame sẽ nằm trong "start flag" và "stop flag". Chính 2 cái flag đó giúp xác định đâu là một frame -- một PDU.

Ở layer 1, đúng là không có cái gì xác định đâu là phần payload, đâu là phần header. Tuy nhiên, trong mô hình OSI, PDU của layer 1 vẫn được coi là bit. Layer 1 dùng để truyền nhiều "bits" từ đầu này sang đầu kia của communication link. Do đó, "data" của layer 1 có thể được coi là bit. Nhưng nói theo trích dẫn trong sách cũng không sai. Lý do: Không có header thì không có xác định được payload.

khoai
ham_choi,

Anh pnco đã nói: Đây là box Góp ý và Hỏi đáp thắc mắc chứ không phải là nơi tán gẫu. Khoai chỉ chắc nhở bạn không nên post các bài có nội dung như thế vào các box khác ngoài box "Các thảo luận khác" trên Forum.

Về lỗi trên của bạn, anh conmale sẽ cố gắng giải quyết nếu đó là lỗi của server. Nếu là lỗi phía đường truyền, proxy, cấu hình của browser, vân vân thì có lẻ sẽ không được giải quyết.

khoai

viethungs wrote:
Em đã đặt các quyền user là 777 hết rồi, và cũng sửa httpd.conf như anh F10 nói, nhưng nó vẫn gặp lỗi.

Em đang test với tên miền http://check.homeftp.net/

Giúp em với 

Cứ gặp lỗi Permission là chmod 777 thì cái website không sống được bao lâu đâu. Bạn cần xem kỹ lại log và cách cấu hình httpd.conf cho đúng. Trong đoạn Code:
<Directory />
Options +Indexes FollowSymLinks
AllowOverride None
Allow from all
</Directory>
thì Apache xem cái / là directory nào? Apache còn được cấu hình với VirtualHost, vậy bạn chỉ xét permission tại /var/www/html có đủ không? Bạn sử dụng VirtualHost nào? Permission ra sao? Apache chạy dưới chủ quyền nào? Group nào?

khoai
coolie,

Có 2 cách để tìm offset: 1. Cách "nông dân" là đếm số lượng byte từ đầu gói tin đến chỗ cần thiết. Mỗi cái 0x__ là một byte. Cứ thế mà đếm smilie Cách hai là sử dụng cột số đầu tiên khi sử dụng wireshark. Cột đầu tiên đã đếm số byte offset theo từng 16bytes (0x10) so với đầu gói tin.

khoai
Không biết bạn cần tài liệu gì về YUI. Tốt nhất vẫn là đọc documentation tại YUI website http://developer.yahoo.com/yui/. YUI chỉ là một bộ javascript do nhóm phát triển của Yahoo viết. Bạn có thể sử dụng bộ javascript này để thiết kế webpages với AJAX.

YUI và PHP thì không "liên hệ" với nhau cho lắm. Có chăng là sử dụng PHP để print ra link đến bộ YUI hoặc để print ra các script dùng cho YUI thôi.

khoai
He he, vậy là cuối cùng cũng đoán mò mà trúng. Để trả lời câu đó của StartGhost thì phải hiểu rõ cách một node làm sao detect được collision. Vậy, khoai xin để các bạn thảo luận tiếp.

khoai
i_t_cun_91,
Bạn không nên viết bài chit chat trong các chủ đề kỹ thuật.

StartGhost,
Dạo này bận quá nên "trốn" luôn đến giờ smilie Nếu so về khoảng cách vật lý thì performance của hai trường hợp chỉ khác nhau về propagation delay (thời gian một frame đi từ node A đến node B). Nếu trong khoảng thời gian đó máy B cũng chịu khó send một frame khác thì cả 2 máy sẽ detect được collision và sẽ tự động gửi lại sau một khoảng thời gian. Nếu khoảng cách A và B càng lớn thì mức độ collision sẽ càng cao. Chưa kể đến trường hợp không thể detect được collision và frame đó bị lỗi khiến cho check sum bị sai.

Mấy câu hỏi của StartGhost rất hay, nếu rãnh rỗi mong bạn gửi thêm nhiều câu hỏi kiểu này để thảo luận chơi smilie

khoai
Nếu thắc mắc đã được giải quyết. Khoai đóng topic này lại. Nếu bạn bolzano_1989 vẫn có ý thảo luận thêm xin mời PM đến khoai để khoai mở lại topic này.

khoai
ganmaxa,
Bạn đóng góp ý kiến thật tình và rõ ràng thì không có gì là "Sai nội quy" cả.

diepbang,
Không có bất cứ một ngôn ngữ gì là an toàn tuyệt đối, và càng không có ngôn ngữ lập trình nào là tạo nhiều lỗ hổng cả. Chỉ có người sử dụng ngôn ngữ đó có biết code làm sao cho an toàn hay không mà thôi. Mỗi ngôn ngữ lập trình đều có điểm mạnh yếu khác nhau. Đã chọn một ngôn ngữ để sử dụng thì phải học luôn cách sử dụng sao cho thật tốt.

Các bài viết của bạn ở trên không phải là sai, nhưng không hoàn toàn đúng 100%. Có chăng đó là một vài trường hợp rất cụ thể và rất đặc biệt, không thể cho là thực hiện các bước trên sẽ bảo mật được máy tính của mình.

Khoai góp ý chân thành là bạn nên từ từ, kiểm tra lại phần kiến thức cơ bản của mình trước đã. Bạn có thể tham khảo các bài viết trong HVA. Cá nhân khoai nhận thấy phần kiến thức "nền" của bạn vẫn chưa đủ để có thể thảo luận sâu về bảo mật.

khoai
Hì, chắc ở nước ngoài lâu quá nên từ không viết thế nào cũng quên mất. Chỉ có vài điểm này bạn nên xem lại:

1. Không có chuyện "lỗ hổng 139" mà chỉ có các lỗ hổng trên các dịch vụ chạy trên port 139. Dịch vụ nào chạy trên port này? Và dịch vụ đó có lỗ hỗng gì? Vì sao làm các bước trên thì sẽ ngăn chặn hoặc khắc phục lỗ hổng đó?

2. Có chắc là một máy tính chỉ có các "lỗ hổng" trên hay không? Vì sao bạn dám khẳng địng sau khi làm các bước trên thì "không còn lỗ hổng" nào nữa?

3. Virus là cái chi? Và lây lan qua đường nào? Các bước phòn thủ của bạn làm sao chống được virus? Chống được trong trường hợp nào?

khoai
StartGhost,

Ở câu 1, ý bạn disable cái CAM table nghĩa là như thế nào? Là cho trường hợp CAM table hoàn toàn bị đầy khiến cho switch hoàn toàn bỏ qua nó hay sao?

Nói gì thì nói, khoai vẫn nghĩ switch "thông minh" hơn hub, nhưng có lẽ switch vẫn chậm hơn hub khi process các Ethernet frame. Nói vậy không ít người la khoai là sử dụng hardware cut-through để forward các frame thì vẫn không thua gì tốc độ một cái repeater chính cống. Nhưng, khoai vẫn nghĩ bước logic để so sánh một MAC address và output port vẫn tốn thời gian. Không biết rõ ở mức "điện tử" thì switch khác với hub thế nào, nhưng theo câu hỏi trên thì switch vẫn tốn nhiều thời gian và tài nguyên để thông qua bước xử lý cho một frame. Như vậy, bỏ đi cái CAM table thì switch và hub vẫn khác nhau. Hub hoàn toàn không hề có bất cứ logic gì phía sau mà chỉ "copy" lại electrical signal từ input port ra tất cả các output port mà thôi.

Còn câu 2: Vậy mình sử dụng loại cable nào? Mức độ resistant cho noise và tốc độ truyền dữ liệu sẽ bị lệ thuộc rất lớn vào cable và NIC. Bạn cho thêm vài gợi ý để suy nghĩ xem smilie Cái này khoai chịu thua.

khoai
StartGhost,

Khoai "khoái" câu số 3 nhất vì không phải ai cũng nghĩ đến lý do sử dụng Collision Detection(CD) hoặc Collision Avoidance(CA). Chỉ có anh "không dây" là có trường hợp không detect được collition mà thôi. Thử nghĩ đến trường hợp khoảng cách từ mỗi node đến base station hoặc AP, so sánh với khoảng cách trực tiếp từ các nodes với nhau chẳng hạn. Đương nhiên là tùy vào lượng dữ liệu, CD nhiều khi bị performance hit cao hơn so với CA. Nhưng hiện nay, ai mà xài hub nữa, dẫn đến việc collition rate của các LAN segment ít khi nào lên cao.

Câu 1: Bà con trả lời quá trời rồi.

Câu 2: Cái này hơi lạ. Còn phải tùy vào transmittion delay, propagation delay và số lượng nodes active trong một segment thì mới quyết định performance được. Nếu số lượng nodes active đủ nhiều có thể khiến cho LAN segment hoàn toàn bị "đóng băng". Khi đó, CA sẽ tốt hơn CD. Tương tự, nếu transmition delay cao, mà lượng traffic lại nhiều thì vẫn dẫn đến tình trạng tương tự. Không có yếu tố users (active nodes) thì làm sao xét performance được?

khoai
jforum3000,

Khoai đã thử rồi mới dám trả lời bạn chứ smilie Còn vụ phải copy và paste vào Address bar thì đúng là hơi bị chuối chiên. Khoai thường vào HVA là log in ngay, nên không có xài chức năng "Các bài viết mới nhất"

ham_choi,

Mình đang bàn vụ "Các bài viết mới nhất". Nếu bạn có ý đóng góp về bàn phím ảo thì nên tạo một chủ đề mới trong mục Góp Ý cho diễn đàn. Xin nói lại lần nữa, các bạn đừng nên so sánh diễn đàn HVA và các diễn đàn khác.

khoai
ham_choi,

Không phải tự nhiên mà anh conmale yêu cầu user phải thông qua trang "chủ" index để vào forum hay portal. Trước kia trang portal đã được chuyển thành trang index cho HVA, do đó việc để những bài viết mới nhất vào portal là hoàn toàn hợp lý.

Chuyện cái bàn phím ảo, theo ý khoai là không cần thiết! Liệu bàn phím như trên có giúp được gì khi bản thân máy mà user sử dụng không an toàn? Và, những điểm "hại" mà bàn phím ảo đó mang lại thì sao?

Mọi đề nghị đóng góp diễn đàn đều được anh conmale và các thành viên BQT xem xét kỹ và thảo luận trước khi "thông qua" hay "bỏ qua" Các thông báo lỗi đương nhiên sẽ được ưu tiên để fix trước. Còn các đóng góp phát triển các chức năng khác của diễn đàn thì phải tùy vào thời gian và mức độ cần thiết. Các bạn đừng nên so sánh HVA với các diễn đàn khác mình đang tham gia về mặt features hoặc lay-out.

jforum3000,
Guess vẫn có thể sử dụng được chức năng Các chủ đề mới nhất mà. Nhưng bạn phải vào trang index, rồi mới paste cái URL trên để sử dụng. Không cần phải log-in thì mới dùng được. Các chủ đề mới nhất khác với Xem các bài mới từ lần truy cập trước.

khoai
 
Go to Page:  First Page 1 2 3 5 6 7 Page 8 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|