Messages posted by: lQ

ưu tiên tìm hiểu client & server's log + debug info nếu có smilie

.

Tui thì ko thể thiếu:

Add N Edit Cookies
Fission: giao diện đỡ đơn điệu
Flashblock: cấm flash
Google Toolbar for Firefox: quản lý bookmark
Live HTTP headers
NoScript

hi vikjava,
ý em là dùng ADSL làm dự phòng cho 02 đường chính. Vậy thì sao em ko tìm hiểu cách dùng đường ADSL để kết nối VPN từ Chi nhánh về Trung tâm, để địa chỉ của ứng dụng ko cần thay đổi.

02 MAC nhưng có 02 ip hay 01? Nếu là 02 ip thì cùng hay khác subnet? Nếu là khác, thì chắc là máy của bạn có lúc dùng wired, có lúc dùng wireless.

chủ đề đã được giải quyết. Closed.

riêng codonmaiminhem cho nghỉ 03 tuần để đọc nội quy.

mua đĩa đi, nó bán có 70k àh. Gọi là ủng hộ nền CNTT VN.

trang www.hxhack.com hình như toàn tiếng ba tàu. Tui thì ko rành mấy tiếng đó. Vậy nhờ diepbang dịch giùm vài bài chất lượng đọc chơi smilie

.

/book/

Cho tui bổ sung vài ý:

5. Biết cách thức kiểm soát toàn bộ hoạt động của các account truy cập DB.
6. Biết về performance tuning, biết cách chuẩn hoá DB, biết cách tối ưu câu lệnh SQL
7. Biết về sao lưu và phục hồi DB, đảm bảo hệ thống DB hoạt động liên tục.

khi nào nghĩ được thêm thì bổ sung tiếp smilie

.

choc_ wrote:

ơ nếu cho lựa chọn, mình vẫn lựa pubkey + passphrase, dẫu gì cũng là 2 yếu tố.

@IQ: mình nghĩ chỉ có cái ý vài anh chàng sysadmin generate key không có passphrase là make sense thôi. chứ còn ý còn lại, private key có thể bị copy, vì buộc phải lưu trên máy của user thì có copy cũng có làm được gì đâu, nếu có đặt passphrase.

vả lại ý 1 cũng tương đương như password thôi, phải bảo vệ cái key đó. nếu không áp được bằng kỹ thuật, thì áp bằng hành chính, cứ một đợt audit, phát hiện anh nào không đặt passphrase, hay share private key tùm lum thì kỷ luật, vậy thôi.

ờ hén. Có lấy được cái private key, thì cũng chưa chắc

việc kiểm tra share private key thì cũng khá dễ, nhưng để audit key giống trường hợp audit password thì tui chưa nghe bao giờ. Ko lẽ buộc mọi người đưa private key? Mà nếu đưa, mọi người đưa cho cái private key đã chỉnh passphrase đủ chuẩn thì làm sao audit? choc_ biết tool nào không, giới thiệu với?

Có một trường hợp tưởng là dùng password bất lợi hơn so với key. Nếu như có quá nhiều server, thì việc dùng password sẽ ko hiệu quả, vì khi đổi password là phải đổi hàng loạt. Tuy nhiên vẫn có thể loại bỏ hạn chế này bằng cách viết một đoạn script thực thi tự động việc này.

Vì vậy lQ vẫn nghiêng về việc dùng password.

topic hay đây.

Trước mắt tui thấy password lợi hơn ở 02 điểm:
- Có thể áp đặt password policy trên sshd. PKI thì ko, thậm chí tui biết có vài anh chàng sysadmin generate key không có passphrase.
- private key có thể bị copy, vì buộc phải lưu trên máy của user. Còn password thì thường ko được lưu.

Có một yếu điểm của password là dễ bị brute force hơn, vì thuật toán mã hóa password trên file shadow có độ dài giới hạn. Còn public key thì có tùy chọn độ dài mã hóa, nên sẽ khó brute force hơn.

gộp 03 thông tin này lại, tui đánh giá password cao hơn smilie

.

OSSEC - Agentless monitoring

http://www.ossec.net/dcid/?p=154

nguyenvanhack wrote:

...

Mô hình kết nối:

Internet <-> Firewall_1 <-> [ SMTP-Gateway, MS ISA 2006 ] <-> IPS <-> Firewall_2 <-> [ Mailbackend (Exchange 2003 SP2), Web App ]

<note>
1. MS ISA 2006 dùng để public OMA, OWA
2. Ngoài dịch vụ SMTP trên SMTP-Gateway và HTTPS trên ISA được public ra ngoài Internt thì không còn dịch vụ nào được public ra ngoài.
</note>

...

Câu hỏi:
1. Mô hình kết nối như trên theo các bác còn điểm nào chưa ổn không?
2. Có thể hay không việc: attacker truy cập thành công đến WebApp (ví dụ như thông qua bug của Exchange 2003. Giả như 1 ngày nào đó chú quản trị IPS phản chủ, disable mấy cái option đi - Hoặc giả IPS update không thành công)?. Nếu có thì các nhờ các bác chỉ giúp em nó là bug gì để nhà em biết cách fix.
3. Nếu bác nào ở đây khai thác được cái này rồi thì làm ơn liên hệ với em nhé.

Tui tạm gọi đám [SMTP-Gateway, MS ISA 2006] là DMZ servers, đám còn lại là backend servers.

1. Theo tui là không ổn.
- Nếu vì lý do gì đó mà IPS không hoạt động thì có nghĩa là nguyên cái mạng của bạn đi toi. IPS theo tui chỉ nên nằm ở nhánh, dạng span-port hoặc dùng chung với network tap.
- Server không nên có cùng subnet dùng chung của 02 firewall mà nên dùng một subnet nào đó của Firewall_1. Trường hợp của bạn là phải đặt 02 ACL chỉ cho đám server DMZ. Theo khuyến cáo của tui thì chỉ dùng 01.

Mô hình:
Internet <-> Firewall_1 <-> Firewall_2 <-> backend servers
________________ |
____________ DMZ servers

2. [Bổ sung] - Luôn có cách thức nào đó theo dõi hoạt động của IPS, giám sát trạng thái + giám sát thay đổi cấu hình thì đỡ phải lo chuyện phản chủ.

Ngoài ra, thiết kế mạng thì cũng luôn phải lưu ý đến ACL. Cái này tối quan trọng, giảm rủi ro nếu như attacker chiếm được quyền của DMZ servers. Sai lầm của một số người là thấy servers thì gán quyền nó truy cập mạng tự do. DMZ servers hạn chế tối đa truy cập backend servers.

LeVuHoang wrote:

Tui nói ngay từ đầu rồi mà giờ lão Thắng mới ngộ ra hả ). Gần như không truy ra được vết đâu.
Còn khía cạnh bảo vệ mail server, thì đúng là dựng 1 con mail gateway trước Exchange rồi sử dụng bộ lọc spam là tốt nhất. Nó cũng làm được nhiều thứ như scan virus... này nọ. Một công đôi chuyện.

Sao ko??? Lão ko nghe câu "lưới trời -lồng lộn-" hả smilie

Chỉ vì lão Thắng bố lười ko chịu sniff nên mới ko biết đó thôi.

Nói vậy chứ, nên nghe lời anh conmale. Có lẽ nên stop chuyện này. Vì cũng chưa có gì gọi là thiệt hại. Mấy dạng phá đám này tui hay gọi là "chó sủa" nhãi nhép, ko nên quan tâm. Khi nào nó 'nằm vùng' đã rồi 'bụp' nó cũng ko muộn.

Xin lỗi vì tính tui hơi thô lỗ. Mấy vụ này ở cơ quan nói sao thì trên đây nói vậy smilie

.

theo tui thì các ISP ko thể giúp gì đ/v trường hợp này đâu. Các ISP không thể phân biệt được ai đó truy cập web mail Google/Yahoo/MS để gửi mail về cho mình hay gửi cho người khác, hay làm một việc khác. Họ chắc chắn cũng ko có thông tin IP nào đã truy cập dịch vụ gì (smtp, pop, imap, telnet, ssh ...) theo thời điểm cụ thể. Họ chỉ có thể cung cấp thông tin IP nào tương ứng với người nào, tại thời điểm nào mà thôi. Và những thông tin này chỉ có khi chính quyền có trát yêu cầu.

Châm tiếp. Nếu người nước ngoài, ngồi tại các ISP nước ngoài, gửi mail, thì sao biết???

PXMMRF wrote:

...

3- Lão có thể reject các gói tin nguồn từ các IP (proxies) mà lão đã kê trên đây. Việc này có thể config. trên Advanced security router (nếu có) hoăc config. trên firewall, nếu cài Firewall "hiện đại" (đủ features) một chút.

...

Ko cấm được đâu anh. Mấy cái IP đó ko phải là proxies gì đó, mà chính là các mail servers. Cấm là khỏi nhận mail từ tụi nó luôn áh.

$ nslookup
> set type=MX
> gmail.com
Server: 192.168.2.2
Address: 192.168.2.2#53

Non-authoritative answer:
gmail.com mail exchanger = 50 gsmtp147.google.com.
gmail.com mail exchanger = 50 gsmtp183.google.com.
gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 10 alt2.gmail-smtp-in.l.google.com.

Authoritative answers can be found from:
gmail.com nameserver = ns2.google.com.
gmail.com nameserver = ns3.google.com.
gmail.com nameserver = ns4.google.com.
gmail.com nameserver = ns1.google.com.
gmail-smtp-in.l.google.com internet address = 209.85.143.27
alt1.gmail-smtp-in.l.google.com internet address = 72.14.205.27
alt1.gmail-smtp-in.l.google.com internet address = 72.14.205.114
alt2.gmail-smtp-in.l.google.com internet address = 209.85.129.27
alt2.gmail-smtp-in.l.google.com internet address = 209.85.129.114
gsmtp147.google.com internet address = 209.85.147.27
gsmtp183.google.com internet address = 64.233.183.27
ns1.google.com internet address = 216.239.32.10
ns2.google.com internet address = 216.239.34.10
ns3.google.com internet address = 216.239.36.10
ns4.google.com internet address = 216.239.38.10

moá ơi, cái lỗi cũ xì mà lại mới update. Bó tay lão thắng bố.

muốn truy cái này thì cũng ko khó. Chỉ cần biết nội dung của cái mail mà tụi này gửi là được. Tốt hơn hết là lấy tất cả nội dung mail headers. Có 02 cách:

- Một vài hệ thống có tuỳ chọn lưu tất cả các mail, kể cả mail tấn công vào 01 địa chỉ nào đó hoặc là forward đến 01 địa chỉ nào khác nữa.
- Sniff traffic từ các subnet của gmail, yahoo mail, ... đến dịch vụ smtp của local mail server.

tui đoán là attacker dùng các free email account của MS, Google và Yahoo để gửi các mail khai thác lỗi này.

đợi ai đó search lỗi này để biết cách khai thác và cách phòng chống.

LeVuHoang wrote:

vài giây crontab "tail -f" 1 lần rồi gởi log về server thì có vẻ hơi thủ công thì phải
Ngoài ra, yêu cầu 1 & 2 phải đi cùng với nhau, log ở chế độ realtime, chứ không có tách ra "monitor changes" không được quanta ah

Monitor hệ thống thì tui đang thử OSSEC nhưng vấn đề monitor và realtime này là cho log server.

thằng Datagram SyslogAgent có chức năng đẩy log Event Viewer và cả customize log files. Còn trên linux thì tìm log minion xài tạm smilie

.

Theo tui thì ko nên dùng cron / scheduled task để đẩy log. Nhiều công đoạn quá sẽ rất khó kiểm soát, nên viết / dùng chỉ một chương trình (tuỳ môi trường, đã nói ở trên) thì dễ hơn.

PS. Hmmmm. Có vẻ các anh em chưa đọc kỹ tài liệu /hvaonline/posts/list/20/24816.html#153376 của tui gửi rồi.