Re: [PATCH v2] add stealth mode

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' isn't usable?

2) You *do* realize that this isn't anywhere near sufficient in order
to actually make your machine "invisible", right?  (Hint: What *other*
packets can be sent to a machine to provoke a response?)

3) At least my copy had massive whitespace damage, where all the tab characters
appear to have evaporated....

2015-07-06 12:49 GMT+02:00  [off-list ref]:

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' isn't usable?

If you mean using a default DROP policy and allowing only the traffic
do you want,
then the use case is where the port can change at runtime and you may not want
to update the firewall every time

2) You *do* realize that this isn't anywhere near sufficient in order
to actually make your machine "invisible", right?  (Hint: What *other*
packets can be sent to a machine to provoke a response?)

Other than ICMP, UDP and TCP excluding open TCP/UDP ports?

3) At least my copy had massive whitespace damage, where all the tab characters
appear to have evaporated....

Sorry, I was using git sendemail first, but I got a security error from gmail,
so I copied/pasted the patch in gmail which corrupted it

-- 
Matteo Croce
OpenWrt Developer
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------

From: Matteo Croce <redacted>
Date: Mon, 6 Jul 2015 21:44:06 +0200

2015-07-06 12:49 GMT+02:00  [off-list ref]:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' isn't usable?

If you mean using a default DROP policy and allowing only the traffic
do you want,
then the use case is where the port can change at runtime and you may not want
to update the firewall every time

Dynamically updated firewalls are "a thing" and quite effective for
solving problems like this one.

With nftables such updates are even extremely efficient.

Valdis.Kletnieks@vt.edu wrote:

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket

2) You *do* realize that this isn't anywhere near sufficient in order
to actually make your machine "invisible", right?  (Hint: What *other*
packets can be sent to a machine to provoke a response?)

Even worse: if you want to pretend that the entire machine is "not there",
you must make the router in front on you reply with an ICMP "destination
unreachable" message.


Regards,
Clemens

On Mon, Jul 6, 2015, at 21:44, Matteo Croce wrote:

2015-07-06 12:49 GMT+02:00  [off-list ref]:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' isn't usable?

If you mean using a default DROP policy and allowing only the traffic
do you want,
then the use case is where the port can change at runtime and you may not
want
to update the firewall every time

Can't you use socket match in netfilter to accomplish exactly that?

2015-07-07 9:01 GMT+02:00 Clemens Ladisch [off-list ref]:

Valdis.Kletnieks@vt.edu wrote:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket

2) You *do* realize that this isn't anywhere near sufficient in order
to actually make your machine "invisible", right?  (Hint: What *other*
packets can be sent to a machine to provoke a response?)

Even worse: if you want to pretend that the entire machine is "not there",
you must make the router in front on you reply with an ICMP "destination
unreachable" message.

You can't do sometimes, like in DSL lines where the router in front of
you is an ISP owned DSLAM

-- 
Matteo Croce
OpenWrt Developer

2015-07-07 10:07 GMT+02:00 Hannes Frederic Sowa [off-list ref]:

On Mon, Jul 6, 2015, at 21:44, Matteo Croce wrote:

quoted

2015-07-06 12:49 GMT+02:00  [off-list ref]:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' isn't usable?

If you mean using a default DROP policy and allowing only the traffic
do you want,
then the use case is where the port can change at runtime and you may not
want
to update the firewall every time

Can't you use socket match in netfilter to accomplish exactly that?

You mean the owner --uid match?
Yes  sort of, but my was a different goal, I want just to disable any
kind of reply from a specific interface (usually WAN) unless there is
a listening socket, to mitigate port scanning and flood attacks
without having a firewall.

Obviously you can do it with a firewall,
but why do we have /proc/sys/net/ipv4/icmp_echo_ignore_all when we can
drop ICMP echoes?

-- 
Matteo Croce
OpenWrt Developer

On Tue, 2015-07-07 at 17:27 +0200, Matteo Croce wrote:

2015-07-07 10:07 GMT+02:00 Hannes Frederic Sowa <
hannes@stressinduktion.org>:

quoted

On Mon, Jul 6, 2015, at 21:44, Matteo Croce wrote:

quoted

2015-07-06 12:49 GMT+02:00  [off-list ref]:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening 
socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single 
interface.

A few notes.....

1) Do you have an actual use case where an iptables '-j DROP' 
isn't usable?

If you mean using a default DROP policy and allowing only the 
traffic
do you want,
then the use case is where the port can change at runtime and you 
may not
want
to update the firewall every time

Can't you use socket match in netfilter to accomplish exactly that?

You mean the owner --uid match?
Yes  sort of, but my was a different goal, I want just to disable any
kind of reply from a specific interface (usually WAN) unless there is
a listening socket, to mitigate port scanning and flood attacks
without having a firewall.

I was more thinking about the xt_socket match:

-m socket in the INPUT chain.

Obviously you can do it with a firewall,
but why do we have /proc/sys/net/ipv4/icmp_echo_ignore_all when we can
drop ICMP echoes?

Same arguments apply to that knob, but it is already imported and cannot
be changed anymore. Nowadays we try to avoid adding new sysctls.

Bye,
Hannes

On 2015-07-06 15:44, Matteo Croce wrote:

2015-07-06 12:49 GMT+02:00  [off-list ref]:

quoted

On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said:

quoted

Add option to disable any reply not related to a listening socket,
like RST/ACK for TCP and ICMP Port-Unreachable for UDP.
Also disables ICMP replies to echo request and timestamp.
The stealth mode can be enabled selectively for a single interface.

A few notes.....

2) You *do* realize that this isn't anywhere near sufficient in order
to actually make your machine "invisible", right?  (Hint: What *other*
packets can be sent to a machine to provoke a response?)

Other than ICMP, UDP and TCP excluding open TCP/UDP ports?

Just to name a few that I know of off the top of my head:
1. IP packets with any protocol number not supported by your current kernel (these return a special ICMP message).
2. SCTP INIT and COOKIE_ECHO chunks when you have SCTP enabled in the kernel.
3. Theoretically, some IGMP messages.
4. NDP messages.
5. ARP queries looking for the machine's IP addresses.
6. Certain odd flag combinations on single TCP packets (check the documentation for Nmap for more info regarding these), which I believe (although I may be reading the code wrong) you aren't accounting for.
7. DAD queries.
8. ICMP address mask queries (which you also don't appear to account for).

This is by no means an exhaustive list, but all of them really should be addressed if you want to do this properly.

2015-07-08 15:32 GMT+02:00 Austin S Hemmelgarn [off-list ref]:

On 2015-07-06 15:44, Matteo Croce wrote:
Just to name a few that I know of off the top of my head:
1. IP packets with any protocol number not supported by your current kernel
(these return a special ICMP message).

Right, I'll handle them

2. SCTP INIT and COOKIE_ECHO chunks when you have SCTP enabled in the
kernel.

Well, I've never played with SCTP before

3. Theoretically, some IGMP messages.
4. NDP messages.
5. ARP queries looking for the machine's IP addresses.

Yes I know, but it's unlikely to receive this packets from WAN, right?
My flag is intended to be used mostly on WAN interfaces,
machines in LAN should be easily discoverable IMHO

6. Certain odd flag combinations on single TCP packets (check the
documentation for Nmap for more info regarding these), which I believe
(although I may be reading the code wrong) you aren't accounting for.

I've tried many TCP flags combination with hping3, NUL, SYN/ACK, ACK,
SYN/FIN, etc.
They doesn't get any response when the flag is set

7. DAD queries.

Never looked at this packets, are a subset of NDP?

8. ICMP address mask queries (which you also don't appear to account for).

It's deprecated and actually it doesn't get any response already

This is by no means an exhaustive list, but all of them really should be
addressed if you want to do this properly.

Thank you,
-- 
Matteo Croce
OpenWrt Developer
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------

On 2015-07-12 19:13, Matteo Croce wrote:

2015-07-08 15:32 GMT+02:00 Austin S Hemmelgarn [off-list ref]:

quoted

On 2015-07-06 15:44, Matteo Croce wrote:
Just to name a few that I know of off the top of my head:
1. IP packets with any protocol number not supported by your current kernel
(these return a special ICMP message).

Right, I'll handle them

quoted

2. SCTP INIT and COOKIE_ECHO chunks when you have SCTP enabled in the
kernel.

Well, I've never played with SCTP before

It should still be checked, as should DCCP and RDS (those are the only other Layer 3 protocols that I have ever actually seen people try to scan hosts with besides TCP/UDP/SCTP).  SCTP itself is not hugely prevalent outside of some clustering uses, but it is still seen on the internet sometimes (for example, Gentoo has optional patches for OpenSSH to use SCTP).

quoted

3. Theoretically, some IGMP messages.
4. NDP messages.
5. ARP queries looking for the machine's IP addresses.

Yes I know, but it's unlikely to receive this packets from WAN, right?
My flag is intended to be used mostly on WAN interfaces,
machines in LAN should be easily discoverable IMHO.

In theory it's unlikely, but if you use any kind of IPv4 multicast on the WAN you will get IGMP (and MLD for IPv6 multicast).  You may also get some NDP queries also if you are using IPv6 and your WAN is itself behind a NAT router (and yes, there are ISP's who do that).

quoted

6. Certain odd flag combinations on single TCP packets (check the
documentation for Nmap for more info regarding these), which I believe
(although I may be reading the code wrong) you aren't accounting for.

I've tried many TCP flags combination with hping3, NUL, SYN/ACK, ACK,
SYN/FIN, etc.
They doesn't get any response when the flag is set

How about FIN/ACK and FIN/PSH/URG?

quoted

7. DAD queries.

Never looked at this packets, are a subset of NDP?

Kind of, it's an ICMPv6 extension for detecting if SLACC configured address is already in use.  Most distro's have support for it enabled by default.

quoted

8. ICMP address mask queries (which you also don't appear to account for).

It's deprecated and actually it doesn't get any response already

Just because it's deprecated doesn't mean you shouldn't account for it, although it does appear to get dropped by default by the kernel.

You should also test how different combinations of sysctls under /proc/sys/net affect this (there are for example already sysctls for ignoring certain types of ICMP packets).

2015-07-13 15:03 GMT+02:00 Austin S Hemmelgarn [off-list ref]:

How about FIN/ACK and FIN/PSH/URG?

Silent:

root@debian64:~# hping3 192.168.0.2 -p 32 -FA
HPING 192.168.0.2 (eth0 192.168.0.2): AF set, 40 headers + 0 data bytes
^C

--- 192.168.0.2 hping statistic ---

3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
root@debian64:~# hping3 192.168.0.2 -p 32 -FPU
HPING 192.168.0.2 (eth0 192.168.0.2): FPU set, 40 headers + 0 data bytes
^C

--- 192.168.0.2 hping statistic ---

3 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms


Matteo Croce
OpenWrt Developer
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------