From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
Cc: Netfilter <netfilter@vger.kernel.org>
Subject: Re: basic understanding of iptables - some questions
Date: Sun, 20 Nov 2016 16:14:18 -0500 [thread overview]
Message-ID: <20161120161418.2ca1938b@playground> (raw)
In-Reply-To: <560733058.4361908.1479674705472.JavaMail.zimbra@helmholtz-muenchen.de>
Unless I misunderstand or things have changed in recent years,
- NEW refers to an unanswered SYN (for TCP) or the first packet of a UDP conn
- RELATED refers to (1) an unanswered SYN (for TCP), or (2) the first packet of
a UDP conn, that a conntrack helper has determined is related to an existing conn.
- ESTABLISHED refers to all subsequent packets in any conn.
Therefore, you can only know that a packet is the first packet of a conn or it is a subsequent packet. You can't know which conn a RELATED packet is associated with, and without using CONNMARKs, you cannot know if a conn was RELATED once it is ESTABLISHED.
N
On Sun, 20 Nov 2016 21:45:05 +0100 (CET)
"Lentes, Bernd" <bernd.lentes@helmholtz-muenchen.de> wrote:
> Hi,
>
>
>
> I'm trying to understand Ubuntu 16.04 (kernel 4.4.0-45-generic) firewall rules. See the rules for the chain INPUT:
>
> Chain INPUT (policy DROP 20 packets, 800 bytes)
> pkts bytes target prot opt in out source destination
> 880 134K ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
> 880 134K ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
> 481 86297 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
> 20 800 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
> 20 800 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
> 20 800 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
>
> chain ufw-before-logging-input (1 references)
> pkts bytes target prot opt in out source destination
>
>
> Chain ufw-before-logging-input does nothing, so evaluating the rules continues with ufw-before-input:
>
> Chain ufw-before-input (1 references)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
> 317 22568 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
> 0 0 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 3
> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 4
> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 11
> 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 12
> 4 112 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
> 72 23616 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
> 487 87216 ufw-not-local all -- * * 0.0.0.0/0 0.0.0.0/0
> 6 919 ACCEPT udp -- * * 0.0.0.0/0 224.0.0.251 udp dpt:5353
> 0 0 ACCEPT udp -- * * 0.0.0.0/0 239.255.255.250 udp dpt:1900
> 481 86297 ufw-user-input all -- * * 0.0.0.0/0 0.0.0.0/0
>
> First question:
> second rule: is that the rule for responses from outgoing packets ? E.g. i start a browser and open a web page. First my host does a TCP SYN to the web server, and this one answers with a tcp SYN ACK.
> Because man iptables-extensions says:
>
> ESTABLISHED: The packet is associated with a connection which has seen packets in both directions.
> RELATED: The packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer or an ICMP error.
>
> Because ESTABLISHED must have seen packets in BOTH directions. When i open a web page and the first packet comes back from the webserver (SYN ACK), this connection does not have seen packets in both directions.
> And RELATED, as i understand, is e.g. for ftp, which uses in one session different destination ports (i think one for control and one for data ?).
>
> But if this is not the rule for the first packet coming back, where is this rule ?
>
> This chain also accepts packets for icmp, dhcp, upnp and mDNS. Right ?
>
> OK. Evaluating continues with ufw-user-input, which are e.g. the services opened by the admin for some services, like ssh ...
>
> Chain ufw-user-input (1 references)
> pkts bytes target prot opt in out source destination
> 41587 1849K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
> 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:22
> 1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7937
> 5 300 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7938
> 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:7938
>
>
> Evaluating continues with ufw-after-input, which drops e.g. some packtes for windows services (file sharing ...) and dhcp.
> It does this by calling another chain which drops the packets.
>
> Chain ufw-after-input (1 references)
> pkts bytes target prot opt in out source destination
> 18978 1486K ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
> 5358 1231K ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
> 0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
> 0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
> 67988 25M ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
> 0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
> 159K 20M ufw-skip-to-policy-input all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
>
> Chain ufw-skip-to-policy-input (7 references)
> pkts bytes target prot opt in out source destination
> 251K 48M DROP all -- * * 0.0.0.0/0 0.0.0.0/0
>
>
> And THEN comes ufw-after-logging-input, which logs all the packets which survived all the previous rules.
>
> Chain ufw-after-logging-input (1 references)
> pkts bytes target prot opt in out source destination
> 42933 1717K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 8 level 4 prefix "[UFW BLOCK INPUT] "
>
>
> So ufw-after-logging-input comes into play when there is a packet which has no previous packet in any direction, is not for the allowed services nor for the denied services.
> E.g. i do a port scan to 12345 on that host. Right ? It should be logged by that rule. Because i don't have a service running on port 12345.
>
> The reason i'm asking is that i have some logging from this rule with ip addresses not from our network, and i'd like to know when this rule comes into play.
>
> I'd appreciate any help, if you want to know more please ask me.
>
> Thanks.
>
> Bernd
>
>
next prev parent reply other threads:[~2016-11-20 21:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-20 20:45 basic understanding of iptables - some questions Lentes, Bernd
2016-11-20 21:14 ` Neal P. Murphy [this message]
2016-11-23 22:54 ` Pascal Hambourg
2016-12-10 8:43 ` Eliezer Croitoru
2016-12-10 15:11 ` /dev/rob0
2016-12-10 22:52 ` Eliezer Croitoru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161120161418.2ca1938b@playground \
--to=neal.p.murphy@alum.wpi.edu \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox