Messages posted by: vd_

@hackerbeyeu

xnohat nói đúng rồi, bạn nên tìm hiểu hash có nghĩa là gì đã. Nếu có key thì gọi là encrypt chứ không gọi là hash. Hash là giải thuật 1 chiều nên có hash không có cách suy ngược lại giá trị gốc.

@conmale

Off topic tí xíu, không rõ anh conmale có "cố ý" nhầm vd_ với rd hay không? Hồi xưa IRC vietlug có rd (phải chăng là reddragonvn ?) rd nếu không lầm thì đã là giỏi lắm rồi, vd_ chì xách dép ngồi học hỏi các anh thôi.

@conmale

Chính xác là site chính lẫn site transaction đều cần phải bảo mật, nhưng cũng vì SSL đòi hỏi computation power cao hơn, và đảm bảo dữ liệu trên đường truyền không bị sniff (nếu customer thực sự có kiến thức) nên SSL sẽ được áp dụng cho những site cần bảo vệ thông tin hơn là sử dụng cho site chính.

Lần thứ 2 anh conmale viết nhầm tên tui nhé, tui là vd_ , không phải là rd_

@myquartz
SSL ngoài việc encrypt còn có ý nghĩa authen, ví dụ làm sao bạn biết www.techcombank.com.vn là thuộc về Techcombank smilie

Nếu bạn mua Verisign (Extend Validation chẳng hạn) thì bạn sẽ phải chứng minh với Verisign bạn đúng là Techcombank. Khi đó các customer của bạn khi visit site www.techcombank.com.vn sẽ thấy được Verisign xác nhận site www.techcombank.com.vn thuộc về Techcombank.

SSL còn giúp tránh bị sniff, tuy nhiên nếu customer không kiểm tra kỹ và không quan tâm đến các thông báo của browser thì cũng dính fake cert như thường.

@vina_man

Tui nghĩ bạn nên tìm hiểu về HTTP protocol để hiểu thêm tại sao phải cần có cookies. (hint: HTTP is a stateless protocol). Hiểu về vai trò của cookie thì bạn mới biết tại sao phải steal, forge hoặc fixate nó (hint: thẻ giữ xe của bãi xe smilie

)

@shuichi_akai
X-Real-IP và X-Forwarded-For thì dùng log được, nhưng cái Host sẽ rất quan trọng để reverse proxy cho đúng. Bạn kiểm tra thêm các response từ server về client sẽ thấy tác dụng của Host. Bạn xem thêm http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html phần 14.23 có đề cập vai trò của field Host.

@conmale

Hiển nhiên khi default policy là drop và không có matching rule thì sẽ không có count.

Cũng chính vì suy nghĩ netfilter sử dụng các table như hình anh conmale đưa mà vd_ (không phải rd smilie

) nghĩ vị trí thích hợp để -j DROP các bad IP là ở table raw, chain PREROUTING.

@conmale

Bữa nay mới thử setup để test thử việc send udp đến port 9 để xem coi nó có đi qua các chain hay không.

Hệ thống gồm:
- máy linux A 172.16.34.1 chạy debian sid
- máy windows B 172.16.34.222 chạy windows, có cài oscinato (traffic generator)

Rule iptables trên A:

# iptables -t nat -I PREROUTING -s 172.16.34.222 -p udp --dport 1999 -j REDIRECT --to-port 9
# iptables -A INPUT -s 172.16.34.222 -p udp --dport 9 -j ACCEPT

run netcat vào null

# netcat -l -u -p 9 > /dev/null &

Oscinato trên B:
port group là card mạng, create new stream với các thông số sau:

tab Protocol selection
frame length fixed (64), L1 = MAC, L2 = Ethernet II, L3 = IPv4, L4 = UDP, L5 = none, VLAN untagged

tab Protocol data:
Media Access Protocol -> đưa MAC của A vào phần source, và MAC của B vào phần dest
Ethernet II -> check vào ethernet type 08 00 (default - ip4)
UDP -> Override source port = 9999, Override dest port = 1999
Payload Data -> Fix word = 0 1 2 3

tab Stream control
Send = packet, Mode = Fixed, Number of packets = 100, After this stream = go to first (tức là sẽ loop ở đây), rate = 2 packet/s

Tổng kết cấu hình:
Máy B sẽ send 2 packet UDP/s từ port 9999 vào port 1999 của máy A, đồng thời ở Máy A có rule để match các UDP packet từ máy B gửi đến port UDP 1999 của máy A và wwwect từ port 1999 sang port 9 trong table nat của iptables. Đồng thời user process netcat listen trên udp port 9 và vứt bỏ packet.

Trong oscinato tiến hành gửi packet, mở console root bên máy A lên và type vào
# watch iptables -L -n -v

Ta sẽ thấy rule iptables của chúng ta nhập được match (số lượng packet tăng) ->nghĩa là rule wwwect ở table nat match và rule accept trong table filter được match. Kill netcat process thì rule trong table filter vẫn tăng match count.

Như vậy có thể kết luận là udp packet thực sự có traverse đến table filter cho đến khi match 1 rule, bất kể có service nào đăng ký listen hay không.

Theo suy nghĩ của tui là cũng hợp logic khi ở kernel, xử lý packet sẽ không quan tâm nhiều đến ý nghĩa quy ước của port number. Đằng nào thì kernel cũng xử lý xong packet mới handle sang user space process. Tuy nhiên cũng có thể có những optimization nào bên dưới để xử lý các trường hợp ngoại lệ như thực tế đã chứng minh.

@mrro

Xin ý kiến của mrro về nhận định ở trong blog post này http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html

Theo đó thì với tỷ lệ CPU giữa client : server thì việc client có thể làm tốn CPU của server khá nhiều. Như vậy thì chừng vài chục máy trạm là có thể làm quá tài server? DOS ở đây sẽ là DOS về CPU chứ không còn là network nữa.

@mrro

- Tui sẽ bookmark cái SNI này để khi nào nó được support nhiều hơn sẽ triển khai thử
- Tiếc là hiện tại support cho SNI vẫn chưa đủ rộng để tui ứng dụng smilie

(IE trên XP ... )

@freakmind

cert chứa domain trong CN, nên client kiểm tra là kiểm tra domain name. Còn việc hạn chế 1 ip - 1 cert là do hạn chế của Name Virtual Host đối với apache httpd http://wiki.apache.org/httpd/NameBasedSSLVHosts

Trong tài liệu bạn gửi có sơ đồ cụ thể cho việc này. Lúc thiết lập SSL thì HTTP GET request chưa được web server handle nên chưa thể xử lý Name Virtual Host (field Host trong HTTP request) -> 1 ip chỉ có thể gắn với 1 cert, tuy nhiên không có ai cấm bạn sử dụng 1 cert cho nhiều ip, tất nhiên với điều kiện là các ip đó đều resolve ra 1 domain đã ghi trong CN của cert đó.

@freakmind

Xin bạn nói rõ hơn việc 1 cert chỉ gắn với một ip và domain?

Theo tui nghĩ thì cert chỉ gắn với domain. Domain có thể có nhiều ip (load balancing).

Xin nói thêm nếu arp poison + sslstrip thì attacker có thể lấy được session cookie

http://vi.wikipedia.org/wiki/TCP

3way handshake xong thì mới gửi các packet dữ liệu. Các packet dữ liệu nôm na là cái file của bạn bẻ nhỏ ra.

@khang0001
www.frozentux.net/documents/iptables-tutorial/

@khang0001
kiểm tra <CHROOT>/etc/passwd và <CHROOT>/etc/group coi có user apache & group apache chưa.

httpd báo error bad username apache nghĩa là nó đã chạy với username apache, nhưng nó không kiếm ra username apache ở đâu hết.

@mrro
Ngưỡng mộ mrro.

Tui đang đợi có thêm chi tiết để hiểu thêm và tìm cách mitigation.
Theo bài viết trên ImperialViolet (http://www.imperialviolet.org/2011/09/23/chromeandbeast.html) thì server ssl sử dụng cipher suit RC4 (?) sẽ không bị ảnh hưởng.

Bữa hổm tui thử config server để disable tất cả cipher suit có CBC (thiệt xấu hổ, không rành lằm nên nhắm mắt cái cipher suit nào có CBC là tắt hết) thì chỉ có 1 số browser mới như Chrome 14, Firefox 6 access được, còn các browser cũ ngủm hết, đành phải set lại như cũ. Hy vọng sớm có thêm những bài phân tích cho newbie như tui để hiểu thêm.

Một lần nữa chúc mừng mrro và cho phép tui bày tỏ sự ngưỡng mộ.

Bạn down Mod Security Core Rule Set trên OWASP về, rồi tham khảo rule 35, 40, 41, 50. Các rule đó có sử dụng operator @pmFromFile để so sánh modsec variable (trong trường hợp của bạn là REMOTE_ADDR) với các giá trị trong 1 file.

Bạn đọc thêm reference manual của ModSec ở đây nữa http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual

Mà bạn thử giải thích ý nghĩa của 3 dòng SecAction và SecRule của bạn viết dùng để làm gì để mọi người góp ý thêm coi có đúng với ý định của bạn không?

Dòng này trong config của bạn accept ssh từ mọi nơi rồi

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Bạn kiểm tra xem coi mod_unique_id.so có trong directory modules của apache hay không?
Bạn chạy thêm httpd -t rồi paste thông báo lỗi lên thì mọi người mới giúp được

@mv1098
Việc stuxnet có được private key của Realtek chưa ai dám truy xét thêm vì ai cũng đoán là việc làm của những tổ chức không nên đụng vào smilie

Biết đâu Realtek tự nguyện dâng private key smilie

( xem thêm http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1 )

Tui đồng ý với ý kiến của cino, trừ phi có private key, không thì không thể sign một binary mà kiểm tra trust chain thấy valid được.

Việc có private key thì có thể thông qua việc hack root CA (ví dụ DigitNoTar.nl gần đây, hoặc Comodo trước đó) để tạo ra chứng chỉ số và sign vào chứng chỉ số đó.

@TQN rất cảm ơn anh về nỗ lực làm trong sạch môi trường IT Việt nam.

@chiro8x

my bad, bạn đã dùng strtolower() để xử lý được hoa thường, tuy nhiên tui vẫn giữ ý kiến là giải pháp tốt nhất vẫn là kiểm tra các thông số đưa vào SQL thay vì nối chuỗi để thành sql.

Việc kiểm tra các keyword sql cũng như kiểm tra param đưa vào xem coi có trùng với pattern của sql không là một việc khá phức tạp, không thể chỉ dùng 1 hoặc 2 regex là có thể giải quyết được (bạn xem thêm ModSecurity Core Rule Set, phần rule SQL injection để thấy một số regex phát hiện sql injection).

Bạn cũng tham khảo thêm http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html để thấy một số kỹ thuật tránh detection.

Cảm ơn anh conmale.

Thiệt tình vẫn cảm thấy không ổn lắm vì các wwwect này sẽ phải tốn thêm 1 process (netcat chẳng hạn) để bỏ packet, như vậy thì packet vẫn đi từ card mạng đến user process, tức là pass qua toàn bộ các table và chain của iptable (?), trong khi với dòng drop thì packet được drop ngay từ lúc PREROUTING.

Mà thực tế (đã được chứng minh) nhiều khi lại khác với những gì mình nghĩ nên bữa nào quởn phải nghiên cứu thử vụ này.

@mrro

- Đồng ý càng nhiều code xử lý sẽ càng có nhiều lỗ hổng tiềm tàng, tuy nhiên việc này giống con gà và quả trứng: muốn giảm rủi ro thì cần nhiều control & handler -> lại càng nhiều code -> lại có thể có lỗi tiềm tàng. Tui nghĩ đến nhiều engine là thiết kế theo dạng multi layer (giống bộ lọc số - filter pass), mỗi engine sẽ được chạy trong 1 isolate container (lxc chẳng hạn), như vậy thì engine này miss thì engine khác sẽ có thể capture được. Hoặc là nếu 1 engine bi crash thì sẽ không ảnh hưởng đến engine khác. Nếu có thêm watchdog service để watch các isolate container thì sẽ kiểm tra được các sự kiên bất thường. Tuy nhiên, vấn đề la gmail là free, nên có cần phải overkill vậy hay không -> quay trở lại việc đánh giá rủi ro: nếu thấy đáng giá thì nên làm, không thì đành vậy smilie

- regex đã viết không có : trong phần domain nên chắc các url dạng domain:port sẽ không match.

Còn về vấn đề url utf8 là tui nhầm lẫn, chuẩn không cho phép, chỉ có browser tự động encode non-ascii về ascii. Sorry, my bad.

- Cách thực hiện phân tích file download về bằng các giải thuật AI thì hiện giờ tui cũng chỉ mới ở mức ý tưởng, cũng chưa có thời gian đào sâu. Chắc phải suy nghĩ thêm mới có thể trả lời cho mrro được.

Tui lấy ý tưởng từ việc nhận dạng chữ viết/giọng nói. Đối với việc nhận dạng trong AI, bài toán đặt ra là làm sao biết được chuỗi binary tương ứng với ngữ nghĩa gì. Ở đây nếu mình coi file (hoặc network session) là một chuỗi binary, thì mình sẽ phải dựa vào các giải thuật AI để đưa ra quyết định chuỗi binary đó là độc hại hay không.

@secmask

Nếu đã sign vào pdf thì không thể chỉnh dữ liệu được, nếu cố ý chỉnh thì đến khi người khác mởi ra sẽ thấy ngay là có người sửa.

Nguyên lý tóm tắt như sau:

Tui là tác giả, tui tạo pdf xong, hash nội dung của pdf thành giá trị S, xong rồi encrypt = private key của tui (S1), rồi đính kèm chuỗi binary đã encrypt vào.
Đến khi đọc lên, pdf reader cũng hash nội dung, rồi dùng public key của tui decrypt chuỗi binary ra.
Nếu 2 giá trị hash và đã decrypt bằng nhau thì chứng tỏ nội dung không thay đổi.
Do giá trị S1 tạo ra từ private key của tui nên chỉ có thể decrypt bằng public key của tui -> không thể tạo ra giá trị S1 nếu không biết được private key của tui.

@conmale

Xin hỏi thêm ngoài lề anh conmale, việc wwwect udp sang port 9 so với việc drop udp packet thì cái nào sẽ lợi hơn?

iptables -t mangle -I PREROUTING -p udp -j REDIRECT --to-ports 9

or

iptables -t mangle -I PREROUTING -p udp -j DROP

@jin9x
4a. dùng passive finger printing (p0f) có thể đoán được 1 tí, nếu traffic từ gmail đủ lớn. Tuy nhiên không quá tin cậy được.

4b. Vấn đề nếu gmail chỉ đơn giản là down về chuyển thành attachment, không có render để preview thì gmail đâu có parse & thực thi js

@mrro
b3. việc phát biện bộ quét virus có thể sử dụng 1 cách đơn giản là sử dụng các mẫu đặc biệt mà 1 engine này phát hiện, nhưng engine khác không phát hiện (virustotal?). Không dễ, nhưng tui nghĩ là khả thi. Về phía defense, sử dụng 2 engine hoặc là sử dụng 1 engine, nhưng hiển thị cho user là engine khác cũng có 1 ít tác dụng (ví dụ yahoo nói sử dụng Norton, nhưng sao biết chắc là nó sử dụng Norton?)

regex viết nhanh (chưa đầy đủ) của url /^https?:\/\/[a-zA-Z0-9_\.-]+\/[a-zA-Z0-9_\.-\/~]+/
biểu thức chính quy vẫn có rủi ro đối với bản thân parser & execution engine của regex (lỗi BO?) . Còn một vấn đề nữa là hình như url giờ có utf8 (non-English) nên regex sẽ khá phức tạp nếu muốn user có thể sử dụng được dịch vụ ở mọi nơi.

tui có 1 ý nghĩ là sao ko dùng các technique của AI: machine learning, pattern recognition (neuron network, empirical analysis, ....) để cho điểm và đánh giá nội dung attachment. Ví dụ sau khi phân tích, ta có điểm 4/10 -> hiện ra visual notification cho user là attachment này likely - unlikely harmful để tự bản thân user chọn -> adjust điểm (giống crowd sourcing)

b3. cái vụ bo này thì tui chỉ tạm biết là nếu giờ cho load file đủ lớn chứa toàn là AAAA hay gì đó, nếu gmail temporarily out of service sau khi attach -> crash service -> có khả năng stack/mem bị overwrite ở đâu đó -> rồi ROP hay gì đó nữa.

chi tiết hơn tui phải nghiên cứu thêm về RoP và đọc thêm về BO mới rõ được, còn trên chỉ là nguyên lý tui nhớ mang máng

@gamma95: ý 2&3 rất hay -> sẽ phải sanitize user input. Mà thường nguyên lý là không bao giờ tin user input nên việc kiểm tra bad url sẽ được thực hiện đầu tiên -> việc malicious server host valid url sẽ có hiệu quả hơn.

nhân tiện đặt thêm câu hỏi: url valid trong trường hợp này sẽ là gì? nếu kiểm tra valid url (http/https only, no port, no user@pass) thì có thể fix được một số vấn đề đang thảo luận hay không?

@ikut3

Bạn không cần đến puppet-enterprise để làm đâu. Puppet open source là đủ xài rồi.

b3. Scan & pattern matching có thể bị buf overflow hoặc dùng escape string để by pass nên chỉ có tác dụng một phần, không phải là giải pháp chắc chắn 100%

b4. Như jinx9 có nói, nếu yêu cầu gmail down về 1 file mà trúng server config tarpit rule thì sẽ tốn network resource để maintain connection. Hoặc là netcat /dev/random thì biết chừng nào mới down xong -> nếu để time limit thì sẽ hạn chế được long download. Trường hợp target server cố ý chỉ support http 1.0 nên gmail serrver không biết được lúc nào mới hết file.

Trường hợp target server support range (http 1.1) thì hạn chế size down để hạn chế disk usage cho server gmail.

Ý của mrro trong trường hợp 1 là để gmail scan port của chính gmail? hoặc các internal server của google?

+1 cho puppet. Không tốn $ như bạn nghĩ đâu. Bạn chỉ tốn công lúc đầu định ra các loại client, và mỗi loại client sẽ cần những package và file config gì. Sau đó là puppet-master sẽ tự động deploy ra hàng loạt các máy có puppetd mà bạn đã list sẵn.