Messages posted by: jerrykun

Vô HVA bằng link bên dưới thông qua google và không bị ảnh hưởng bởi tình trạng trên.

http://www.google.com.vn/url?sa=t&rct=j&q=%20site%3Ahvaonline.net%20hva%20online&source=web&cd=3&ved=0CC4QFjAC&url=http%3A%2F%2Fwww.hvaonline.net%2Fhvaonline%2Fportal%2Flist.html&ei=z4tAT4KoHqr4mAXUysnMBw&usg=AFQjCNGWsu5u26qNG-VfwrjwaLXQBy_wDw

Add vô bookmark là HVA và edit bằng đường link trên.

Mình xài mạng Internet của VNPT (Gói MegaEasy), hôm nay mình truy cập web thường hay bị đứt quãng, mình khảo sát lại đường mạng thì thấy thông tin sau:

modem/LAN ip trong trang hiển thị : 123.22.96.1 (A), sau đó mình vô các trang kiểm tra ip thì thấy ip là : 123.22.107.213 (B). Cả hai đều là WAN IP, lạ một chổ là mỗi lần mình reset modem thì cái ip trên modem (A) vẫn giữ nguyên còn cái WAN ip kia (B) thì thay đổi sau khi mình vô website check ip lại.

Mọi người có thể giải thích giúp mình tại sao và mục đích cái ip (B) kia lại thay đổi ko ? thông thường thì nó hay đổi ip của modem/LAN.

Thông tin tracert:

Tracing route to google.com.au [74.125.31.94]
over a maximum of 30 hops:

1 2 ms 2 ms 2 ms 192.168.1.1
2 12 ms 16 ms 12 ms 123.22.96.1
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 123 ms 121 ms 121 ms 72.14.196.21
7 121 ms 122 ms 121 ms 64.233.175.207
8 121 ms 122 ms 121 ms 209.85.241.58
9 144 ms 141 ms 142 ms 209.85.250.122
10 146 ms 140 ms 142 ms 209.85.243.21
11 * * * Request timed out.
12 143 ms 142 ms 143 ms tb-in-f94.1e100.net [74.125.31.94

Trace complete.

Cảm ơn nhiều.

chiro8x wrote:

Dùng iframe đôi khi sẽ bị trình duyệt chặn tiêu biểu ở đây là Google Chrome, Các web browser giờ rất nhạy cảm với mấy hidden element. Bác nào thử đoạn mã sau đây xem nhé.
Code:
style="background-image: url()"
Em không biết là giờ có được nữa không, trước đây dùng JS thay đổi thuộc tính style là đc. Mà sao em viết cả cái code vào là HVA nó lọc mất . Mình đưa cái url của mình log cookie vào trong cái dấu () và nhớ '' .

chắc code của bạn match với rules của mod_security nên bị chặn rồi.

Mình thử nghiệm trên máy của mình có cài mod_sec thì thấy, nếu nhét cái iframe chứa link độc hại vào JS thì bypass với trình duyệt như Chorme, Firefox chưa có thiết lập add-on hoặc plugin kiểm tra JS ( Đa phần người dùng ít quan tâm và cài các add-on hổ trợ này). Còn nhập các iframe hoặc đường link trộm cookie thì hầu hết đều bị chặn bởi mod_sec.

Mình xin phân tích và trình bày quan điểm như sau:
1. web của công ty vừa bị thâm nhập.
2. Để bảo đảm bảo mật và uy tín của công ty theo bạn, công ty ấy cần khai triển những gì và lý do tại sao?

1. web của công ty vừa bị thâm nhập là hệ quả của một số nguyên nhân tồn tại trước đó khách quan hoặc chủ quan. (VD: cá nhân nghịch phá , đối thủ cạnh tranh không lành mạnh, quan hệ khách hàng hoặc cộng đồng không tốt, nhân viên kỹ thuật trong công ty nghỉ việc, quản trị hệ thống thiếu quan tâm đến các dịch vụ trên máy chủ web,cập nhập,fix bugs ...vv.)

2. Bảo đảm bảo mật và uy tín của công ty là quá trình xây dựng lâu dài, từ lúc thành lập công ty và tiếp diễn. Bất kỳ công ty nào làm khi làm kinh doanh đều phải xây dựng cho mình kế hoạch phục hồi sau thảm họa (Disaster Recovery). Kế họach khôi phục sau thảm họa là quá trình chuẩn bị, là phản ứng từ trên xuống dưới, tất cả cá nhân liên quan. Việc chuẩn bị tốt chu đáo kế hoạch phản ứng với các danh sách thảm họa đã được phân loại sẽ giúp công ty giảm thiểu thiệt hại về vật chất lẫn uy tín của mình.

- Tùy theo quy mô lớn nhỏ của công ty cũng như dịch vụ mà mình cung cấp( VD: Website availability 24/7 ) mà xây dựng kế hoạch Disaster Recovery cho phù hợp. Như vậy, việc xây dựng kế hoạch khắc phục sau thảm họa là việc cần triển khai trước tiên song song với sự phát triển của công ty. Còn tình huống web bị thâm nhập là xãy ra sau, và cần chấp nhập sự thật khi public web ra internet bị tấn công là vấn đề không tránh khỏi. Ghi nhận trường hợp của bkav và các thông tin từ các tờ báo online được xem là có uy tín ở việt nam phản ảnh: Cho thấy sự thiếu chuẩn bị và cách đánh giá vấn đề dẫn đến các hành động, phản ứng của cá nhân đại diện bkav được cộng đồng mạng đánh giá là bất lợi cho doanh nghiệp khi kinh doanh sản phẩm và dịch vụ của mình sau này.

- Việc đánh giá mực độ hậu quả một cách nghiêm túc,cũng như công việc thu thập thông tin để tìm ra nguyên nhân cốt lõi của vấn đề là việc cần thiết nên làm. Có thể thấy vấn đề nghiêm trọng trong trường hợp của bkav xuất phát từ cách hành xử, phản ứng đã tồn tại từ rất lâu, chứ không phải vấn đề bị tấn công (defaced và mất DB) và bị cài file "hacked.html" trên máy chủ. bkav bị tấn công(defaced và mất DB) là hậu quả tất yếu
xuất phát từ nguyên nhân là cách hành xử, phản ứng từ vụ bị tấn công trước đó.

- Như đã đề cập ở trên, Bảo đảm bảo mật là quá trình làm việc lâu dài song song với sự phát triển của công nghệ, là sự hợp tác từ cá nhân liên quan từ cấp Lãnh đạo tới nhân viên. Ghi nhận ý kiến của anh Conmale về kiện toàn bảo mật "Bảo mật ở các tầng, các lớp không đơn thuần chỉ cấu hình ứng dụng trên máy chủ web.

Thanks for viewing

@mrcodon,

Ý của bạn kenshin19xx có thể hiểu là bạn dùng firewall trong hệ thống mạng nội bộ chặn kết nối tới port 1433 từ bên ngoài vào. Nói cách khác là các máy đằng sau firewall sẽ không bị ảnh hưởng khi truy cập tới MSSQL.

Cuốn sách gamma đề cập đây:

Google : XSS Attacks: Cross Site Scripting Exploits and Defense mediafire

modsec có nhiều kiểu báo lỗi , mình nghĩ nếu count được số lần bad url input cho mỗi ip với thời gian ấn định thì chắc sẽ hạn chế được những thằng bị block oan và loại bỏ được các cỗ máy auto vul scan.

@myquartz,

Hy vọng bác không sử dụng thông tin này thực hiện việc gì đó trái pháp luật smilie

Tuy trong hội trường đa số là là người am hiểu kỹ thuật nhưng cũng có thể bị dính như thường bởi sự quan tâm lớn nhất của họ là các chủ để trong buổi thuyết trình nên sự lơ đãng và bị sniff có thể dể hiểu.

ISP có thể khoanh vùng xác định được tại một thời điểm nào đó thông tin đầy đủ tên thuê bao đăng ký nhận public ip.
ISP có thể biết được những thông tin liên quan mà public ip đó đã truy cập trong một khoản thời gian xác định thông qua ISP proxy logs.

Còn việc xác định ai đằng sau cái public ip đó đã thực hiện cái gì đó gây hậu quả nghiêm trọng thì đó là cả 1 quá trình tổng hợp thông tin cần thiết và timestamp là điều kiện thiết yếu phục vụ cho công tác điều tra.

Hì Hì.. đọc kỹ nhận ra 1 điểm chung là cả hai phương thức là đều cố giữ connection và tăng cường tạo thêm connection mới và hệ quả out of resource tại máy chủ :=]]

Mình không dám khẳng định bạn là nạn nhân của Slowloris HTTP DoS hay không nhưng mình nhận thấy có 1 sự liên quan vấn đề của bạn với chủ đề đã thảo luận về Slowloris trên HVA

So Sánh [#2] /hvaonline/posts/list/29851.html

Và

[root@www2 ~]# netstat -nat |grep :80 |wc -l
1174
[root@www2 ~]# netstat -an | grep :80 | awk '{print $6}' | sort | uniq -c
224 ESTABLISHED
60 FIN_WAIT1
165 FIN_WAIT2
5 LAST_ACK
1 LISTEN
43 SYN_RECV
619 TIME_WAIT
[root@www2 ~]#

Lúc trước mình có tấn công vào máy chủ của mình với phương pháp trên, quả thật chỉ vài giây nó sụp luôn và không thể ssh vào server.

Cái này đã được thảo luận cách đây hơn 2 năm rồi. =]]. requests mà chạy thẳng vào apache là website đơ luôn.

/hvaonline/posts/list/29851.html

Với cấu hình phần cứng của bạn thì 200-300 connection tải bình thường nhưng load average: 6.92, 21.27, 20.04 là cao, bất thường. Bạn hãy tcpdump packets rồi gửi lên đây xem, chắc sẽ có cơ hội nhận được nhiều hồi âm của các chuyên gia phân tích. Mọi người cần nhiều thông tin hơn để phân tích và xác địch nguyên nhân từ bên ngoài hoặc bên trong hệ thống. Không thấy bạn đề cập đến iptables, vậy thử search một số bài về iptables trong hva và áp dụng thử xem.

CucKiHungHan wrote:

Mình có 1 sever Linux có cài Direct Admin. Mình có thuê bên thiết kế web làm web cho bên mình nên đã chuyển giao toàn bộ acc quản trị sever cho họ bao gồm acc root ssh + acc admin Direct Admin.
Cho mình hỏi sau khi mình đổi pass acc root ssh + pass acc admin Direct Admin thì họ có cách nào chiếm được sever không và cách phòng chống như thế nào? (mình nghe nói hình như có cách up shell gì đó để lấy thông tin rồi chuyển đến 1 địa chỉ email nào đó --> quét shell trên sever thế nào?)
Mình không có căn bản về Linux và không có nhiều thời gian để đọc nên mong các bạn giúp đỡ và đừng ném gạch. Cảm ơn nhiều !

Hãy thuê cty bảo mật kiểm tra toàn bộ giúp nếu như bạn không tin tưởng đội ngũ thiết kế web trên.

Em cám ơn anh Conmale đã chia sẽ kinh nghiệm quý báu.

Em thử với rule của anh viết thì nhận thấy với ấn định này thì chỉ làm giảm ảnh hưởng đến tất cả mọi người share chung 1 public ip, nói cách khác là tăng khả năng truy cập cho người dùng sử dụng các loại trình duyệt khác nhau thôi.

Hiện em đang hình giải pháp phòng chống (auto timing block/unblock ip vi phạm dựa trên các dấu hiệu nhận biết bởi mod_security) .Vô tình search lại thì thấy anh đã chia sẽ trong topic "Hỏi về cơ chế anti DDoS của HVA - #2, Line 2 "rồi ,thế mà em đọc không kĩ..hì hì.

Reference
/hvaonline/posts/list/40202.html

Chào mọi người,

mình có chút thắc mắc về việc ấn định số lượng http requests cho phép trong 1 khoảng thời gian xác định.
Ghi nhận theo mod_security rule của anh Conmale về giải pháp chống DDoS:

SecAction initcol:ip=%{REMOTE_ADDR},nolog
SecRule REQUEST_URI "^/$" "nolog,phase:1,setvar:ip.ddos=+1,deprecatevar:ip.ddos=5/60,expirevar:ip.ddos=600"
SecRule IP smilie

DOS "@gt 5" "phase:1,log,drop,msg:'DDoS'"

Với việc ấn định trên cho phép 5 http requests cho phép gửi trong thời gian 1 phút. Nhưng điều này lại ảnh hưởng nếu 1 tổ chức sử dụng địa chỉ IP Internet public shared, giả sử có 6 người trong 1 phút cùng truy cập đến website hoặc nhiều kết nối truy cập thông qua ip proxy của ISP đến website.

Cho mình hỏi cần ấn định cho phép gửi bao nhiêu requests là thích hợp ?

Cám ơn.

Reference
[1] #8 "hva /hvaonline/posts/list/36593.html"

@vina_man,

Trước khi request được chuyển đến (ví dụ mysqld) xử lý thì nó đã đi qua những quá trình xử lý nào? Nhận biết rõ được quá trình đi của request thì bạn mới đưa ra được giải pháp tốt nhất để ngăn chặn.

@TheShinichi,

nếu bạn không muốn thấy cái tab mới sinh ra thì thay gõ hvaonline.net trên thành trình duyệt thì gõ cái từ khoá này trên google search address "hva ky su" trên chrome hay firefox , sau đó click vô link có domain là hvaonline.net là sẽ chạy thẳng vào diễn đàn của hva. =]]

Mình viết ra 1 số vấn đề bạn kiểm chứng nhé :

1> Mã nguồn website bạn download từ nguồn có uy tín ?

2> Bạn có thói quen sử dụng tài khoản Quản trị đăng nhập ở wifi cafe, Internet công cộng hoặc trên máy tính của bạn bè không ?

3> Mật khẩu Tài khoản quản trị do hosting cấp và email chính đăng ký có thường được xuyên thay đổi không ?

4> Máy chủ hosting website của bạn bởi 1 doanh nghiêp có uy tín và đội ngũ hỗ trợ chuyên nghiệp?

Snort bạn nên cài trên máy có NIC thật mà test. Có lỗi debug cũng đỡ hơn.

Chắc bác ấy đã sắm 1 con Ipad và 1 sim 3G mobile internet. =]]

@Xnohat,

Cám ơn anh về bài viết, em mở mang thêm được chút kiến thức quý báu. Mong bài viết kế tiếp của anh.

Hi anh Conmale,

Em có thắc mắc như sau mong anh giải đáp giúp em.

Hiện công ty em có 1 website tin tức ( sử dụng HĐH CentOS,Apache,PHP,MySQL,Mod_security 2.x) hosting ở 1 datacenter. Mạng LAN trong công ty có khoảng 100 máy con, share chung 1 public IP để truy cập Internet. Gần đây, Em kiểm tra error_log thì thấy mod_security báo mã lỗi 403 Forbidden cho request có dạng http://mywebsite.com/index.php?../etc/paswd . Qua quá trình tìm hiểu, em thấy request trên gửi từ public IP share của công ty em.

Có cách nào mình tìm được IP của máy con đã gửi request trên không anh? Mong anh giải đáp giúp em.

À, em chỉ có quyền admin trên server web, không có quyền hạn của mạng LAN công ty.
Em cảm ơn.

oh, sorry...

Để mình kiếm con Core i3 khác test thử xem sao.

Mình nghĩ bạn nên tìm hiểu thêm về Linux command mình dùng cho chính xác.

ngthang91 wrote:

Cho mình hỏi, tại sao khi mình boot backtrack 3 từ USB lên thì nó không có nhận card mạng được, mình có nghe anh kia nói là hầu như các máy core i3 thì backtrack không nhận được card mạng của máy. Nghe nói là như vậy mà mình không biết có phải ko? Mình thử với backtrack 5 củng vậy, vậy cho mình hỏi nguyên nhân là do máy hay là do mình làm thao tác gì đó sai. Cảm ơn mọi người rất nhiều.

Mình không hiểu dòng màu đỏ của bạn viết. Riêng mình thì có 2 cái laptop 1 cái dell CPU Intel mua hồi 2007 và 1 cái HP CQ42 , AMD Tripple core (mua giữa 2010), mình thử với backtrack 5 thì đều kết nối được wifi và kết nối vào switch. Bạn không nói bạn xài card gì và thao tác của bạn ra sao nên mình cũng biết chính xác nữa.

Nếu kết nối card Ethernet vào switch thì bạn thử dùng command này thử xem:

ifconfig
ifconfig eth0 "Your IP" netmask "Your netmask"
route add default gw "Your IP gateway" eth0
echo nameserver "Your DNS" > /etc/resolv.conf
ifconfig eth0 up

Theo ý chủ quan của mình là sau khi thành công bước xâm nhập thì hacker đều theo hướng đi tìm cách exploit kernel hoặc các service vulnerability để get root hơn là quan tâm đến cái apache's config. Việc hạn chế load module không cần thiết đơn thuần làm giảm thiểu khả năng xâm nhập hơn.

@khang0001 : cho mình hỏi thêm là đã compile apache rồi mà sau cần thêm 1 vài mod nữa, vậy có cách nào để add thêm mod vào trong apache không cậu

Bạn đọc README của module cần load thì sẽ biết được cách sử dụng như thế nào.

satzoom wrote:

chiếm quyền đk thì tự viết ra con virus rồi dụ nó kích vô.

Lỡ máy nó có cài AVs thì sao ? smilie

chưa kịp click vô thì Virus bị băm rồi

Mình chưa cài CPANEL, DIRECT ADMIN, PLESK... lần nào, để mình tập cài và tìm hiểu thử.Thanks

conlocbayby wrote:

Hì cám ơn bạn, mình đã làm thành công rồi. Vấn đề ở đây là mình muốn chia sẽ kinh nghiệm của mình dành cho những bạn mắc phải trường hợp như mình như sau:

Khi các bạn không thể update được những compoment như PHP, SQL, APACHE... [color=brown]thì còn 1 cách nữa mà ít ai để ý đó là thêm trong phần quản lý server, vì ở đây của mình là PLESK[/color]

Mình rất cảm ơn các thành viên của HAV online đã giúp mình tận tình, đặc biệt là anh conmale và mv1098.

Hi, mình cũng đang tìm hiểu về Linux, bạn có thể giải thích rõ cho mình hiểu phần màu đỏ được không?

Thanks