Iptables,Netfilter Hilfe bei UDP Packet Filtern
Hallo,
meine Iptables Regeln habe ich so eingestellt das der ganze Input blockiert wird und nur von mir etablierte Verbindungen erlaubt sind. Ich bekomme aber noch UDP Packete(mcast) von einem Laptop in meinem Netzwerk die anscheinend nicht gedropt werden. Wie kann das sein? Was kann ich da machen?
Auszug meiner Iptables Regeln:
Wireshark UDP Packet:
meine Iptables Regeln habe ich so eingestellt das der ganze Input blockiert wird und nur von mir etablierte Verbindungen erlaubt sind. Ich bekomme aber noch UDP Packete(mcast) von einem Laptop in meinem Netzwerk die anscheinend nicht gedropt werden. Wie kann das sein? Was kann ich da machen?
Auszug meiner Iptables Regeln:
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
$IPT -A INPUT -m conntrack --ctstate=RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -m conntrack --ctstate=INVALID -j DROP
$IPT -A OUTPUT -m conntrack --ctstate=RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -m conntrack --ctstate=INVALID -j DROP
$IPT -A OUTPUT -p UDP --dport=53 -j ACCEPT
Wireshark UDP Packet:
Frame 55745: 698 bytes on wire (5584 bits), 698 bytes captured (5584 bits) on interface enp6s0, id 0
Ethernet II, Src:............, Dst:.....................
Destination: IPv4mcast...............
Source: ...................
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 210.211.212.33, Dst: 239.255.255.250
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 684
Identification: 0xe148 (57672)
000. .... = Flags: 0x0
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 1
Protocol: UDP (17)
Header Checksum: 0x3f09 [validation disabled]
[Header checksum status: Unverified]
Source Address: 210.211.212.33
Destination Address: 239.255.255.250
User Datagram Protocol, Src Port: 56993, Dst Port: 3702
Source Port: 56993
Destination Port: 3702
Length: 664
Checksum: 0x2d5a [unverified]
[Checksum Status: Unverified]
[Stream index: 105]
[Timestamps]
[Time since first frame: 0.000000000 seconds]
[Time since previous frame: 0.000000000 seconds]
UDP payload (656 bytes)
Data (656 bytes)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6646414766
Url: https://administrator.de/contentid/6646414766
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
22 Kommentare
Neuester Kommentar
Moin.
Das ist normal das du INBOUND Pakete siehst die später noch gedroppt werden, denn Wireshark/tcpdump sehen INBOUND alle Pakete noch bevor diese von der Firewall verarbeitet werden.
Cheers briggs
Das ist normal das du INBOUND Pakete siehst die später noch gedroppt werden, denn Wireshark/tcpdump sehen INBOUND alle Pakete noch bevor diese von der Firewall verarbeitet werden.
Cheers briggs
ntop , ntopng
Mit modernen nftables statt der veralteten iptables sähe das dann mit einem zusätzlichen Prerouting Filter z.B. so aus (nur SSH inbound erlaubt):
#!/usr/sbin/nft -f
flush ruleset
define pub_iface = "eth0"
table inet drop-bad-ct-states {
chain prerouting {
type filter hook prerouting priority -150; policy accept;
# drop packets in "invalid" connection-tracking state
ct state invalid drop
# drop tcp packets for new connections that aren't syn packets
tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
# drop XMAS packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
# drop NULL packets.
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
# drop new connections over rate limit
ct state new limit rate over 1/second burst 10 packets drop
}
}
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
# accept any localhost traffic
iif lo accept
# accept traffic originated from us
ct state established,related accept
# accepted ICMP types
# ip protocol icmp icmp type {echo-request, echo-reply, time-exceeded, parameter-problem, destination-unreachable } accept
ip protocol icmp icmp type {time-exceeded, parameter-problem, destination-unreachable } accept
# accept common local TCP services on public interface
# iif $pub_iface tcp dport {ssh} ct state new accept
# accept neighbour discovery otherwise IPv6 connectivity breaks.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
# log and count dropped traffic
# log prefix "[nftables]Denied: " counter drop
# only count dropped traffic
counter drop
Auf den ersten Blick sieht Iptables uebersichtlicher aus.
Das ist, wie immer, persönliche Geschmackssache und sieht man anders wenn man mehr mit nftables arbeitet. An der Grundstruktur mit den Chains hat sich ja auch nichts groß geändert.Unterschied ist das iptables auf lange Sicht verschwinden wird.
In allen aktuellen Debian basierten Distros (Bullseye) gibt es schon kein iptables mehr nur noch nftables.
https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
Die Datei oben ist die zentrale nftables Konfig Datei unter /etc/nftables.conf
Mit nft list ruleset kann man das aktive Ruleset ansehen.
https://www.youtube.com/watch?v=KePW2pw8W5w
usw.
Zitat von @TatnocGL:
Die IP 210.211.212.33 ist die LAN IP von dem Laptop. Warum mein Admin 210.211.... genommen hat weiss ich auch nicht ....
Ähm, das würde ich aber mal mit ihm ausdiskutieren, öffentliche IPs in privaten Netzen zu verwenden kann noch ganz andere Seiteneffekte nach sich ziehen.Die IP 210.211.212.33 ist die LAN IP von dem Laptop. Warum mein Admin 210.211.... genommen hat weiss ich auch nicht ....
Gruß
cykes
Zumal wenn es nicht seine IP ist sondern diese einem indischen Provider gehört. Sowas ist fahrlässig!!
inetnum: 210.211.128.0 - 210.211.255.255
mnt-by: APNIC-HM
netname: TATACOMM-IN
descr: Internet Service Provider
descr: TATA Communications formerly VSNL is Leading ISP,
descr: Data and Voice Carrier in India
country: IN
address: 6th Floor, LVSB, VSNL
address: Kashinath Dhuru marg, Prabhadevi
address: Dadar(W), Mumbai 400028
address: India
e-mail: ip.admin@tatacommunications.com
abuse-mailbox: 4755abuse@tatacommunications.com
inetnum: 210.211.128.0 - 210.211.255.255
mnt-by: APNIC-HM
netname: TATACOMM-IN
descr: Internet Service Provider
descr: TATA Communications formerly VSNL is Leading ISP,
descr: Data and Voice Carrier in India
country: IN
address: 6th Floor, LVSB, VSNL
address: Kashinath Dhuru marg, Prabhadevi
address: Dadar(W), Mumbai 400028
address: India
e-mail: ip.admin@tatacommunications.com
abuse-mailbox: 4755abuse@tatacommunications.com
Zitat von @TatnocGL:
Ok hier ist sie,
ich hab noch ein Windows Geraet hier auf dem ich gerne eine Firewall installieren will.
Hab mir 3 Kostenlose rausgesucht: Evorim FreeFirewall ,ZoneAlarm und Free Comodo Firewall.
Ist davon eine gut? Gibt es vieleicht noch andere?bessere?
Gar keine, Winblows hat bereits eine völlig ausreichende FW an Bord wenn damit eh nur gespielt wird, ist ein Zusatzprodukt verschwendete Performance und zusätzliche Fehlerquelle.Ok hier ist sie,
ich hab noch ein Windows Geraet hier auf dem ich gerne eine Firewall installieren will.
Hab mir 3 Kostenlose rausgesucht: Evorim FreeFirewall ,ZoneAlarm und Free Comodo Firewall.
Ist davon eine gut? Gibt es vieleicht noch andere?bessere?
Hab auch gelesen das man mit der Evorim FreeFirewall andere Firewalls kombinieren kann. Also koennte man ja vieleicht die Evorim FreeFirewall und Comodo zusammen installieren. Macht das sinn?
Nein. Macht mehr Probleme als das es hilft oder sicherer macht.ich hab noch ein Windows Geraet hier auf dem ich gerne eine Firewall installieren will.
Aber da ist doch schon die recht gute onboard Defender Firewall drauf. Wie oben schon gesagt: Besser als die ist keine externe FW ins System integriert. Es macht also recht wenig Sinn etwas anderes zu verwenden!meine Skepsis gegenueber Windows/Windowsprodukte mal bei Seite schieben ;)
In dem Falle solltest du da auch ruhig machen!