Messages posted by: camazalraman

Mod xoá giúp mình một bài gửi nhé, gửi bài cho HVA toàn bị time out nên không biết đã gửi được một bài thành công.

Từ một máy laptop của thằng ku em, nó kêu có cái file lạ. Minh xin nó cái file đấy và "đút" vô cho chú chim Cuckoo "nhai".

File lạ có tên Data.pif
http://www.mediafire.com/download/5dwnv1px5m6y9z4/Data.rar

Sau khi cho chạy qua Cuckoo thì kết quả như sơ lược như sau
Kết nối đến host: trieutrung.no-ip.org
Droped xuống 2 file: aut1.tmp và temp.tmp
Sinh ra một loạt file, nhưng khả nghi nhất là file: spooler.exe
Chi tiết hơn thì mình gửi luôn kết quả phân tích của cuckoo.
http://www.mediafire.com/download/eat1ee3urlrez8y/10.rar

Lúc này, spooler.exe chạy như một service trong Service Manager của Windows. Cho Cuckoo "nhai" tiếp spooler.exe
http://www.mediafire.com/download/cznyj2fkzb1k5g9/spooler.zip
Kết nối đến host: trieutrung.no-ip.org
Chi tiết phân tích đây nhé
http://www.mediafire.com/download/xmlgb1i6dw30728/12.rar

Bác nào giúp phân tích tiếp xem mục đích của chú malware này định làm gì?
Thanks

daubac402 wrote:

Xin chào cả diễn đàn,
Như mọi người đã biết, thì một trong số các cách để vào facebook là sửa file hosts trong hệ điều hành
Trình duyệt thay vì hỏi DNS để biết IP của facebook.com sẽ dùng thẳng IP này rồi từ đó gửi request của mình.

Ví dụ như
12.34.56.78 facebook.com
x.y.z.t facebook.com
...

Trên mạng hiện nay, search ra có thể thấy rất nhiều các IP kiểu này. Nếu ta sử dụng sẽ vào được facebook tuy nhiên, trình duyệt sẽ báo đỏ ssl tại trang https://facebook.com/login.php.

Em đoán rằng IP mà ta vừa sửa không phải là IP của facebook thật mà nó chỉ là fake, nên khi CA kiểm tra thấy public key mà trình duyệt nhận về từ IP kia không đúng với IP thật mà facebook đã đăng ký với CA chăng.

Vậy thì cách thức để IP x.y.z.t kia sẽ lắng nghe ở port 80 và nhận được request từ trình duyệt rồi sẽ xử lý tiếp như thế nào? để giữa trình duyệt và facebook có thể trao đổi thông tin qua lại với nhau. Em vẫn không hiểu khâu này.

Em văn không được tốt, trình bày chưa mạch lạc, có gì mọi người cứ chỉ bảo ạ

Khi truy vấn ngược ip ví dụ "60.254.175.42" ( một trong số các ip sử dụng trong việc sửa file host để vào facebook) bạn sẽ thấy ip này thuộc công ty akamai.net

Khi view CA (lúc trình duyệt báo đỏ SSL khi đăng nhập facebook) bạn sẽ thấy CA này được cấp cho Common Name "a248.e.akamai.net"

akamai.net ( Akamai Technologies, Inc.) là công ty cung cấp dịnh vụ application hosting, content delivery, streaming media. Facebook là một trong các khách hàng của Akamai.

Mình chưa tìm hiểu thêm được tại sao Facebook không sử dụng CA được cấp cho Common Name Facebook.com mà lại sử dụng CA cấp cho akamai.net.

Bạn xác định đầu tư cho "an toàn thông tin và bảo mật mạng" nhằm mục đích "phòng chống tình trạng thất thoát dữ liệu". Với năng lực như bạn mình nghĩ bạn nên lập một kế hoạch triển khai đầy đủ, bắt đầu từ xác định mục tiêu, từ đó triển khai ra cần làm những gì.

Ví dụ như bạn muốn chống thất thoát dữ liệu nội bộ thì trong mục tiêu này bạn phải đảm bảo
- không mất dữ liệu do hỏng vật lý ( hỏng đĩa cứng, hỏng máy chủ...)
- Dữ liệu không bị làm sai lệch
- Dữ liệu không bị sao chép (mang ra khỏi công ty)

Từ đây đề ra các phương án cho mỗi tình huống, mỗi phương án cần thiết bị gì thực hiện ra sao.
Firewall cứng không phải thiết bị toàn năng, firewall không thể ngăn chặn người dùng mang dữ liệu ra ngoài công ty trong khi đó một số phương pháp đơn giản như khoá cửa phòng máy chủ, không cho mang máy tính cá nhân vào công ty, vô hiệu hoá các cổng usb cũng là những yếu tố góp phần chống việc thất thoát dữ liệu nội bộ

trycatch wrote:

Như bạn quanta nói rồi, mình bổ sung thêm theo cách hiểu của mình.
Hiện nay Token key các NH dùng thường có 2 loại sinh mã:
1: sinh theo event(mỗi lần bấm để sinh mã), nhược điểm là nếu cho trẻ em chơi thì nhanh phải thay token vì loại này giới hạn số lần bấm.
2: Sinh mã theo thời gian thực, loại này bấm thoải mái. Nhược là server xác thực của NH vì 1 lý do nào đó mà sai giờ thì coi như tèo. :d

Mình chưa gặp loại Token nào bấm để sinh mã ( không biết có loại này không)
Theo mình biết thì có 2 loại token thường dùng nhất là 30s và 60s ( thời gian hiệu lực của mã hiển thị trên token)
trong 2 loại đó thì có kiểu Token có thêm nút bấm để hiện mã và ẩn mã (không phải sinh mã, vì nếu bạn bấm nhiều lần trong 30s thì vẫn là 1 mã)
Nếu vì lý do nào đó, có thể là lệch thời gian mà token bị mất đồng bộ ( mã sinh ra trên server và token không trùng khớp nhau) thì bạn có thể đồng bộ lại ( token không tèo).

DK và DKIM là 2 phương thức khác nhau của việc ký và kiểm tra email

DK: Domainkey hiện nay là công nghệ không được tiếp tục phát triển và hỗ trợ nữa.
DKIM: là chuẩn mới, hiện đang được phát triển và khuyến cáo sử dụng

Thắc mắc 1: khi triển khai bạn chỉ sử dụng DKIM thôi.
Thắc mắc 2: mail của bạn relay qua một mail Gateway, nếu mail Gateway này đóng vai trò relay cho cả outgoing và incoming đến mail của bạn, thì bạn nên triển khai DKIM trên mail gateway

Xin lỗi mọi người, mình cung cấp thông tin hơi thiếu.

Môi trường test của mình như sau.

-sử dụng USB 3G có thể sử dụng được 3 loại sim ( Vina, Viettel, Mobi)
- USB 3G cắm vào Laptop Lenovo T61
- OS: win xp sp 3
- Firefox 3.5.1
- IE 8

Khẳng định chỉ có 3G Vina mới có hiện tượng đổi IP mỗi khi F5 trên http://www.whatismyip.com/

Thêm nữa, với việc IP thay đổi liên tục như vậy liệu:

- Các kết nối sẽ phải khởi tạo lại một cách liên tục
- Sử dụng 3G Vina dể DDOS

invalid-password wrote:

Do họ cấu hình cơ chế NAT thôi, muốn kiểu gì cũng được.

camazalraman wrote:

Liệu có liên quan đến bài này không nhỉ?
http://forum.bkav.com.vn/showthread.php?t=10226

BKIS "trình diễn" vớ vẩn, làm người ta mất 5 ngàn thì BKIS cũng mất 5 ngàn, trừ khi BKIS xài thuê bao còn victim xài lưu lượng.
Đây không phải là lỗ hổng bảo mật gì cả, có IP thì ping thấy nhau thôi, mạng nào chẳng vậy, trừ khi cấm các thuê bao local truy cập lẫn nhau mà chỉ cho ra ngoài internet (mà sắp cấm rồi, không thì nó gọi thoại data peer to peer thì di động có mà phá sản)

Vậy theo bạn là do cơ chế NAT, vậy tại sao riêng Vina lại thực hiện NAT với nhiều IP và IP thay đổi liên tục như vậy,
Mình đưa màn trình diễn của BKIS không phải là bàn đến việc ai làm ai mất tiền và mất bao nhiêu. Mình chỉ đưa ra một giả thuyết có thể liên quan đến sự khác biệt của 3G Vina so với Viettel và Mobi thôi.

Đúng là muốn kiểu gì cũng được, nhưng khi có sự khác nhau thì mình thắc mắc là tại sao lại làm khác, để làm gì, được lợi gì hay đơn giản vì thích.

Liệu có liên quan đến bài này không nhỉ?

http://forum.bkav.com.vn/showthread.php?t=10226

Hi all,

Hiện mình đang test với thiết bị 3G sử dụng sim Vina + sim Viettel + sim Mobi

Hiện tượng như sau:
sử dụng http://www.whatismyip.com/ để kiểm tra ip:
- Sim Vina: mỗi lần F5, trên www.whatismyip.com hiện ra IP bị thay đổi
( ip trên biểu tượng kết nối tại client không đổi)
- Sim Viettel và Mobi: mỗi lần F5, trên www.whatismyip.com hiện ra IP không bị thay đổi

Vậy cơ chế của 3G Vina có điểm khác như vậy để làm gì, là do chủ định của nhà mạng hay do điểm khác biệt về hạ tầng giữa các nhà mạng.

Bạn thử dùng hệ thống PMX của sophos, thằng này là mail gateway có thể thực hiện được một số yêu cầu của bạn như:
- check dung lượng mail ( check riêng attackment)
- check keyword blacklist do mình định nghĩa
- forwarmail về mail admin
- giữ lại toàn bộ mail đến hoặc đi và gửi một bản sao cho admin
- admin approve mail vẫn giữ nguyên trạng thái mail

Bạn mở IE rồi vào
Tool\Internet Options\Connections
Check vào "Never dial a connection" xem còn tự động connect nữa không nhé

Xem trong menu File/Work Offline có bị tick không

No.13 wrote:

Trên windows server phải dùng khóa AutoShareServer thay vì AutoShareWks nếu muốn disable administrative shares.

Cảm ơn bạn đã bổ sung.

Theo bạn trong trường hợp này tình trạng gửi packet theo thứ tự 1,2,3,4 và nhận theo thứ tự 2,3,4,1 sẽ xảy ra liên tục, vậy thì ngay sau khi kết nối được thiết lập, trong pha Slow Start với congestion window (cwnd) khởi tạo với 1 segment
- cwnd = 1 segment , ssthresh = 65535 bytes --> oki sender nhận được 1 ack trả về
- cwnd = 2 segment , ssthresh = 65535 bytes --> oki sender nhận được 2 ack trả về
- cwnd = 4 segment , ssthresh = 65535 bytes --> lúc này có thể sẽ nhận được 3 duplicate ack hoặc là 4 ack

nếu nhận được 4 ack thì cwnd sẽ tiếp tục tăng theo hàm mũ cho đến khi nhận được 3 duplicate ack hoặc bị mất gói tin. khi đó ssthresh = 1/2 cwnd, và bắt đầu lại quá trình Slow Start hoặc Congestion Avoidance

Trường hợp với mạng như bạn nêu việc nhận 3 duplicate ack sẽ liên tục -->vậy thì ngay từ đầu việc truyền dữ liệu đã bị "vùi dập" bởi giá trị cwnd sẽ không thể lớn được mà rất nhỏ ( có thể là 1packet) ngay từ quá trình thăm dò khả năng đường truyền (Slow Start).

Mình có chút ý kiến như vậy.
Để thảo luận tiếp mọi người có thử đưa ra giải pháp khắc phục mà vẫn sử dụng mô hình kết nối như ban đầu thì sao nhỉ

Mặc định win xp và win server 2003 đã găn chặn việc enumeration của các kết nối nặc danh (null session) ngoài trừ domain controller.

Nếu chỉ chạy một file *.reg với nội dung duy nhất:

(Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"AutoShareWks"=dword:00000000)

Như bạn nói thì không thể nói là hạn chế lỗi null session được, bởi vì sau khi chạy file này xong các share ẩn như c$, d$..... sẽ bị disable. Khi đó các kết nối nặc danh sẽ không thể liệt kê được các share ẩn c$, d$.... những vẫn có thể liệt kê được các thông tin khác.

Trong trường hợp này:
- nếu *.reg chạy trên xp hoặc win 2003 không phải là DC thì chỉ có tác dụng disable share admin, không liên quan đến lỗi null session (bở lỗi này mặc định đã bị ngăn chặn) không cần enumeration cũng biết là có share admin smilie

- nếu *.reg chạy trên DC thì chỉ có tác dụng disble share admin, không hạn chế được lỗi null session

Topic này có vẻ không thêm được thảo luận nào nữa,
Bạn StarGhost cho đáp án đi vậy.

Thanks

Giao thức Torrent không hoạt động như bồ nghĩ và đang định thực hiện đâu.
Bồ tham khảo xem:http://vi.wikipedia.org/wiki/BitTorrent
Có vẻ như bồ định làm một trang web rồi dụ ai đó vào và dùng nó theo dõi được người ta đang lướt web ra sao thì phải ????

Header của một mail spam với From và To giống nhau, ví dụ abc@mycompany.com gửi cho chính abc@mycompany.com

Received: from mycompany.com ([x.x.x.x]) by mycompany.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 6 May 2009 19:36:50 +0700
Received: from PC-BELSERS ([84.160.105.68]) by mycompany.com with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 6 May 2009 19:36:49 +0700
X-Originating-IP: [02.5.920.238]
X-Originating-Email: [xxx@mycompany.com]
X-Sender: xx@mycompany.com">xxx@mycompany.com
Return-Path: xx@mycompany.com">xxx@mycompany.com
To: xx@mycompany.com">xxx@mycompany.com
Subject: RE: SALE 70% 0FF on Pfizer
From: VIAGRA ® Official Site <xxx@mycompany.com>
MIME-Version: 1.0
Importance: High
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <01n3GCIFoPk00000a38@mycompany.com>
X-OriginalArrivalTime: 06 May 2009 12:36:49.0524 (UTC) FILETIME=[53797B40:01C9CE47]
Date: 6 May 2009 19:36:49 +0700

mR.Bi wrote:

Chuyện gì xảy ra nếu window size quá nhỏ?

Theo em nghĩ window size quá nhỏ ảnh hưởng tới tcp performance, nếu window size nhỏ thì quá trình gửi nhận dữ liệu sẽ lâu.
Nếu nói window size của receiver là 1 byte, có nghĩa: receiver chỉ có thể tiếp nhận tối đa 1 byte một lần client gửi dữ liệu trược khi nhận ACK.
Nhưng nếu như thế tại sao không thiết lập window size lên 1 GB cho nhanh, mà còn giảm thiểu nguy cơ TCP buffer overload nhỉ?

Mình thấy đoạn này trên wiki khá hay, làm rõ một số vấn đề mọi người đang thắc mắc
http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Flow control

TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to reliably receive and process it. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate. For example, when a fast PC sends data to a slow hand-held PDA, the PDA needs to regulate the influx of data, or protocol software would be overrun quickly.[2] Similarly, flow control is essential if the application that is receiving the data is reading it more slowly than the sending application is sending it.

TCP uses a sliding window flow control protocol. In each TCP segment, the receiver specifies in the receive window field the amount of additional received data (in bytes) that it is willing to buffer for the connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host.
When a receiver advertises a window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from a deadlock situation that could arise if the window size update from the receiver is lost and the sender has no more data to send while the receiver is waiting for the new window size update. When the persist timer expires, the TCP sender sends a small packet so that the receiver sends an acknowledgement with the new window size.

If a receiver is processing incoming data in small increments, it may repeatedly advertise a small receive window. This is referred to as the silly window syndrome, since it is inefficient to send only a few bytes of data in a TCP segment, given the relatively large overhead of the TCP header. TCP senders and receivers typically employ flow control logic to specifically avoid repeatedly sending small segments. The sender-side silly window syndrome avoidance logic is referred to as Nagle's algorithm.

Congestion control

The final main aspect of TCP is congestion control. TCP uses a number of mechanisms to achieve high performance and avoid 'congestion collapse', where network performance can fall by several orders of magnitude. These mechanisms control the rate of data entering the network, keeping the data flow below a rate that would trigger collapse.

Acknowledgments for data sent, or lack of acknowledgments, are used by senders to infer network conditions between the TCP sender and receiver. Coupled with timers, TCP senders and receivers can alter the behavior of the flow of data. This is more generally referred to as congestion control and/or network congestion avoidance.

Modern implementations of TCP contain four intertwined algorithms: Slow-start, congestion avoidance, fast retransmit, and fast recovery (RFC2581).

In addition, senders employ a retransmission timer that is based on the estimated round-trip time (or RTT) between the sender and receiver, as well as the variance in this round trip time. The behavior of this timer is specified in RFC 2988. There are subtleties in the estimation of RTT. For example, senders must be careful when calculating RTT samples for retransmitted packets; typically they use Karn's Algorithm or TCP timestamps (see RFC 1323). These individual RTT samples are then averaged over time to create a Smoothed Round Trip Time (SRTT) using Jacobson's algorithm. This SRTT value is what is finally used as the round-trip time estimate.

Enhancing TCP to reliably handle loss, minimize errors, manage congestion and go fast in very high-speed environments are ongoing areas of research and standards development. As a result, there are a number of TCP congestion avoidance algorithm variations.

Vậy vấn đề là gì vậy bạn ?

Dear all,
Mình có một mô hình mạng như sau:
VPN server(RRAS trên window server 2003) <--> Router cisco 1800(NAT) <--> Internet-VPN

-Server cấu hình cả PPTP và L2TP
-Router cấu hình NAT, IOS của Router là version 12.4 đã hỗ trợ Nat-t
Từ Internet kết nối VPN PPTP thành công
Từ mạng trong VPN L2TP không đi qua Router hoặc đi qua Router mà không NAT cũng thành công
Từ mạng trong VPN L2TP đi qua router có NAT không thành công
Từ Internet kết nối VPN L2TP không thành công

Ai đã cấu hình Router thành công trường hợp này xin chỉ giáo mình với?
Thanks & Regards