uesenberg
Goto Top

Fedora9 Firewall macht nicht das was sie soll

Firewall öffnet definierte Ports nicht

Habe Fedora9 auf einem Rechner installiert. Über System/Administration/Firewall habe ich verschiedene Ports (1248, 12489, 5666, 5667) eingetragen. Trotz neu Aktivierung der Firewall oder Neustart des PC, bleiben die Ports verschlossen. Auch wenn ich die Firewall deaktiviere, bleiben sie zu.
Die einzigen offenen Ports sind 22, 80, 111, 139, 443, 445.
Wie bringe ich die Firewall dazu, das zu machen was sie soll?

Content-Key: 98714

Url: https://administrator.de/contentid/98714

Printed on: April 26, 2024 at 15:04 o'clock

Member: theton
theton Oct 08, 2008 at 06:04:13 (UTC)
Goto Top
Ports sind nur dann offen, wenn auch ein Service daran lauscht. Ist kein Service auf einem Port, ist dieser unter Linux immer geschlossen.
Member: uesenberg
uesenberg Oct 08, 2008 at 07:27:58 (UTC)
Goto Top
Ja, das ist klar.
Ich habe auf dem Linux-Server Nagios installiert, und der Service lauscht auf Port 5667.

In iptables steht folgende Zeile.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 5667 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 5667 -j ACCEPT
.
.
.
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Member: theton
theton Oct 08, 2008 at 07:36:58 (UTC)
Goto Top
Dann schau mal mit 'netstat' nach ob der Service auch am richtigen Interface lauscht. Wenn er nur auf dem Loopback hängt, ist er nach aussen nicht erreichbar. Im Übrigen sind die Firewall-Regeln ziemlich nutzlos. iptables-Regeln werden sequentiell abgearbeitet. Da die Default-Policy für INPUT auf ACCEPT gesetzt ist, werden sämtliche eingehende Verbindungen zugelassen. Die explizite Freigabe der Ports ist daher nutzlos. Die Default-Policy für INPUT sollte immer DROP oder REJECT sein.
Member: uesenberg
uesenberg Oct 08, 2008 at 09:16:13 (UTC)
Goto Top
wenn der dienst nicht auf dem Interface horcht, was muss ich dafür tun damit er das macht?
Member: theton
theton Oct 08, 2008 at 09:19:49 (UTC)
Goto Top
Den Dienst so konfigurieren dass er die richtige IP zum Binden benutzt.
Member: uesenberg
uesenberg Oct 08, 2008 at 09:51:05 (UTC)
Goto Top
Der Dienst horcht am richtigen Interface.

An dem Fedora-PC arbeitet die Firewall nicht koreckt. Deaktiviere ich sie, ändert sich nichts. Die Ports 5667 bleiben nach aussen und innen zu.
Member: theton
theton Oct 08, 2008 at 10:16:06 (UTC)
Goto Top
Nimm einfach mal folgendes Skript:

#!/bin/bash

echo "Starting firewall"  

LOGLIMIT=20
IPTABLES=/sbin/iptables # pfad ggf. anpassen

case "$1" in  
start)
        echo "starte firewall"  
        # alle alten Regeln entfernen
        echo "Loesche alte Regeln"  
        $IPTABLES -F
        $IPTABLES -X
        $IPTABLES -t nat -F

        # kette fuers logging erstellen
        $IPTABLES -N LOGREJECT
        $IPTABLES -A LOGREJECT -m limit --limit $LOGLIMIT/minute -j LOG --log-prefix "FIREWALL REJECT " --log-level notice --log-ip-options --log-tcp-options  
        $IPTABLES -A LOGREJECT -j REJECT --reject-with icmp-port-unreachable


        ### PROC MANIPULATION ###
        # auf Broadcast-Pings nicht antworten
        echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
        # halt die Klappe bei komischen ICMP Nachrichten
        echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
        # Kicke den ganzen IP Spoofing Shit
        # (Source-Validierung anschalten)
        echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
        # Setze Default-TTL auf 61 (Default fuer Linux ist 64)
        echo 61 > /proc/sys/net/ipv4/ip_default_ttl
        # sende RST-Pakete wenn der Buffer voll ist
        echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
        # warte max. 30 secs auf ein FIN/ACK
        echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
        # unterbreche Verbindungsaufbau nach 3 SYN-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_syn_retries
        # unterbreche Verbindungsaufbau nach 3 SYN/ACK-Paketen
        # Default ist 6
        echo 3 > /proc/sys/net/ipv4/tcp_synack_retries

        # default-policy auf drop setzen
        $IPTABLES -P INPUT DROP
        $IPTABLES -P FORWARD DROP

        # output kann durchgelassen werden
        $IPTABLES -P OUTPUT ACCEPT

        # zu bestehenden zugehoerige verbindungen zulassen
        $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        # im Loopback koennen wir jedem trauen
        $IPTABLES -A INPUT -i lo -j ACCEPT

        # erlaube Pings
        $IPTABLES -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

        # erlaube SSH
        $IPTABLES -A INPUT -p tcp --dport 22 --tcp-flags ALL SYN -j ACCEPT

        # deine gewuenschten ports oeffnen
        $IPTABLES -A INPUT -p tcp --dport 1248 --tcp-flags ALL SYN -j ACCEPT
        $IPTABLES -A INPUT -p tcp --dport 12489 --tcp-flags ALL SYN -j ACCEPT
        $IPTABLES -A INPUT -p tcp --dport 5666 --tcp-flags ALL SYN -j ACCEPT
        $IPTABLES -A INPUT -p tcp --dport 5667 --tcp-flags ALL SYN -j ACCEPT

        # Alle TCP Packete, die bis hier hin kommen, werden
        # geloggt und rejected
        # Der Rest wird eh per Default Policy gedroppt...
        $IPTABLES -A FORWARD -p tcp -j LOGREJECT
        ;;
*)
        echo "Usage: `basename $0` {start}" >&2  
        exit 64
        ;;
esac

exit 0

Abspeichern, ausführbar machen und als root mittels 'skript start' ausführen. Wenn es dann nicht geht, poste bitte den Output von 'netstat -tulpe' (als root ausführen). Dann glaub ich nämlich nicht, dass der Service korrekt konfiguriert ist.
Member: uesenberg
uesenberg Oct 08, 2008 at 11:51:00 (UTC)
Goto Top
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 *:sunrpc *:* LISTEN root 6856 1848/rpcbind
tcp 0 0 *:ssh *:* LISTEN root 8032 2139/sshd
tcp 0 0 nagios:ipp *:* LISTEN root 8547 2238/cupsd
tcp 0 0 *:56664 *:* LISTEN root 6933 1867/rpc.statd
tcp 0 0 nagios:smtp *:* LISTEN root 8218 2159/sendmail: acce
tcp 0 0 *:netbios-ssn *:* LISTEN root 8516 2212/smbd
tcp 0 0 *:http *:* LISTEN root 8271 2179/httpd
tcp 0 0 *:ssh *:* LISTEN root 8030 2139/sshd
tcp 0 0 *:https *:* LISTEN root 8275 2179/httpd
tcp 0 0 *:microsoft-ds *:* LISTEN root 8514 2212/smbd
udp 0 0 *:778 *:* root 6924 1867/rpc.statd
udp 0 0 *:34213 *:* root 6930 1867/rpc.statd
udp 0 0 *:54222 *:* avahi 8500 2228/avahi-daemon:
udp 0 0 *:mdns *:* avahi 8499 2228/avahi-daemon:
udp 0 0 *:kerberos_master *:* root 6855 1848/rpcbind
udp 0 0 *:sunrpc *:* root 6851 1848/rpcbind
udp 0 0 *:ipp *:* root 8550 2238/cupsd
Member: theton
theton Oct 08, 2008 at 18:11:21 (UTC)
Goto Top
Also ich sehe dort keinen offenen NSCA-Port.
Member: uesenberg
uesenberg Oct 09, 2008 at 06:49:01 (UTC)
Goto Top
der nsca-client kann an den nagios-server auf port 5667 auch nicht senden. Da steht im Logfile:
"Could not connect to 192.168.0.251:5667"
Firewall des Clients ist der Port frei.

Wieso lässt sich der port nicht öffnen. Bei Fedora7 gabs auch mal einen Security Bug mit der Firewall. Die hatten das gleiche Problem wie ich mit Fedora9. Selbst wenn ich die Firewall deaktiviere bleiben die Ports dicht.
Member: theton
theton Oct 09, 2008 at 06:57:48 (UTC)
Goto Top
Wenn auf Port 5667 kein Service läuft, dann kann dorthin natürlich auch nicht verbunden werden. Port 5667 ist der NSCA-Port. Siehe /etc/services. Deswegen wird der Port im Output von netstat als 'nsca' betitelt und wie du in deinem netstat-Output siehst, gibt es bei dir keinen Dienst an diesem Port. Du solltest also eher überprüfen warum dieser Dienst nicht startet und/oder an den Port bindet.
Member: uesenberg
uesenberg Oct 10, 2008 at 06:26:37 (UTC)
Goto Top
Ich habe mich dazu entschieden Fedora9 gegen F6 zu ersetzten und nun läuft das Nagios auf dem Server einwandfrei.

zum Vergleich hier netstat -tulpe auf F6

Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode PID/Program name
tcp 0 0 *:netbios-ssn *:* LISTEN root 6829 2199/smbd
tcp 0 0 *:sunrpc *:* LISTEN root 5973 1898/portmap
tcp 0 0 localhost:smtp *:* LISTEN root 6578 2114/sendmail: acce
tcp 0 0 *:827 *:* LISTEN root 6029 1917/rpc.statd
tcp 0 0 *:microsoft-ds *:* LISTEN root 6828 2199/smbd
tcp 0 0 *:http *:* LISTEN root 6654 2142/httpd
tcp 0 0 *:ssh *:* LISTEN root 6506 2096/sshd
tcp 0 0 ep100.europapark.ads:ipp *:* LISTEN root 6472 2087/cupsd
tcp 0 0 *:https *:* LISTEN root 6659 2142/httpd
udp 0 0 *:filenet-tms *:* avahi 6983 2248/avahi-daemon:
udp 0 0 192.168.0.251:netbios-ns *:* root 6839 2203/nmbd
udp 0 0 192.168.2.100:netbios-ns *:* root 6837 2203/nmbd
udp 0 0 *:netbios-ns *:* root 6834 2203/nmbd
udp 0 0 192.168.0.251:netbios-dgm *:* root 6840 2203/nmbd
udp 0 0 192.168.2.100:netbios-dgm *:* root 6838 2203/nmbd
udp 0 0 *:netbios-dgm *:* root 6835 2203/nmbd
udp 0 0 *:821 *:* root 6007 1917/rpc.statd
udp 0 0 *:824 *:* root 6026 1917/rpc.statd
udp 0 0 *:mdns *:* avahi 6981 2248/avahi-daemon:
udp 0 0 *:sunrpc *:* root 5972 1898/portmap
udp 0 0 *:ipp *:* root 6475 2087/cupsd
udp 0 0 *:filenet-rpc *:* avahi 6984 2248/avahi-daemon:
udp 0 0 *:mdns *:* avahi 6982 2248/avahi-daemon: