Đóng thủ công một cổng từ dòng lệnh

Tôi muốn đóng một cổng mở ở chế độ nghe giữa ứng dụng khách và máy chủ của tôi.

Có tùy chọn dòng lệnh thủ công nào trong Linux để đóng cổng không?

LƯU Ý: Tôi đã biết rằng "chỉ ứng dụng sở hữu ổ cắm được kết nối mới đóng nó, điều này sẽ xảy ra khi ứng dụng chấm dứt."

Tôi không hiểu tại sao ứng dụng chỉ mở được ... Nhưng tôi vẫn háo hức muốn biết liệu có cách nào khác để làm điều đó không.

Tôi đã có một vấn đề tương tự, quá trình phải tiếp tục sống nhưng ổ cắm phải đóng lại. Đóng một ổ cắm trong một quy trình đang chạy không phải là không thể nhưng khó khăn:

1. xác định vị trí quá trình:

   netstat -np
   

   Bạn có một source/destination ip:port portstate pid/processnamebản đồ

2. xác định vị trí mô tả tệp của ổ cắm trong quá trình

   lsof -np $pid
   

   Bạn nhận được một danh sách: tên tiến trình, pid, người dùng, fileDescriptor, ... một chuỗi kết nối.

   Xác định vị trí số fileDescriptor phù hợp cho kết nối. Nó sẽ là một cái gì đó như "97u" có nghĩa là "97".

3. Bây giờ kết nối quá trình:

   gdb -p $pid
   

4. Bây giờ hãy đóng ổ cắm:

   call close($fileDescriptor) //does not need ; at end.
   

   thí dụ:

   call close(97)
   

   Sau đó tách gdb:

   quit
   

   Và ổ cắm được đóng lại.

Bạn đang hỏi sai câu hỏi ở đây. Thật sự không thể chỉ đơn giản là "đóng một cổng" từ bên ngoài ứng dụng đã mở ổ cắm nghe trên nó. Cách duy nhất để làm điều này là tiêu diệt hoàn toàn quy trình sở hữu cổng. Sau đó, trong khoảng một hoặc hai phút, cổng sẽ có sẵn để sử dụng lại. Đây là những gì đang diễn ra (nếu bạn không quan tâm, bỏ qua đến cuối nơi tôi chỉ cho bạn cách giết quá trình sở hữu một cổng cụ thể):

Các cổng là tài nguyên được HĐH phân bổ cho các quy trình khác nhau. Điều này tương tự với việc yêu cầu HĐH cho một con trỏ tệp. Tuy nhiên, không giống như con trỏ tệp, chỉ MỘT quá trình tại một thời điểm có thể sở hữu một cổng. Thông qua giao diện ổ cắm BSD, các quy trình có thể đưa ra yêu cầu lắng nghe trên một cổng, sau đó HĐH sẽ cấp. HĐH cũng sẽ đảm bảo không có quá trình nào khác có cùng cổng. Tại bất kỳ thời điểm nào, quá trình có thể giải phóng cổng bằng cách đóng ổ cắm. Hệ điều hành sau đó sẽ lấy lại cổng. Ngoài ra, nếu quá trình kết thúc mà không giải phóng cổng, HĐH cuối cùng sẽ lấy lại cổng (mặc dù điều đó sẽ không xảy ra ngay lập tức: sẽ mất vài phút).

Bây giờ, những gì bạn muốn làm (chỉ cần đóng cổng từ dòng lệnh), không thể vì hai lý do. Đầu tiên, nếu có thể, điều đó có nghĩa là một quy trình đơn giản có thể lấy cắp tài nguyên của quy trình khác (cổng). Đây sẽ là chính sách tồi, trừ khi bị hạn chế trong các quy trình đặc quyền. Lý do thứ hai là không rõ điều gì sẽ xảy ra với quy trình sở hữu cổng nếu chúng ta để nó tiếp tục chạy. Mã của quy trình được viết giả định rằng nó sở hữu tài nguyên này. Nếu chúng ta chỉ đơn giản là lấy nó đi, nó sẽ tự sụp đổ, vì vậy OS sẽ không cho phép bạn làm điều này, ngay cả khi bạn là một quy trình đặc quyền. Thay vào đó, bạn chỉ cần giết chúng.

Dù sao, đây là cách để giết một quá trình sở hữu một cổng cụ thể:

sudo netstat -ap | grep :<port_number>

Điều đó sẽ xuất ra dòng tương ứng với cổng giữ quá trình, ví dụ:

tcp  0  0 *:8000   *:* LISTEN  4683/procHoldingPort

Trong trường hợp này, ProcHoldingPort là tên của quá trình mở cổng, 4683 là pid của nó và 8000 (lưu ý rằng đó là TCP) là số cổng mà nó giữ.

Sau đó, nhìn vào cột cuối cùng, bạn sẽ thấy /. Sau đó thực hiện điều này:

kill  <pid>

Nếu điều đó không hoạt động (bạn có thể kiểm tra bằng cách chạy lại lệnh netstat). Làm cái này:

kill -9 <pid>

Nói chung, tốt hơn hết là tránh gửi SIGKILL nếu bạn có thể. Đây là lý do tại sao tôi nói với bạn để thử killtrước kill -9. Chỉ cần sử dụng killsẽ gửi SIGTERM nhẹ nhàng hơn.

Như tôi đã nói, sẽ vẫn mất vài phút để cổng mở lại nếu bạn làm điều này. Tôi không biết một cách để tăng tốc độ này. Nếu ai đó làm như vậy, tôi rất thích nghe nó.

Fuser cũng có thể được sử dụng

fuser -k -n *protocol portno*

Ở đây giao thức là tcp / udp và portno là số bạn muốn đóng. Ví dụ

fuser -k -n tcp 37

Thêm thông tin tại trang fuser man

Bạn cũng có thể sử dụng iptables:

iptables -I INPUT -p tcp --dport 80 -j DROP

Về cơ bản nó hoàn thành những gì bạn muốn. Điều này sẽ giảm tất cả lưu lượng TCP xuống cổng 80.

netstat -anp | grep 80

Nó sẽ cho bạn biết, nếu bạn đang chạy apache, "httpd" (đây chỉ là một ví dụ, hãy sử dụng cổng mà ứng dụng của bạn đang sử dụng thay vì 80)

pkill -9 httpd 

hoặc là

killall -9 httpd

Bạn có thể chỉ cần tìm ra quá trình mở ổ cắm mà cổng được liên kết và giết quá trình đó.

Nhưng, bạn sẽ phải nhận ra rằng trừ khi quá trình đó có trình xử lý khởi tạo lại tất cả những thứ mà nó đang sử dụng (mở tệp, ổ cắm, dĩa, thứ có thể tồn tại trừ khi nó đóng đúng khi chấm dứt) thì bạn sẽ tạo ra kéo theo hiệu suất hệ thống. Thêm vào đó, ổ cắm sẽ vẫn mở cho đến khi kernel nhận ra rằng quy trình đã bị giết. Điều đó thường chỉ mất khoảng một phút.

Tôi cho rằng câu hỏi tốt hơn sẽ là: Cổng nào (thuộc quy trình nào) mà bạn muốn dừng lại?

Nếu bạn đang cố gắng chấm dứt một cửa hậu hoặc virus mà bạn đã tìm thấy, thì ít nhất bạn nên tìm hiểu dữ liệu nào sẽ qua lại trước khi bạn chấm dứt nó. . quá trình tự.

Thông thường nó sẽ có một chương trình điều khiển (dừng HTTPD | bắt đầu hoặc một cái gì đó). Hoặc, nếu đó là một thứ hệ thống, có lẽ bạn không nên lộn xộn với nó. Dù sao, tôi nghĩ rằng vì mọi người khác đang cho bạn góc "làm thế nào", tôi sẽ cho bạn sự cẩn thận.

Trước tiên tôi tìm các quá trình mongo và nút, sau đó thực hiện như sau:

ps -A | grep node

10418 pts/23   00:00:05 node

10551 pts/23   00:00:00 node

ps -A | grep mongo

10490 pts/23   00:00:00 mongod

Sau khi xác định, chỉ cần giết các quá trình với lệnh kill.

kill -9 10418
kill -9 10490

Cuối cùng, gõ meteorvà nó sẽ hoạt động trở lại.

Bạn có thể viết một tập lệnh sửa đổi iptables và khởi động lại chúng. Một tập lệnh để thêm quy tắc thả tất cả các gói trên cổng, một tập lệnh khác để xóa quy tắc đã nói.

Các câu trả lời khác đã chỉ cho bạn cách tiêu diệt quá trình bị ràng buộc với cổng - đây có thể không phải là điều bạn muốn. Nếu bạn muốn máy chủ tiếp tục chạy, nhưng để ngăn kết nối từ máy khách thì bạn muốn chặn cổng, không dừng quá trình.

Một vấn đề nữa: đôi khi kernel sở hữu các cổng. Tôi biết định tuyến NAT giữ một số cổng mở để sử dụng NAT. Bạn không thể giết quá trình cho việc này, đây là kernel và cấu hình lại và khởi động lại là bắt buộc.

Nếu bạn muốn cổng của mình được phát hành sớm hơn, bạn phải đặt giá trị sau:

echo 1 > /proc/sys/net/ipv4/tcp_fin_timeout

để đặt nó từ 60 giây (mặc định) thành 1 giây

Bạn có thể sử dụng lệnh có tên killcx, đóng kết nối mà không có bất kỳ quá trình nào bị giết.

• cú pháp:

killcx [dest_ip:dest_port] {interface}

  dest_ip              : remote IP
  dest_port            : remote port
  interface (optional) : network interface (eth0, lo etc).

• thí dụ:

killcx 120.121.122.123:1234
killcx 120.121.122.123:1234 eth0

Tôi biết rằng câu trả lời này không tự trả lời câu hỏi, nhưng nói đúng ra, nhưng đọc nó có thể là thông tin liên quan:

Hành vi mặc định của việc gắn một ổ cắm vào một cổng (và địa chỉ) là khi ổ cắm bị đóng do quá trình chấm dứt đột ngột, ổ cắm sẽ ở trong TIME_WAIT trong một thời gian. Điều này có nghĩa là bạn không thể liên kết lại ngay lập tức với địa chỉ / cổng này. Nếu bạn đang tự phát triển hệ thống thông qua giao diện ổ cắm BSD tiêu chuẩn, bạn có thể (ít nhất là ở một mức độ nào đó) kiểm soát hành vi này với tùy chọn ổ cắm SO_REUSEADDR. Điều này về cơ bản sẽ cho phép bạn liên kết vào cùng một địa chỉ / cổng nếu ổ cắm ở trạng thái TIME_WAIT. Vẫn còn một ổ cắm trên mỗi cổng!

Tuy nhiên, thông tin này chỉ nên được sử dụng làm hỗ trợ phát triển, vì có lý do để TIME_WAIT tồn tại ở nơi đầu tiên, đã được giải thích trong các câu trả lời khác.

Nếu bạn muốn không có lưu lượng truy cập qua ổ cắm nhưng muốn tiếp tục quá trình: tcpkill .

tcpkill -i eth0 host xxx.xxx.xxx.xxx and port yyyy

Sẽ bắt đầu một trình nền đánh hơi chặn và chặn tất cả lưu lượng truy cập trên cổng đó. Rất thuận tiện để kiểm tra các ứng dụng của bạn để phân chia mạng.

Bạn có thể đóng ổ cắm nghe bằng ss :

sudo ss --kill state listening src :1234

Trong đó 1234 là số cổng của bạn.

ss là một phần của gói iproute2, vì vậy có một sự thay đổi mạnh mẽ mà nó đã được cài đặt trên một Linux hiện đại.

Tôi đã học được điều này từ một câu trả lời cho một câu hỏi liên quan .