* basic understanding of iptables - some questions
@ 2016-11-20 20:45 Lentes, Bernd
2016-11-20 21:14 ` Neal P. Murphy
2016-11-23 22:54 ` Pascal Hambourg
0 siblings, 2 replies; 6+ messages in thread
From: Lentes, Bernd @ 2016-11-20 20:45 UTC (permalink / raw)
To: Netfilter
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
--
Bernd Lentes
Systemadministration
institute of developmental genetics
Gebäude 35.34 - Raum 208
HelmholtzZentrum München
bernd.lentes@helmholtz-muenchen.de
phone: +49 (0)89 3187 1241
fax: +49 (0)89 3187 2294
Erst wenn man sich auf etwas festlegt kann man Unrecht haben
Scott Adams
Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671
--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: basic understanding of iptables - some questions
2016-11-20 20:45 basic understanding of iptables - some questions Lentes, Bernd
@ 2016-11-20 21:14 ` Neal P. Murphy
2016-11-23 22:54 ` Pascal Hambourg
1 sibling, 0 replies; 6+ messages in thread
From: Neal P. Murphy @ 2016-11-20 21:14 UTC (permalink / raw)
Cc: Netfilter
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: basic understanding of iptables - some questions
2016-11-20 20:45 basic understanding of iptables - some questions Lentes, Bernd
2016-11-20 21:14 ` Neal P. Murphy
@ 2016-11-23 22:54 ` Pascal Hambourg
2016-12-10 8:43 ` Eliezer Croitoru
1 sibling, 1 reply; 6+ messages in thread
From: Pascal Hambourg @ 2016-11-23 22:54 UTC (permalink / raw)
To: Lentes, Bernd, Netfilter
Le 20/11/2016 à 21:45, Lentes, Bernd a écrit :
>
> 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
I always recommend to use iptables-save or iptables -S instead of
iptables -L because I find the output format much easier to read.
> 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
(...)
> 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.
Yes.
> Because man iptables-extensions says:
>
> ESTABLISHED: The packet is associated with a connection which has seen packets in both directions.
Hint : including the packet being processed.
> 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.
Yes, including the packet being processed.
> 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.
It just did. See above.
> 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 ?).
Yes, and ICMP errors.
> This chain also accepts packets for icmp, dhcp, upnp and mDNS. Right ?
Except for ICMP errors and replies to unicast packets, probably not
because the other listed protocols use broadcast or multicast, but
conntrack only handles correctly unicast traffic.
> 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
Silly. SSH does not use UDP.
> 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.
Guess so.
> Because i don't have a service running on port 12345.
It does not matter to iptables whether a service is running on that port
or not.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: basic understanding of iptables - some questions
2016-11-23 22:54 ` Pascal Hambourg
@ 2016-12-10 8:43 ` Eliezer Croitoru
2016-12-10 15:11 ` /dev/rob0
0 siblings, 1 reply; 6+ messages in thread
From: Eliezer Croitoru @ 2016-12-10 8:43 UTC (permalink / raw)
To: 'Pascal Hambourg', 'Lentes, Bernd',
'Netfilter'
It's not silly that ssh uses UDP since there are implementations of SSH which utilizes UDP....
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer@ngtech.co.il
-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Pascal Hambourg
Sent: Thursday, November 24, 2016 12:54 AM
To: Lentes, Bernd <bernd.lentes@helmholtz-muenchen.de>; Netfilter <netfilter@vger.kernel.org>
Subject: Re: basic understanding of iptables - some questions
Le 20/11/2016 à 21:45, Lentes, Bernd a écrit :
>
> 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
I always recommend to use iptables-save or iptables -S instead of iptables -L because I find the output format much easier to read.
> 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
(...)
> 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.
Yes.
> Because man iptables-extensions says:
>
> ESTABLISHED: The packet is associated with a connection which has seen packets in both directions.
Hint : including the packet being processed.
> 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.
Yes, including the packet being processed.
> 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.
It just did. See above.
> 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 ?).
Yes, and ICMP errors.
> This chain also accepts packets for icmp, dhcp, upnp and mDNS. Right ?
Except for ICMP errors and replies to unicast packets, probably not because the other listed protocols use broadcast or multicast, but conntrack only handles correctly unicast traffic.
> 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
Silly. SSH does not use UDP.
> 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.
Guess so.
> Because i don't have a service running on port 12345.
It does not matter to iptables whether a service is running on that port or not.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: basic understanding of iptables - some questions
2016-12-10 8:43 ` Eliezer Croitoru
@ 2016-12-10 15:11 ` /dev/rob0
2016-12-10 22:52 ` Eliezer Croitoru
0 siblings, 1 reply; 6+ messages in thread
From: /dev/rob0 @ 2016-12-10 15:11 UTC (permalink / raw)
To: netfilter
[ top-posting fixed ]
> Pascal Hambourg:
> Le 20/11/2016 à 21:45, Lentes, Bernd a écrit :
> >
> > 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
>
> Silly. SSH does not use UDP.
On Sat, Dec 10, 2016 at 10:43:47AM +0200, Eliezer Croitoru wrote:
> It's not silly that ssh uses UDP since there are implementations of
> SSH which utilizes UDP....
This post made me curious. Clearly in the case of the OP, Pascal is
correct; we can see the counters on the udp/22 rule above.
I did a bit of searching and the only "ssh using udp" implementation
found was Mosh, <https://mosh.org/>, but Mosh != ssh.
Of what ssh implementation do you speak? More to the point of this
thread, is it using udp/22? Is it available for GNU/Linux?
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: basic understanding of iptables - some questions
2016-12-10 15:11 ` /dev/rob0
@ 2016-12-10 22:52 ` Eliezer Croitoru
0 siblings, 0 replies; 6+ messages in thread
From: Eliezer Croitoru @ 2016-12-10 22:52 UTC (permalink / raw)
To: netfilter
Rob0 thanks for the notes.
First goes first... I have seen a version of ssh somewhere couple years ago
that used some kind of FTP over udp on port 22.
I do not remember the details but it was there and worked for good and bad.
Mosh works on other ports then 22 so this rules is not for mosh.
Probably the version I have seen was self compiled one which was never
released to the public or to anyone except a specific group of sys admins.
I believe that it shouldn't be allowed(22 udp) on systems since it's an open
port waiting for smugglers to smuggle things in and out of the network
pretending to be 22 by the naked admin eyes
And... it's not such a big issue to write an sftp service or an nrpe like
service that will utilize this port for smuggling things.
Leaving ssh the main subject aside, most of the Bittorent world is utilizing
UTP which is a protocol over udp which uses couple very nice FW holes or
piercing like the one that was mentioned.
The most used one is ESTABLISHED,RELATED which the bittorrent users use to
"open" a fake connection from the inside out and using aa coordinator both
peers are 'piercing' the FW each of them from his side.
I can demonstrate if required but I believe it's a known enough issue in
this area of the Internet so I wouldn't be needed to dirty my hands coding
such a thing.
Eliezer
* let me know if I missed something.
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer@ngtech.co.il
-----Original Message-----
From: netfilter-owner@vger.kernel.org
[mailto:netfilter-owner@vger.kernel.org] On Behalf Of /dev/rob0
Sent: Saturday, December 10, 2016 5:12 PM
To: netfilter@vger.kernel.org
Subject: Re: basic understanding of iptables - some questions
[ top-posting fixed ]
> Pascal Hambourg:
> Le 20/11/2016 à 21:45, Lentes, Bernd a écrit :
> >
> > 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
>
> Silly. SSH does not use UDP.
On Sat, Dec 10, 2016 at 10:43:47AM +0200, Eliezer Croitoru wrote:
> It's not silly that ssh uses UDP since there are implementations of
> SSH which utilizes UDP....
This post made me curious. Clearly in the case of the OP, Pascal is
correct; we can see the counters on the udp/22 rule above.
I did a bit of searching and the only "ssh using udp" implementation found
was Mosh, <https://mosh.org/>, but Mosh != ssh.
Of what ssh implementation do you speak? More to the point of this thread,
is it using udp/22? Is it available for GNU/Linux?
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-10 22:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-20 20:45 basic understanding of iptables - some questions Lentes, Bernd
2016-11-20 21:14 ` Neal P. Murphy
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
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.