Em đã đọc qua tất cả các bình luận của các anh, trước khi nói về nhận xét của mình em muốn hỏi các anh một cậu : Trojan hoàn toàn không có một ích lợi nào trong mọi trường hợp và tất cả những ai viết hay sử dụng nó đều là người xấu ? ( Câu hỏi này em muốn nhận đc câu trả lời từ tất cả các mem trong diễn đàn, nhất là anh Conmale và anh TQN ) 

anh conmale ơi,cho em nói câu.Thật sự thì em không đồng ý với comment của anh.Vì học CNTT thì ắt hẳn biết càng nhiều càng tốt.Nếu mà virus,trojan,worm...thuộc lĩnh vực CNTT mà chúng ta cũng không biết tạo ra thì có phải là CNTT của ta mơ hồ quá không.Biết là nó là xấu nhưng chúng ta biết nhiều thì chúng ta chưa chắc hẳn xấu,xấu chăng là những người sử dụng nó với mục đích gì thôi.Chúng ta biết mà chúng ta chỉ cùng nhau học tập nghiên cứu không viết để phá hoại ai thì nó đâu có gì xấu cũng như những bông hoa sen vẫn ngát hương mặc dù sống trên những mảnh đất bùn.Virus không xấu có chăng là ai đã viết nên nó và xử dụng với mục đích gì,có khi virus,trojan,...cứu cả một quốc gia,thế giới trong việc thu thập tài liệu để phá huỷ một âm mưu chống lại khủng bố hạt nhân của bọn khủng bố chẳng hạn.Uh em có suy nghĩ vậy thôi anh conmale đừng giận nhé. 

conmale wrote:

Anh không gọi nhà cung cấp dịch vụ hosting mình đang dùng là ISP (Internet Service Provider) mà họ là Data Center thì đúng hơn. ISP chỉ đúng cho người bình thường cần truy cập Internet.

Về việc null-routing mà Data Center ở đây cung cấp, anh nghĩ một phần là do mình trả phí thuê máy chủ khá đậm (vì có cấu hình khá và băng thông rộng) và một phần là do họ cần làm như vậy để bảo đảm chất lượng dịch vụ. 

ISP có trách nhiệm cao hơn phía Data Center bởi vì 1 Data Center thông thường phải mướn, phải thuê 1 đường truyền từ ISP sang với tốc độ băng thông phía DataCenter yêu cầu.

Ở VN theo em thấy dường như khái niệm null-routing em chưa thấy ở các nhà cung cấp dịch vụ !!! Đọc bài viết này của anh, tra cứu thêm mới tận tường thêm nhiều điểm mình chưa biết.  

anh conmale cho em hỏi một chút được ko ạ,vì em là newbie nên ko được rõ lắm
hi vọng anh và các anh có thể giúp e!!!
e đã tìm được IP của một máy đích, vậy việc tiếp theo để xâm nhập vào máy của họ sẽ phải làm như thế nào ạ
mong các anh có thể chỉ giáo giúp e
yahoo e : lovepost01,mong mọi người giúp đỡ  

mệt quá chừng,đang theo dõi để học mà gặp mấy bác chém nhau như thế này,em ko biết làm sao? Mấy bác có gì hay đóng góp cho anh em học hỏi,để tiếp thu. Chứ nói thật mấy bác làm vậy chả được cái gì hết. Nói thật cái tôi của mấy bác lớn quá. Tôi đang cần và muốn học anh văn nên vào diễn đàn để xem mà thấy toàn chém...và chém..nản hết sức. 

conmale wrote:

thinh191 wrote:

conmale wrote:

thinh191 wrote:

Mọi người ơi cho e hỏi chút.E có 1 con dcom 3g .Khi vào mạng nó được cấp địa chỉ ip là 27.69.46.251 .Đây có phải là địa chỉ ip cá nhân không ak .Nếu em muốn share 1 ổ của mình rồi truy cập vào đó qua mạng internet bằng chính địa chỉ ip đó thì có đc không .Em thấy nếu truy cập vào 1 địa chỉ ip thì cần phải có user và pass , nhưng làm thể nào để set user và pass ip cho chú dcom của e ak .Xin cảm ơn các bác đã đọc , rất mong các bác giúp đỡ vs ak 

Chủ đề này có liên quan gì đến "thâm nhập"? 

thì em thấy rằng nếu " truy cập " từ bên ngoài vào mà không được phép thì có thể gọi là " thâm nhập " chứ ak .
Em muốn thử ở cấp độ thấp nhất là share ổ và truy cập từ ngoài vào thông qua ip đó . 

Trong bài đầu tiên của bồ chỗ nào nói tới chuyện "không cho phép"? 

vâng .Em trình bày còn kém mong bác thông các .Bác có thể giúp e trả lời câu hỏi
"Nếu em muốn share 1 ổ của mình rồi truy cập vào đó qua mạng internet bằng chính địa chỉ ip 27.69.46.251 thì có được không ak .Và nếu được thì phải làm thế nào ak" 

conmale wrote:

thinh191 wrote:

Mọi người ơi cho e hỏi chút.E có 1 con dcom 3g .Khi vào mạng nó được cấp địa chỉ ip là 27.69.46.251 .Đây có phải là địa chỉ ip cá nhân không ak .Nếu em muốn share 1 ổ của mình rồi truy cập vào đó qua mạng internet bằng chính địa chỉ ip đó thì có đc không .Em thấy nếu truy cập vào 1 địa chỉ ip thì cần phải có user và pass , nhưng làm thể nào để set user và pass ip cho chú dcom của e ak .Xin cảm ơn các bác đã đọc , rất mong các bác giúp đỡ vs ak 

Chủ đề này có liên quan gì đến "thâm nhập"? 

thì em thấy rằng nếu " truy cập " từ bên ngoài vào mà không được phép thì có thể gọi là " thâm nhập " chứ ak .
Em muốn thử ở cấp độ thấp nhất là share ổ và truy cập từ ngoài vào thông qua ip đó . 

Mọi người ơi cho e hỏi chút.E có 1 con dcom 3g .Khi vào mạng nó được cấp địa chỉ ip là 27.69.46.251 .Đây có phải là địa chỉ ip cá nhân không ak .Nếu em muốn share 1 ổ của mình rồi truy cập vào đó qua mạng internet bằng chính địa chỉ ip đó thì có đc không .Em thấy nếu truy cập vào 1 địa chỉ ip thì cần phải có user và pass , nhưng làm thể nào để set user và pass ip cho chú dcom của e ak .Xin cảm ơn các bác đã đọc , rất mong các bác giúp đỡ vs ak 

THeo mình HVA ta nên mở 1 khoá học bảo mật onli, và chi phí là bao nhiêu xin HVA cứ nới, AE se chuyển tiền qua tài khoản tín dụng, và ta nên lập 1 phòng học onli, và nhưng thnahf viên nào nộp tiền thì mới được vào phòng học onli này, mong BQT hãy cân nhắc vần đề này, thì nếu ta có thể tổ chức được thì kiến thức và bề sau, rộng của HVA sẽ được AE tín nhiệm nhiều hơn 

conmale wrote:

Cho đến bây giờ vẫn chưa thu thập được những thông tin cốt yếu để xác định HVA vừa bị tấn công cụ thể như thế nào bởi vì ngay khi luồng DDoS ập vào thì nhà cung cấp dịch vụ đã "null-route" trọn bộ traffic đến IP của HVA. Bởi thế, từ bên trong máy chủ, mình không có cách nào capture được thông tin cụ thể.

Xét trên biểu hiện tổng quát thì dường như đây là một dạng spoof IP để DDoS bởi vì trên logs của máy chủ có một số thông tin về cảnh báo spoof IP ngay trước lúc nhà cung cấp dịch vụ tiến hành "null-routing". Đây chỉ là phỏng đoán và không chắc là đúng vì không có bằng chứng cụ thể ở cấp độ "packet".

Giải pháp hiện thời là tạo ra một loạt (càng nhiều càng tốt) các reverse proxies đứng trước HVA để chẻ traffic ra thành nhiều phần nhỏ nhằm tránh tính trạng 1 máy chủ bị "null-route". 

Anh conmale cho em hỏi là ISP tiến hành "null-routing" là do họ tự nguyện hay là do anh thuê cái dịch vụ "null-routing" này của họ? Nếu họ tự nguyện thì anh có biết lí do tại sao họ lại bỏ công sức ra làm vậy hay không?

Cám ơn anh. 

Đã gửi mà không thấy phản hồi.  

mình đã thực hành cái này khá nhiều trong mạng LAN rồi , nhưng có một thắc mắc là nếu xài metasploit qua mạng WAN thì có được không , nếu được thì các bước làm khác gì so với làm trong LÁN, search qua google thì thấy nó kêu phải NAT port nhưng mình cũng chưa hiểu rõ lắm nên post bài hỏi mọi người , ai biết thì giải đáp giùm mình nhé . Thanks  

conmale wrote:

Mình đang nói đến điểm mạnh và yếu của giao thức mà. Mình chưa bàn đến băng thông.
 

Nói về khả năng chống DDoS của IPv6, hay nói đúng hơn là của IPSec, nhận định của em là như sau:
- Giống như TCP SYN flood, IKEv2 hoàn toàn có thể bị DDoS bằng cách tương tự với các kết nối half-open từ fake(forged) IP.
- Cả TCP và IKEv2 đều hỗ trợ cookie, chỉ riêng điểm này đã nói lên vấn đề với IKEv2
- IKEv2 tệ hơn TCP ở chỗ, khi không hỗ trợ cookie, IKEv2 cần nhiều computing power hơn để xử lý half-open connections, vì nó phải giải mã packet.
- Cả TCP và IPSec đều chống được IP spoofing/forging cho các layer cao hơn nó.
- IPSec có lợi thế hơn TCP ở chỗ nó hoạt động ở IP layer, còn TCP ở tầng cao hơn, và vì thế quá trình bóc tách headers cho mỗi packet cũng ít hơn 1 lần.
- Tuy nhiên, với các kiểu DDoS giả dạng flash crowds, TCP chắc là "sống khoẻ" hơn IPSec nhiều vì nó không đòi hỏi encryption và integrity check.

Từ đó, em nghi ngờ về nhận định rằng với việc IPv6 được sử dụng đại trà, tình trạng và hậu quả của DDoS sẽ được cải thiện.
 

conmale wrote:

Chuyện DDoS thì không bao giờ có thể triệt tiêu hoàn toàn được. Chỉ có thể giảm thiểu. 

Đây là vì anh chỉ đứng dưới góc độ của end systems nên mới có nhận định như thế. Cái em muốn thảo luận là về các đặc điểm của một mô hình lí tưởng mà ở đó có thể (chỉ là ví dụ) botnets vẫn tồn tại, nhưng mà dùng nó đi tấn công bất cứ hệ thống nào, dù nhỏ dù lớn, dùng bất cứ phương pháp gì (kể cả bandwidth DDoS) cũng không còn nhiều tác dụng (ví dụ: bị dập tắt chỉ sau 5-10 phút). Bối cảnh đó khác hoàn toàn với tình trạng "sống chung với lũ" và "mạnh ai nấy lo" hiện nay. 

Hi anh conmale,

Anh cho em hỏi theo anh thì cơ chế "bắt tay" phải thay đổi như thế nào thì các dạng flood bằng TCP, UDP và ICMP mới có thể được ngăn chặn được ? Thanks anh

-rickb
 

conmale wrote:

- Nếu chủ nhân không muốn tham gia DDoS và là nạn nhân thì trước tiên chỉ có mỗi "nạn nhân" ấy bị block thay vì hàng loạt người bị block như tình trạng hiện nay. Cái này giúp giảm thiểu "từ chối dịch vụ" do chính biện pháp ban. Nếu 100000 static IPv6 IP bị ban thì chỉ 100000 IP đó bị ban thay vì 100000 x 10 hoặc x 100 bị ban như IPv4 hiện nay thì vẫn tốt hơn.
 

À như vậy thì hậu quả DoS so với IPv4 được giảm đi 10 hoặc 100 lần. Nhưng mà như vậy liệu đã phải là cái đích cuối cùng của cuộc chiến chống DDoS?

conmale wrote:

- IP Spoofing không tồn tại với IPv6 được.
 

Ở đây theo em hiểu ý của anh là receiver hoàn toàn có thể xác định IP address của sender trước khi tiến hành communicate ở các layer cao hơn. Điều này thì em đồng ý. Tuy nhiên IPv6 với IPSec căn bản không có chống được ai đó spoof (hoặc nói đúng hơn là fake) IP address và gửi packet khi bắt đầu IKE. Dù IKE có khả năng chịu đựng DDoS tốt hơn các protocol ở layer cao như TCP, nhưng hoàn toàn khác với việc chỉ cần nhìn IP address sau đó drop và drop.

conmale wrote:

- Người bị DDoS (chủ máy, chủ hệ thống) ban chớ chẳng có ISP nào ban cả. Người bị DDoS có trọn quyền cho phép hoặc ban bất cứ nguồn IP nào vi phạm. Nếu "nạn nhân" bị ban vì chính máy mình là zombie thì người bị ban phải có trách nhiệm tự xoá zombie, tự phục hồi để không bị ban.
 

Vậy còn vấn đề bandwidth DDoS thì sao anh? Nếu bandwidth của anh bị bão hoà thì dù anh có cấu hình firewall kiểu gì cũng vô ích.
 

Cảm ơn anh, nhưng em chưa hiểu cái yêu cầu đầu tiên cho lắm.
Anh có thể giải thích giúp em "All your session attributes must implement java.io.Serializable" là gì và mình nên làm những gì không ạ ?
Cảm ơn anh 1 lần nữa. 

Vâng, Em cảm ơn Anh! Hệ thống này, em setup cả nginx,jetty trên cùng 1 server và nó cấu hình: CPU 2 cores, RAM 4G, hiện tại tối đa chỉ 4-50 connections đồng thời.
Với những ý kiến của anh, em fix lại như sau:
Với Kernel: /sbin/sysctl -w net.core.somaxconn=512
Với nginx.conf:
worker processes 2;
....
upstream localhost {
server 127.0.0.1:8080;
}
....
proxy_pass http://localhost;
proxy_read_timeout 75;
proxy_connect_timeout 75;

Với jetty.xml:
<Set name="connectors">
.....
<Set name="Acceptors">2</Set>
<Set name="acceptQueueSize">512</Set>
.....
</Set>

Đó là những chỉnh sửa của em, anh xem, rồi cho ý kiến ạ!

Em xin cảm ơn! 

To run session replication in your Tomcat 7.0 container, the following steps should be completed:

All your session attributes must implement java.io.Serializable
Uncomment the Cluster element in server.xml
If you have defined custom cluster valves, make sure you have the ReplicationValve defined as well under the Cluster element in server.xml
If your Tomcat instances are running on the same machine, make sure the tcpListenPort attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100
Make sure your web.xml has the <distributable/> element
If you are using mod_jk, make sure that jvmRoute attribute is set at your Engine <Engine name="Catalina" jvmRoute="node01" > and that the jvmRoute attribute value matches your worker name in workers.properties
Make sure that all nodes have the same time and sync with NTP service!
Make sure that your loadbalancer is configured for sticky session mode.
 

conmale wrote:

Tôi vào trang đó và ctlr + 4 lần cũng không bị cuộn gì hết.
 

Anh thử với link em đưa ở trên chưa: /hvaonline/posts/list/42771.html