Score:0

UFW บล็อกการเชื่อมต่อขาออกที่มีอยู่เมื่อเปิดใช้งาน

ธง in

ฉันมีปัญหาที่ดูเหมือนว่า ufw จะบล็อกการเชื่อมต่อขาออกที่มีอยู่ในพอร์ต 443 เมื่อเปิดใช้งาน ตัวอย่าง:

24 ก.พ. 17:53:00 เคอร์เนล server5: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 
24 ก.พ. 17:33:40 เคอร์เนล server5: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0
27 ก.พ. 00:47:07 เคอร์เนล server5: [18769144.299731] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=1460 TOS=0x00 PREC=0x60 TTL=51 ID=60877 DF PROTO=TCP SPT=443 DPT=42030 WINDOW=229 RES=0x00 ACK URGP=0

นอกจากนี้ การบล็อกแพ็กเก็ต UDP บางแพ็กเก็ต แม้ว่าฉันจะอนุญาต UDP โดยเฉพาะจาก 1025-65535:

24 ก.พ. 17:52:19 เคอร์เนล server5: [18571459.414576] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=5.6.7.8 DST=1.2.3.4 LEN=69 TOS=0x00 PREC=0x00 TTL=44 ID=59557 PROTO=UDP SPT=58678 DPT=49900 LEN=49 

(ฉันได้เปลี่ยน ip เซิร์ฟเวอร์ของเราเป็น 1.2.3.4) ทราฟฟิกที่ถูกบล็อกคือการเชื่อมต่อขดขาออกไปยัง Google ไดรฟ์และ Vimeo

นี่คือวิธีที่ฉันตั้งค่า:

ufw รีเซ็ต
ค่าเริ่มต้น ufw อนุญาตให้ส่งออก
ufw เริ่มต้นปฏิเสธการรับเข้า
ufw อนุญาตจาก 96.54.177.7 proto tcp ไปยังพอร์ตใดก็ได้ 22
ufw อนุญาตจาก 50.70.255.166 proto tcp ไปยังพอร์ตใดก็ได้ 22
ufw อนุญาต 443/tcp
ufw อนุญาต 80/tcp
ufw อนุญาต 25/tcp
ufw อนุญาต 587/tcp
ufw อนุญาต 1025:65535/udp

สถานะ ufw แสดง:

สถานะ: ใช้งานอยู่
การบันทึก: เปิด (ต่ำ)
ค่าเริ่มต้น: ปฏิเสธ (ขาเข้า), อนุญาต (ขาออก), ปิดใช้งาน (กำหนดเส้นทาง)
โปรไฟล์ใหม่: ข้าม

ถึงการดำเนินการจาก
-- ------ ----
22/tcp อนุญาตใน 99.99.99.99               
22/tcp อนุญาตใน 99.99.99.99             
443/tcp อนุญาตในทุกที่                  
80/tcp อนุญาตในทุกที่                  
25/tcp อนุญาตในทุกที่                  
587/tcp อนุญาตในทุกที่                  
  

ในการทดสอบ:

  • เริ่มการอัปโหลดใหม่ไปยัง Vimeo หลังจากเปิดใช้งาน ufw ทำงานได้ดีดูเหมือนจะไม่มีอะไรปิดกั้น
  • การเปิดใช้งาน ufw ระหว่างการอัปโหลด Vimeo ดูเหมือนจะทำให้เสีย
  • telnetting ไปยังพอร์ต 587 (เมล) จากเซิร์ฟเวอร์ไปยังที่อื่น และการเปิดใช้งาน ufw ดูเหมือนจะไม่ก่อให้เกิดปัญหาใดๆ การเชื่อมต่อยังคงเปิดอยู่ และฉันพิมพ์ help ฯลฯ ได้
  • conntrack ไม่เคยแสดงการเชื่อมต่อขาออก แต่แสดงการเชื่อมต่อขาเข้าได้
  • เมื่อฉันทดสอบบนอินสแตนซ์เซิร์ฟเวอร์คลาวด์ ubuntu 20.04 ใหม่ ไม่มีปัญหาใดๆ... ฉันไม่เห็นแพ็กเก็ตใดถูกบล็อกสำหรับพอร์ต 443 และการอัปโหลดทำงานได้ดี แต่ไม่ได้ติดตั้งบนเซิร์ฟเวอร์คลาวด์ทดสอบ conntrack และแม้หลังจากที่ฉันติดตั้ง conntrack และ conntrackd ฉันไม่เห็นการเชื่อมต่อใด ๆ ที่แสดงรายการใน "conntrack -L" เลย

ดังนั้นฉันจึงสับสนเล็กน้อยเกี่ยวกับสิ่งที่เกิดขึ้นที่นี่และควรกังวลเกี่ยวกับเรื่องนี้หรือไม่ ฉันไม่ต้องการเปิดใช้งาน ufw จนกว่าฉันจะเข้าใจอย่างถ่องแท้ว่ามันจะทำอะไรกับการรับส่งข้อมูลของฉัน จะติดตามการเชื่อมต่อขาออกได้อย่างไรหาก conntrack ไม่ติดตาม

ฉันคิดว่าอาจมีบางสิ่งเกิดขึ้นที่นี่ แต่ฉันต้องการที่จะเข้าใจว่าเหตุใดฉันจึงเห็นสิ่งเหล่านี้ บล็อก UDP และ ACK เป็นสิ่งที่น่ากังวลที่สุด แต่ดูเหมือนว่าจะเกิดขึ้นเพียงเสี้ยววินาทีหลังจากเปิดใช้งาน ufw ดังนั้นฉันจึงสงสัยว่าจะมีความล่าช้าเล็กน้อยหรือไม่ในขณะที่ ufw กำลังเปิดใช้งานกฎ ส่วนอื่น (RST) อาจเป็นเพราะการเชื่อมต่อถูกปิด บล็อก ACK ดูเหมือนจะทำให้เกิดปัญหากับการเชื่อมต่อขาออกที่เปิดอยู่ซึ่งกำลังส่งข้อมูลเมื่อเปิดใช้งานไฟร์วอลล์

Score:0
ธง cn

หากคุณดูอย่างใกล้ชิด คุณจะเห็นว่าทราฟฟิกที่ลดลงนั้นเป็นทราฟฟิกขาเข้า DST=1.2.3.4 DST หมายถึงปลายทาง และตามที่คุณระบุ 1.2.3.4 คือ IP ของคุณ

ตามผลผลิตของ สถานะ ufw การรับส่งข้อมูลมีพอร์ตต้นทาง 443 (SPT) ไม่ใช่ DPT (ซึ่งน่าจะได้รับอนุญาต) ดังนั้นจึงถูกทิ้งโดย ufw

ฉันเดาว่าคุณทำผิดพลาดที่ไหนสักแห่ง (อาจเกี่ยวข้องกับการแปลที่อยู่เครือข่าย) ซึ่งมีผลทำให้ไฟร์วอลล์ไม่มีสถานะ

in flag
นั่นคือการตอบสนองจากเซิร์ฟเวอร์ระยะไกล (ดังนั้น SRC จึงเป็นเซิร์ฟเวอร์ระยะไกล) แต่การเชื่อมต่อนั้นออกจากเซิร์ฟเวอร์ของเราอย่างแน่นอน และไม่ถูกติดตามโดย conntrack ฉันได้แก้ไขคำตอบเพื่อแสดงคำสั่งที่แน่นอนที่ฉันใช้ในการตั้งค่า ufw ไม่มีคำสั่งให้ระบุสถานะหรือไม่ ดังนั้นฉันจึงไม่เห็นว่าเป็นข้อผิดพลาดของฉันอย่างไร แต่โปรดแก้ไขฉันหากฉันผิด ปัญหาน่าจะเป็น conntrack ไม่ติดตามการเชื่อมต่อขาออก ทำไมถึงเป็นเช่นนั้น?
Score:0
ธง in

จากการตรวจสอบเพิ่มเติมพบว่าแพ็กเก็ตที่ถูกบล็อกเกิดขึ้นในช่วงเวลาน้อยกว่า 1 วินาทีในขณะที่เปิดใช้งาน ufw คำสั่ง "ufw enable" นั้นไม่มีที่ไหนเลยใกล้กับ atomic... มันเป็นสคริปต์หลามที่โต้ตอบกับ iptables คุณอาจคิดว่ามันทำเพียงหนึ่งหรือสองคำสั่ง iptables แต่นั่นไม่ถูกต้อง การรัน strace บน "ufw enable" แสดงว่าจริง ๆ แล้วรันคำสั่ง iptables หรือ ip6tables ทั้งหมด 358 ครั้งในกรณีของฉัน:

strace -f -tt ufw --force enable > /tmp/a 2>&1
root@testing:/home/ubuntu# grep exec /tmp/a|wc -l
358
root@testing:/home/ubuntu# grep exec /tmp/a|grep iptables|wc -l
135
root@testing:/home/ubuntu# grep exec /tmp/a|grep ip6tables|wc -l
134

ตัวอย่าง:

[pid 1959] 17:13:34.241806 execve("/usr/sbin/ip6tables", ["/usr/sbin/ip6tables", "-I", "ufw6-user-limit", "-m", "limit ", "--limit", "3/minute", "-j", "LOG", "--log-prefix", "[UFW LIMIT BLOCK] "], 0x7ffd5e6d3d10 /* 18 vars */ <ยังไม่เสร็จ ..>

ดังนั้น ผลที่สุดของสิ่งนี้คือการเปิดใช้งาน ufw อาจทำให้การเชื่อมต่อที่มีอยู่ซึ่งกำลังส่งหรือรับข้อมูลเสียหายชั่วคราวในระหว่างระยะเวลาที่ใช้ในการเปิดใช้งาน ufw ดังนั้นโปรดระมัดระวังในการเปิดใช้งาน ufw บนเซิร์ฟเวอร์จริง

Score:0
ธง gn

สำหรับสิ่งนี้:

24 ก.พ. 17:53:00 เคอร์เนล server5: [18571501.131985] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=35.196.37.91 DST=1.2.3.4 LEN=40 TOS=0x00 PREC=0x60 TTL=51 ID=24902 DF PROTO=TCP SPT=443 DPT=44496 WINDOW=0 RES=0x00 RST URGP=0 

นั่นไม่ใช่เรื่องผิดปกติ ดูรายละเอียดเพิ่มเติมในหนึ่งในคำตอบก่อนหน้าของฉัน ที่นี่.

อันถัดไป:

24 ก.พ. 17:33:40 เคอร์เนล server5: [18570340.976130] [UFW BLOCK] IN=eno1 OUT= MAC=d0:50:99:db:0a:be:00:6b:f1:17:4a:81:08: 00 SRC=52.10.136.43 DST=1.2.3.4 LEN=83 TOS=0x00 PREC=0x00 TTL=228 ID=23746 DF PROTO=TCP SPT=443 DPT=59404 WINDOW=118 RES=0x00 ACK PSH URGP=0

ยังไม่ชัดเจนนัก แต่ยังมีปัญหาการเชื่อมต่อหลุดเมื่อเปลี่ยนจาก UFW ปิดใช้งานเป็นเปิดใช้งานในอดีต วิธีการสืบสวนบางอย่างมีอยู่ในคำตอบก่อนหน้าของฉัน ที่นี่

สำหรับสิ่งนี้:

conntrack ไม่เคยแสดงการเชื่อมต่อขาออก แต่แสดงการเชื่อมต่อขาเข้าได้

นั่นไม่เป็นความจริง นี่คือตัวอย่าง:

doug@s15:~$ sudo conntrack -L | เกรป 192.168.111.134
tcp 6 35972 ก่อตั้งแล้ว src=192.168.111.1 dst=192.168.111.134 sport=36866 dport=22 src=192.168.111.134 dst=192.168.111.1 sport=22 dport=36866 [มั่นใจ] เครื่องหมาย=0 ใช้=1
conntrack v1.4.6 (conntrack-tools): มีการแสดงโฟลว์ 68 รายการ

นั่นคือการเชื่อมต่อขาออกจากเซิร์ฟเวอร์เกตเวย์หลักของฉันที่ 192.168.111.1 ไปยัง raspberry pi ที่ 192.168.111.134

in flag
สำหรับเซิร์ฟเวอร์ของฉัน ฉันดูเหมือนจะไม่เห็นการเชื่อมต่อขาออกโดยใช้ conntrack -L การเชื่อมต่อที่เกี่ยวข้องกับ 35.196.37.91 ในตัวอย่างด้านบนไม่เคยปรากฏใน conntrack (แต่แสดงใน netstat) เมื่อฉัน telnet ขาออกไปยังพอร์ต 587 ของโฮมเซิร์ฟเวอร์ของฉัน มันจะแสดงใน netstat แต่ไม่อยู่ใน conntrack -L นั่นอาจเป็นสาเหตุของปัญหาหรือไม่ เหตุใดเซิร์ฟเวอร์ของฉัน (สต็อก ubuntu 20.04 จาก OVH) จึงไม่แสดงการเชื่อมต่อขาออกใน conntrack
in flag
นอกจากนี้ เมื่อดูที่บันทึกอีกครั้ง แพ็กเก็ตที่ถูกบล็อกทั้งหมดดูเหมือนจะเป็น RST หรือ ACK ฉันเดาว่า RST ไม่ใช่ปัญหา แต่ ACKs อาจเป็นปัญหา
Doug Smythies avatar
gn flag
"OVH" หมายความว่าเป็นเซิร์ฟเวอร์ที่โฮสต์หรือไม่ การที่การเชื่อมต่อของคุณแสดงในตารางการติดตามนั้นค่อนข้างเป็นพื้นฐาน ดังนั้นฉันไม่รู้ว่าทำไมคุณถึงไม่แสดง
in flag
ไม่ มันเป็นเซิร์ฟเวอร์เฉพาะที่มี OVH ฉันลองบนเซิร์ฟเวอร์คลาวด์กับ OVH โดยใช้ Ubuntu 20.04 และ conntrack -L ไม่แสดงรายการเลย ขาเข้าหรือขาออก ฉันต้องติดตั้ง conntrack และ conntrackd แต่ถึงแม้จะไม่มีการติดตามการเชื่อมต่อ ฉันก็สามารถตั้งค่า ufw ได้ ufw มีการติดตามการเชื่อมต่อของตัวเองหรือไม่? ทั้งหมดนี้สร้างความสับสนและจัดทำเอกสารได้ไม่ดีนัก และฉันก็ไม่ค่อยมั่นใจในการรันบนเซิร์ฟเวอร์ prod จนกว่าฉันจะเข้าใจอย่างถูกต้อง
Doug Smythies avatar
gn flag
ไม่มีตาราง conntrack เว้นแต่ว่า iptables จะใช้ โปรดทราบว่า UFW เป็นเพียงส่วนหน้าสำหรับ iptables วิธีทำความเข้าใจสิ่งนี้คือการใช้ iptables เพื่อดูการไหลของแพ็กเก็ตและตัวนับและชุดกฎที่ UFW สร้างขึ้น ตัวฉันเองฉันเกลียด UFW และชุดกฎ iptables ที่อ่านยากและซับซ้อนที่มันสร้างขึ้น เซิร์ฟเวอร์ทดสอบของฉันไม่ได้ตั้งค่ากฎ iptables เลย และตาราง conntrack แสดงเป็นว่างเปล่า แม้ว่าฉันจะมีเซสชัน SSH หลายเซสชันทำงานอยู่ก็ตาม
in flag
ใช่ ฉันเคยใช้ raw iptables กับ centos โดยไม่มีปัญหาใดๆ ufw ดูเหมือนจะเป็นวิธีที่สมเหตุสมผลในการจัดการไฟร์วอลล์มากกว่าการสร้าง iptables ด้วยมือ

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา