banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận hệ điều hành *nix tìm process id đang mở udp port  XML
  [Question]   tìm process id đang mở udp port 30/12/2013 22:40:51 (+0700) | #1 | 279363
tuanksor
Member

[Minus]    0    [Plus]
Joined: 01/11/2011 02:44:03
Messages: 50
Offline
[Profile] [PM]
Các bạn cho mình hỏi làm sao để tìm được 1 process id nào đang mở 1 udp port.
Mình sử dụng netstat nhưng tại column process_id/process_name hiển thị là -
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 smilie ) 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 smilie
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 01/01/2014 22:02:20 (+0700) | #2 | 279376
myquartz
Member

[Minus]    0    [Plus]
Joined: 04/01/2005 04:58:30
Messages: 563
Offline
[Profile] [PM]
Mình vẫn hay sử dụng lệnh netstat -nlup
trong đó:
l listen
p process
u: udp (nếu cần xem tcp thì thay bằng t)
n: hiện số cho nhanh.
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 02/01/2014 15:47:10 (+0700) | #3 | 279382
tuanksor
Member

[Minus]    0    [Plus]
Joined: 01/11/2011 02:44:03
Messages: 50
Offline
[Profile] [PM]
Cảm ơn myquartz, mà với lệnh netstat bạn đưa ra thì chỉ xem được process nào đang LISTEN thôi, mình cần tìm ra process đã thiết lập kết nối ra bên ngoài.
Thêm thông tin là tại webserver, net.ipv4.ip_forward = 0, nên mình chắc rằng không có kết nối nào đi qua nó được, chỉ có vào ra thôi
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 02/01/2014 18:47:15 (+0700) | #4 | 279383
[Avatar]
quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
[Profile] [PM]
Bạn thử ngâm cứu `auditd` xem.

Đầu tiên, tạo một rule thế này:
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.
Let's build on a great foundation!
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 06/01/2014 16:42:17 (+0700) | #5 | 279415
tuanksor
Member

[Minus]    0    [Plus]
Joined: 01/11/2011 02:44:03
Messages: 50
Offline
[Profile] [PM]
mình cảm ơn quanta, mặc dù chưa gặp lại cái hiện tượng trên để mình thực hiện tracking bằng audit, mình có thử nghiệm với rule quanta hướng dẫn, sau khi add rule khoảng 15s, dùng ausearch: # ausearch -sc socket
kết quả quá lớn, và toàn bộ các process hầu như là suexec và php-cgi (vì webserver chạy rất nhiều website)
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 smilie
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 08/01/2014 23:03:09 (+0700) | #6 | 279435
[Avatar]
quanta
Moderator

Joined: 28/07/2006 14:44:21
Messages: 7265
Location: $ locate `whoami`
Offline
[Profile] [PM]

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 smilie 

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,
Let's build on a great foundation!
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 10/01/2014 17:32:52 (+0700) | #7 | 279444
tuanksor
Member

[Minus]    0    [Plus]
Joined: 01/11/2011 02:44:03
Messages: 50
Offline
[Profile] [PM]
mình cảm ơn quanta rất nhiều
Sau một buổi nín thở nằm chờ, đã xác định được uid gây ra hiện tượng trên
Khi xảy ra hiện tượng bottle neck tại firewall, xác định được des ip, mình vào webserver bật iptables lên
tạo 1 rule mới:
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 smilie
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 smilie )

http://www.mediafire.com/download/dls41n3bdk7uh76/file.zip
[Up] [Print Copy]
  [Question]   tìm process id đang mở udp port 14/01/2014 09:47:28 (+0700) | #8 | 279458
tuanksor
Member

[Minus]    0    [Plus]
Joined: 01/11/2011 02:44:03
Messages: 50
Offline
[Profile] [PM]
Hiện tại mình đã tìm được file gây ra bottle neck.
Khi xảy ra sự cố, mình tail access log của uid này, và tìm ra được file bot php
Bên trong file đơn giản chỉ là 1 vòng lặp vô tận while(1)
nội dung bên trong while dùng các func fsockopen() , fwrite() và fclose() để mở socket gửi data ra ngoài
data là chuỗi ký tự XXXXX (khớp với payload khi mình capture đc bằng tcpdump)

Cảm ơn quanta rất nhiều
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|