วิธีรันเซิร์ฟเวอร์บนพอร์ต 80 ในฐานะผู้ใช้ปกติบน Linux?

ฉันใช้ Googled เกี่ยวกับวิธีแก้ปัญหามาระยะหนึ่งแล้ว แต่ไม่พบคำตอบ

ฉันใช้ Ubuntu Linux และต้องการใช้งานเซิร์ฟเวอร์ที่พอร์ต 80 แต่เนื่องจากกลไกความปลอดภัยของ Ubuntu ฉันได้รับข้อผิดพลาดดังต่อไปนี้:

java.net.BindException: การอนุญาตถูกปฏิเสธ: 80

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

คำตอบสั้น ๆ : คุณทำไม่ได้ พอร์ตที่ต่ำกว่า 1024 สามารถเปิดได้โดยรูทเท่านั้น ตามความคิดเห็น - คุณสามารถใช้CAP_NET_BIND_SERVICEแต่วิธีการที่นำไปใช้กับ java bin จะทำให้โปรแกรม java ใด ๆ ที่จะทำงานด้วยการตั้งค่านี้ซึ่งไม่พึงประสงค์หากไม่เสี่ยงต่อความปลอดภัย

คำตอบที่ยาว: คุณสามารถเปลี่ยนเส้นทางการเชื่อมต่อบนพอร์ต 80 ไปยังพอร์ตอื่นที่คุณสามารถเปิดได้เหมือนผู้ใช้ปกติ

เรียกใช้เป็นราก:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

เนื่องจากอุปกรณ์ลูปแบ็ค (เช่น localhost) อย่าใช้กฎการกำหนดล่วงหน้าหากคุณต้องการใช้ localhost ฯลฯ ให้เพิ่มกฎนี้ด้วย ( ขอบคุณ @Francesco ):

# iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

หมายเหตุ: วิธีการแก้ปัญหาข้างต้นไม่เหมาะสำหรับระบบที่มีผู้ใช้หลายคนเนื่องจากผู้ใช้สามารถเปิดพอร์ต 8080 (หรือพอร์ตสูงอื่น ๆ ที่คุณตัดสินใจใช้) จึงขัดขวางการรับส่งข้อมูล (มอบเครดิตให้แก่CesarB )

แก้ไข: ตามคำถามความคิดเห็น - เพื่อลบกฎข้างต้น:

# iptables -t nat --line-numbers -n -L

สิ่งนี้จะให้ผลลัพธ์เช่น:

Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination         
1    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8080 redir ports 8088
2    REDIRECT   tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80 redir ports 8080

กฎที่คุณสนใจคือ nr 2 เพื่อลบ:

# iptables -t nat -D PREROUTING 2

ใช้การตรวจสอบอัตโนมัติ

สามารถใช้งานได้กับ Java หากคุณเปิดใช้งานสแต็ก IPv4 เท่านั้นของ Java ฉันใช้:

authbind --deep $JAVA_HOME/bin/java -Djava.net.preferIPv4Stack=true …

หากระบบของคุณรองรับคุณอาจใช้ความสามารถ ดูความสามารถของมนุษย์สิ่งที่คุณต้องการคือ CAP_NET_BIND_SERVICE

ใน Debian / Ubuntu รุ่นใหม่กว่าคุณสามารถเรียกใช้:

sudo apt-get install libcap2-bin 
sudo setcap 'cap_net_bind_service=+ep' /path/to/program

วิธีแก้ปัญหาอื่นคือทำให้แอปของคุณตั้งค่าเพื่อให้สามารถผูกกับพอร์ต 80 ได้ในฐานะที่เป็นรูทให้ทำดังต่อไปนี้

chown root ./myapp
chmod +S ./myapp

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

อัปเดต: ตามที่เห็นในคำถามนี้ปรากฏว่าเคอร์เนล Linux ตั้งแต่ 2.6.24 มีความสามารถใหม่ที่อนุญาตให้คุณทำเครื่องหมายความสามารถในการเรียกใช้งาน (แต่ไม่ใช่สคริปต์แน่นอน) ว่ามีCAP_NET_BIND_SERVICEความสามารถ "" หากคุณติดตั้งแพคเกจเดเบียน "libcap2-bin" คุณสามารถทำได้โดยการออกคำสั่ง

setcap 'cap_net_bind_service=+ep' /path/to/program

ฉันใช้ Nginx ด้านหน้าเท่านั้น มันสามารถทำงานบน localhost ได้เช่นกัน

• apt-get install nginx

.. หรือ ..

• pkg_add -r nginx

.. หรือสิ่งที่เหมาะสมกับระบบปฏิบัติการของคุณ

สิ่งที่คุณต้องการใน nginx.conf หากทำงานบน localhost คือ:

เซิร์ฟเวอร์ {
        ฟัง 80;
        server_name some.domain.org;
        ตำแหน่ง / {
            proxy_set_header โฮสต์ $ host;
            proxy_set_header X-Real-IP $ remote_addr;
            proxy_set_header X-Forwarded- สำหรับ $ proxy_add_x_forwarded_for;
            proxy_pass http://127.0.0.1:8081;
        }
}

แนวทางที่เสนอโดย Sunny และ CesarB:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

ทำงานได้ดี แต่มีข้อเสียเปรียบเล็กน้อย - ไม่ได้ป้องกันผู้ใช้จากการเชื่อมต่อโดยตรงกับพอร์ต 8080 แทน 80

พิจารณาสถานการณ์สมมติต่อไปนี้เมื่ออาจเป็นปัญหา

สมมติว่าเรามีเซิร์ฟเวอร์ที่ยอมรับการเชื่อมต่อ HTTP บนพอร์ต 8080 และการเชื่อมต่อ HTTPS บนพอร์ต 8181

เราใช้ iptables เพื่อสร้างการเปลี่ยนเส้นทางต่อไปนี้:

80  ---> 8080
443 ---> 8181

ทีนี้สมมติว่าเซิร์ฟเวอร์ของเราตัดสินใจเปลี่ยนเส้นทางผู้ใช้จากหน้า HTTP ไปยังหน้า HTTPS https://host:8181/ถ้าเราไม่ระมัดระวังเขียนการตอบสนองก็จะเปลี่ยนเส้นทางไปยัง ณ จุดนี้เราเมา:

• ผู้ใช้บางคนจะคั่นหน้าhttps://host:8181/URL และเราจะต้องรักษา URL นี้ไว้เพื่อหลีกเลี่ยงการทำลายที่คั่นหน้า
• ผู้ใช้รายอื่นจะไม่สามารถเชื่อมต่อได้เนื่องจากพร็อกซีเซิร์ฟเวอร์ไม่รองรับพอร์ต SSL ที่ไม่ได้มาตรฐาน

ฉันใช้วิธีการต่อไปนี้:

iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 1
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8181
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -m mark --mark 1 -j ACCEPT
iptables -I INPUT -m state --state NEW -m tcp -p tcp --dport 8181 -m mark --mark 1 -j ACCEPT

รวมกับกฎ REJECT เริ่มต้นบนเชน INPUT วิธีนี้จะป้องกันผู้ใช้จากการเชื่อมต่อโดยตรงกับพอร์ต 8080, 8181

ตามธรรมเนียมบน Unix เฉพาะ root เท่านั้นที่สามารถเชื่อมโยงกับพอร์ตต่ำ (<1024)

วิธีที่ง่ายที่สุดในการหลีกเลี่ยงปัญหานี้คือการเรียกใช้เซิร์ฟเวอร์ของคุณบนพอร์ตสูง (เช่น 8080) และใช้กฎ iptables ง่าย ๆ เพื่อส่งต่อการเชื่อมต่อจากพอร์ต 80 ไปยังพอร์ต 8080 โปรดทราบว่าสิ่งนี้ทำให้คุณสูญเสียการป้องกันเพิ่มเติมจาก พอร์ตต่ำ ผู้ใช้ใด ๆ บนเครื่องของคุณสามารถผูกกับพอร์ต 8080

หากระบบของคุณรองรับคุณอาจใช้ความสามารถ ดูหนึ่งที่คุณต้องการจะเป็นman capabilities CAP_NET_BIND_SERVICEไม่ฉันไม่เคยใช้ด้วยตนเองและฉันก็ไม่รู้ว่าทำงานได้จริง :-)

ใช้ reverse proxy (nginx, apache + mod_proxy) หรือ reverse proxy แคช (Squid, Varnish) ต่อหน้าเซิร์ฟเวอร์แอพพลิเคชันของคุณ!

ด้วยพร็อกซีย้อนกลับคุณสามารถบรรลุสิ่งที่น่าสนใจมากมายเช่น:

• โหลดสมดุล
• รีสตาร์ทเซิร์ฟเวอร์แอปพลิเคชันของคุณด้วยผู้ใช้ที่ได้รับหน้าข้อผิดพลาดแฟนซี
• เร่งความเร็วสิ่งของด้วยแคช
• การตั้งค่าแบบละเอียดที่ปกติแล้วคุณทำกับ reverse-proxy และไม่ใช่กับเซิร์ฟเวอร์แอปพลิเคชัน

คุณสามารถใช้โปรแกรม redir:

sudo redir --lport=80 --laddr=192.168.0.101 --cport 9990 --caddr=127.0.0.1

ใช้ sudo

กำหนดค่า sudo เพื่อให้ผู้ใช้ทั่วไปสามารถเรียกใช้คำสั่งที่เหมาะสม:

/etc/init.d/httpd start

หรือ

apachectl stop

หรือ

/usr/local/apache2/apachectl restart

หรือ

/myapp/myappbin start

(หรือคำสั่ง / สคริปต์ใด ๆ ก็ตามที่คุณใช้เพื่อเริ่ม / หยุดคุณเว็บเซิร์ฟเวอร์ / แอปเฉพาะ)

คำตอบของ sunny ถูกต้อง แต่คุณอาจประสบปัญหาเพิ่มเติมเนื่องจากส่วนต่อประสานย้อนกลับไม่ได้ใช้ตาราง PREROUTING

ดังนั้นกฎ iptables ที่จะเพิ่มเป็นสอง:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

ด้วย Linux คุณมีสองตัวเลือกอื่น ๆ :

• คุณสามารถลอง SELinux ( http://www.nsa.gov/selinux/ )
• คุณสามารถลอง grsecurity ( http://www.grsecurity.net/ )

ส่วนขยายทั้งสองไปยังเคอร์เนล Linux อนุญาตให้สิทธิ์การเข้าถึงในระดับที่ละเอียดมาก สิ่งนี้จะช่วยให้คุณสามารถอนุญาตให้กระบวนการนี้เปิดพอร์ต 80 แต่จะไม่สืบทอดสิทธิ์รูทอื่น ๆ

จากสิ่งที่ฉันเคยได้ยินความปลอดภัย grs ง่ายต่อการใช้งานมากขึ้น แต่ SELinux มีความปลอดภัยมากขึ้น

ทางออกหนึ่งคือการใช้ iptables เพื่อดำเนินการ PAT บนแพ็คเก็ตสำหรับพอร์ต 80 คุณสามารถใช้สิ่งนี้เพื่อกำหนดเส้นทางแพ็คเก็ตไปยังพอร์ตท้องถิ่น 8080 ตัวอย่างเช่น ตรวจสอบและปรับแพ็กเก็ตขาออกกลับไปที่พอร์ต 80

จากประสบการณ์ของฉันฟีเจอร์การอนุญาตที่ละเอียดของลีนุกซ์ไม่ได้ถูกรวบรวมไว้ในเมล็ดมาตรฐานเนื่องจากปัญหาด้านความปลอดภัย

หากคุณพยายามทำเช่นนี้เพื่อให้คำสั่งที่ผู้ใช้เรียกใช้สามารถใช้พอร์ต 80 ได้โซลูชันเดียวของคุณคือเทคนิค iptables หรือตั้งค่าไฟล์ปฏิบัติการ setuid-to-root

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

เมื่อฉันมีแอปพลิเคชั่นการให้บริการเว็บต่างๆ (สคริปต์หลาม, เครื่องยนต์ทอมแคท, ... ) ที่ฉันไม่ต้องการเรียกใช้ในฐานะรูทฉันมักจะกำหนดค่าเว็บเซิร์ฟเวอร์ Apache ไว้ข้างหน้าพวกเขา Apache ฟังพอร์ต 80 และ tomcat รับฟัง 8080

ใน apache: s config:

ProxyPass /webapp http://localhost:8080/webapp
ProxyPassReverse /webapp http://localhost:8080/webapp

ดูเอกสารประกอบ mod-proxy สำหรับข้อมูลเพิ่มเติม: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html

ฉันคิดว่าทางออกที่ดีที่สุดคือ sgid แอปของคุณและทันทีที่พอร์ตของมันถูกผูกไว้ก็ควรจะลดระดับสิทธิ์โดยการสลับไปใช้ผู้ใช้รายอื่น

ระบบโฮสต์บางระบบไม่อนุญาตให้ใช้โมดูล NAT 'iptables' ไม่สามารถแก้ปัญหาได้ในกรณีนี้

แล้ว xinetd ล่ะ?

ในกรณีของฉัน (Ubuntu 10.04)

# apt-get install xinetd
# touch /etc/xinetd.d/my_redirect
# vim /etc/xinetd.d/my_redirect

วางการกำหนดค่า:

service my_redirector_80
{
 disable = no
 socket_type = stream
 protocol = tcp
 user = root
 wait = no
 port = 80
 redirect = localhost 8080
 type = UNLISTED
}

แล้ว:

# service xinetd restart

http://docs.codehaus.org/display/JETTY/port80อธิบายได้ดีขึ้น

ในฐานะที่เป็นกัน FreeBSD และ Solaris (ใครจำได้ว่าเป็น?) ช่วยให้คุณทำเช่นนี้ (ผูกกับพอร์ตต่ำ) โดยไม่มีการเพิ่มสิทธิพิเศษ (เช่นการใช้โปรแกรมเพื่อเปลี่ยนเป็นรูท) เมื่อคุณระบุลีนุกซ์ฉันเพิ่งโพสต์สิ่งนี้เป็นประกาศให้ผู้อื่นที่อาจพบคำถามนี้

Necromancing

ง่าย ด้วยเคอร์เนลปกติหรือเก่าคุณทำไม่ได้
ตามที่คนอื่น ๆ ชี้ให้เห็น iptables สามารถส่งต่อพอร์ต
ตามที่คนอื่น ๆ ชี้ให้เห็น CAP_NET_BIND_SERVICE ก็สามารถทำงานได้เช่นกัน
แน่นอนว่า CAP_NET_BIND_SERVICE จะล้มเหลวถ้าคุณเปิดโปรแกรมจากสคริปต์เว้นแต่ว่าคุณตั้งค่า cap บนตัวแปลเชลล์ซึ่งไม่มีจุดหมายคุณสามารถเรียกใช้บริการของคุณในฐานะ root ...
เช่นสำหรับ Java คุณต้องใช้มัน ถึง JAVA JVM

sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java

เห็นได้ชัดว่านั่นหมายความว่าโปรแกรม Java ใด ๆ สามารถผูกพอร์ตระบบได้
Dito สำหรับโมโน /. NET

ฉันค่อนข้างมั่นใจว่า xinetd ไม่ใช่คนที่ดีที่สุดของความคิด
แต่เนื่องจากทั้งสองวิธีนี้มีแฮ็กทำไมไม่ยกระดับ จำกัด ด้วยการยกข้อ จำกัด ?
ไม่มีใครบอกว่าคุณต้องใช้เคอร์เนลปกติดังนั้นคุณสามารถรันเคอร์เนลของคุณเองได้

คุณเพียงแค่ดาวน์โหลดแหล่งที่มาสำหรับเคอร์เนลล่าสุด (หรือที่คุณมีอยู่ในปัจจุบัน) หลังจากนั้นคุณไปที่:

/usr/src/linux-<version_number>/include/net/sock.h:

ที่นั่นคุณมองหาบรรทัดนี้

/* Sockets 0-1023 can't be bound to unless you are superuser */
#define PROT_SOCK       1024

และเปลี่ยนเป็น

#define PROT_SOCK 0

หากคุณไม่ต้องการมีสถานการณ์ที่ไม่ปลอดภัยของ ssh คุณต้องเปลี่ยนเป็น: #define PROT_SOCK 24

โดยทั่วไปฉันจะใช้การตั้งค่าต่ำสุดที่คุณต้องการเช่น 79 สำหรับ http หรือ 24 เมื่อใช้ SMTP บนพอร์ต 25

นั่นคือทั้งหมด
รวบรวมเคอร์เนลและติดตั้ง
Reboot
เสร็จสิ้น - ข้อ จำกัด ที่โง่คือ GONE และใช้ได้กับสคริปต์ด้วย

นี่คือวิธีที่คุณรวบรวมเคอร์เนล:

https://help.ubuntu.com/community/Kernel/Compile

# You can get the kernel-source via package linux-source, no manual download required
apt-get install linux-source fakeroot

mkdir ~/src
cd ~/src
tar xjvf /usr/src/linux-source-<version>.tar.bz2
cd linux-source-<version>

# Apply the changes to PROT_SOCK define in /include/net/sock.h

# Copy the kernel config file you are currently using
cp -vi /boot/config-`uname -r` .config

# Install ncurses libary, if you want to run menuconfig
apt-get install libncurses5 libncurses5-dev

# Run menuconfig (optional)
make menuconfig

# Define the number of threads you wanna use when compiling (should be <number CPU cores> - 1), e.g. for quad-core
export CONCURRENCY_LEVEL=3
# Now compile the custom kernel
fakeroot make-kpkg --initrd --append-to-version=custom kernel-image kernel-headers

# And wait a long long time

cd ..

สรุปใช้ iptables ถ้าคุณต้องการรักษาความปลอดภัยรวบรวมเคอร์เนลถ้าคุณต้องการให้แน่ใจว่าข้อ จำกัด นี้ไม่รบกวนคุณอีก