<![CDATA[Latest posts for the topic "tìm process id đang mở udp port "]]> /hvaonline/posts/list/24.html JForum - http://www.jforum.net tìm process id đang mở udp port - Code:
#  netstat -np --protocol=inet | grep 101.99.6.87
udp        0      0 10.0.0.xxx:44431            101.99.6.87:53              ESTABLISHED -
mình sử dụng lsof, nhưng không ra kết quả gì Code:
#port=`netstat -np --protocol=inet | grep 101.99.6.87 |awk '{print $4}' | cut -d: -f2` && lsof -i :$port
(hơi ngoài lề với câu hỏi nhưng cho mình tiện hỏi luôn) Sở dĩ mình cần tìm process và file đang sử dụng để xác định nguyên nhân của việc mạng bị bottle neck. Sơ đồ mạng đơn giản như sau: Wan<---> eth0-LVS(nat)-eth1 <---> Webserver, cổng eth0 100Mb, eth1 1000Mb Tại LVS, mình chạy # iftop -i eth0 Kết quả show ra top là ip 101.99.6.87 <-> 123.162.233.1 (ip wan lvs) với TX > 90Mb, RX: < 1Mb # iftop -i eth1 Kết quả show ra top là ip 101.99.6.87 <-> 10.0.0.xxx (ip webserver) với TX > 900Mb, RX: < 1Mb Mình sử dụng tcpdump tại LVS : #tcpdump -n -vv host 101.99.6.87 -i eth1 -w 101.99.6.87.pcap Dùng wireshark xem gói tin thấy có 2 dạng gói tin, trong đó có 1 gói là malform packet dns(mình ko rõ cái dạng gói tin này là gì, tra google 1 tí thì mình đoán có lẽ server mình bị dính con bot gì rồi, DNS malformed packet flood, http://www.iss.net/security_center/reference/vuln/DNS_Malformed_Flood.htm :( ) file chứa gói tin mình export 2 gói ra file txt: https://www.mediafire.com/?le1d0m6w2zj3h2a Mình đã dùng iptables Drop ip này: #iptables -t filter -I FORWARD 1 -d 101.99.6.87 -j DROP Lúc này traffic out từ ip 123.162.233.1 -> 101.99.6.87 ở eth0 ko còn nữa, nhưng traffic out ở eth1 vẫn còn, nhưng RX = 0, TX > 900Mb À còn ip 101.99.6.87 ko phải lúc nào cũng là ip đó, có lúc nó lại ra ip khác với trường hợp tương tự Rất mong mọi người có thể xem qua và giúp mình, chân thành cảm ơn :)]]> /hvaonline/posts/list/45380.html#279363 /hvaonline/posts/list/45380.html#279363 GMT tìm process id đang mở udp port /hvaonline/posts/list/45380.html#279376 /hvaonline/posts/list/45380.html#279376 GMT tìm process id đang mở udp port /hvaonline/posts/list/45380.html#279382 /hvaonline/posts/list/45380.html#279382 GMT tìm process id đang mở udp port Code:
auditctl -a exit,always -F arch=b64 -S socket -k SOCKET
Trong khi chờ đợi, có thể chạy `tcpdump` để chắc chắn rằng đã có một ít UDP đã đi ra ngoài đến port 53. Sau đó, dùng `ausearch` để kiểm tra log. Một ví dụ khi mình dùng `nslookup`:
type=SYSCALL msg=audit(01/02/2014 11:21:27.679:24) : arch=x86_64 syscall=socket success=yes exit=7 a0=2 a1=2 a2=11 a3=0 items=0 ppid=2180 pid=2182 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=4294967295 comm=nslookup exe=/usr/bin/nslookup key=SOCKET  
Good luck.]]> /hvaonline/posts/list/45380.html#279383 /hvaonline/posts/list/45380.html#279383 GMT tìm process id đang mở udp port Code:
# ausearch -sc socket | wc -l
63468
Code:
#ausearch -sc socket
time->Thu Jan  2 20:47:33 2014
type=SYSCALL msg=audit(1388670453.581:284435): arch=c000003e syscall=41 success=yes exit=3 a0=1 a1=80801 a2=0 a3=ffffffffff
ffffff items=0 ppid=30299 pid=3651 auid=520 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 tty=(none) ses=388
55 comm="suexec" exe="/usr/sbin/suexec" key="SOCKET"

time->Thu Jan  2 20:47:33 2014
type=SYSCALL msg=audit(1388670453.584:284436): arch=c000003e syscall=41 success=yes exit=4 a0=2 a1=2 a2=0 a3=7fff17818960 i
tems=0 ppid=3305 pid=3649 auid=520 uid=15382 gid=200000 euid=15382 suid=15382 fsuid=15382 egid=200000 sgid=200000 fsgid=200
000 tty=(none) ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi" key="SOCKET"
Nếu xảy ra hiện tượng như ở câu hỏi, khi mình track được dữ liệu với số lượng như trên, không biết phải soi thế nào mới ra đúng cái process hay uid,pid,... mình cần tìm không :(]]> /hvaonline/posts/list/45380.html#279415 /hvaonline/posts/list/45380.html#279415 GMT tìm process id đang mở udp port

tuanksor wrote:
Nếu xảy ra hiện tượng như ở câu hỏi, khi mình track được dữ liệu với số lượng như trên, không biết phải soi thế nào mới ra đúng cái process hay uid,pid,... mình cần tìm không :( 
Bạn có thể dùng thêm `-F a0=2 -F a1=2` nữa để chỉ audit UDP thôi. Tham khảo: http://serverfault.com/questions/192893/how-i-can-identify-which-process-is-making-udp-traffic-on-linux Ở đây, a0 tương ứng với PF_INET còn a1 là SOCK_DGRAM: Code:
# grep _INET /usr/src/linux-headers-3.2.0-30/include/linux/socket.h
#define AF_INET         2       /* Internet IP Protocol         */
#define AF_INET6        10      /* IP version 6                 */
#define PF_INET         AF_INET
#define PF_INET6        AF_INET6
Code:
# grep _DGRAM /usr/src/linux-headers-3.2.0-30/include/linux/net.h 
 * @SOCK_DGRAM: datagram (conn.less) socket
        SOCK_DGRAM      = 2,
]]> /hvaonline/posts/list/45380.html#279435 /hvaonline/posts/list/45380.html#279435 GMT tìm process id đang mở udp port Code:
# iptables -t filter -I OUTPUT -d 112.78.1.194 -j LOG --log-prefix="tracking: "
nhằm để xác định thời gian tiếp tục tạo rule audit: Code:
#auditctl -d exit,always -F arch=b64 -S socket -k SOCKET -F a0=2 -F a1=2
để im trong ~1 phút sau đó bỏ 2 rule trên, đổ log audit vào 1 file mới Code:
#ausearch -sc socket | grep 'a0=2' | grep 'a1=2' > audit.track.log
hiện tượng xảy ra lúc ~10:54 (theo log kernel), mình lọc khoảng thời gian này Code:
#grep "^10:5[4-6]" audit.track.log > audit.track1.log
nhưng lượng log vẫn còn quá lớn Code:
# grep "^10:5[4-6]" audit.track1.log | wc -l
55921
nên mình lọc ra xem uid nào mở socket nhiều nhất trong khoảng thời gian 10:54 -10:56 Code:
#grep "^10:5[4-6]" audit.track1.log | awk '{print $15,$16,$24,$25,$26}' | sort -k1 | uniq -c | sort -rn | head
55084 uid=1xxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
     85 uid=xxxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
     34 uid=xxxxx gid=x00000 ses=38855 comm="php-cgi" exe="/usr/bin/php-cgi"
.....
lúc này coi như khoanh vùng được là do tên nào cd đến homedir của uid này: có source web chạy joomla vẫn chưa thể xác định được file nào mình thử xem log của những web này, thấy có nhiều request lạ như thế này 80.242.139.195 - - [10/Jan/2014:10:53:53 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:55:15 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:56:36 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:57:58 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:10:59:19 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:00:41 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:02:02 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xx 80.242.139.195 - - [10/Jan/2014:11:03:23 +0700] "POST /tmp/b.php HTTP/1.1" 200 0 "-" "-" 10.0.0.1xxx trong homedir/tmp, mình tìm ra đc 2 file (file đính kém) trong đó có 1 con webshell :( nhưng không biết có phải file b.php gây ra hiện tượng bottle neck hay ko (còn chính xác file nằm trong homedir của uid trên, vì trong lúc xảy ra hiện tượng, mình đổi tên cái homedir đi thì ngắt ngay hiện tượng bottle neck ) hiện mình định dùng audit track (chờ xảy ra hiện tượng ở lần tiếp theo) toàn bộ file trong homdir của user này, auditctl -w /homedir-uid/ -p rx mong sẽ xảy ra hiện tượng trên sớm. (cho mình hỏi có cách nào tối ưu hơn không :) ) http://www.mediafire.com/download/dls41n3bdk7uh76/file.zip]]> /hvaonline/posts/list/45380.html#279444 /hvaonline/posts/list/45380.html#279444 GMT tìm process id đang mở udp port /hvaonline/posts/list/45380.html#279458 /hvaonline/posts/list/45380.html#279458 GMT