# sneaky ping... way to not respond to closed ports?

## eccerr0r

Well, I noticed people are pinging my machine ... both ICMP and apparently via TCP.  ICMP echo response is easy to silence, but what about TCP?

Is there a way to simply not respond to ports that are closed, so ones machine doesn't send out packets, and let the attacker keep state open?

The rub is that ports that are open - should respond normally...

I seem to find grsec has an option...which isn't an option on a vanilla kernel?

----------

## e3k

if you want your host to be silent when contacted on a closed port use DROP instead of REJECT in iptables.

----------

## eccerr0r

Eh... welll, not quite the right answer... 

Or maybe it is, but the trouble is I want to set up a rule to automatically skip the ports that are actually being listened to, instead of manually punching holes....

----------

## e3k

maybe i do not understand you but this seems trivial for me. i would set the default action on the INPUT CHAIN to DROP and then just allow specific ports. is this what you wanted?

----------

## Ant P.

You'd want to filter the output chain to suppress TCP NACK replies not part of an established connection.

----------

## eccerr0r

Well, if I just dropped all from port 0 to port 65535, but this would not let anyone have legitimate incoming packets.

So technically the hard way is making a rule from port 0 to port 24, then port 26 to port 79, then port 81 to port 1193, and then port 1195 to port 65535... 

... but can this done automatically, so that if I decided to start to listen to port 443, I wouldn't have to manually punch a hole through this?

Hmm, however, filtering the output chain sounds like a plan.  It might just work though need to think about this some more. I hope there are no legitimate reasons to send the NACK packets.

----------

## e3k

 *eccerr0r wrote:*   

> so that if I decided to start to listen to port 443, I wouldn't have to manually punch a hole through this?

 it was years ago so i do not recall this very clearly but last time i checked it did DROP packets even if port was open but no service listening/running.

iptables -P INPUT DROP

would have to check to be sure. nmap probably. would have to set it up first.... takes time.

----------

## eccerr0r

Ah that might do it too... will need to check later.  Thanks.

[EDIT]

Ahh nope, setting a default policy to drop still requires an accept rule for listeners... close, but was hoping I would not need to touch iptables when starting to listen to a port.

[EDIT]

Dropping the packets on outgoing -- so far, so good... Now I just hope regular connections do not hang when those packets never make it, I was hoping that this would only happen on new port open attempts.

----------

## Hu

 *eccerr0r wrote:*   

> Is there a way to simply not respond to ports that are closed, so ones machine doesn't send out packets, and let the attacker keep state open?

 Failing to respond, such as by using DROP, is the simplest.  If you want to be more disruptive to peers, you could use TARPIT instead.  It is not as stealthy, but can cause more problems for some unwanted peers. *eccerr0r wrote:*   

> I seem to find grsec has an option...which isn't an option on a vanilla kernel?

 I believe the target was never merged upstream. *eccerr0r wrote:*   

> Or maybe it is, but the trouble is I want to set up a rule to automatically skip the ports that are actually being listened to, instead of manually punching holes....

 How many holes do you expect to have, that automatically whitelisting them is worth the trouble of setting up a context-sensitive rule? *eccerr0r wrote:*   

> Well, if I just dropped all from port 0 to port 65535, but this would not let anyone have legitimate incoming packets.

 Use connection tracking, so that packets associated with legitimate existing connections work. *eccerr0r wrote:*   

> So technically the hard way is making a rule from port 0 to port 24, then port 26 to port 79, then port 81 to port 1193, and then port 1195 to port 65535... 

 Traditionally, you would write rules to permit the ports you want, then have a default rule that denies all ports that are not on the permitted list.  This makes it easier to reason about your firewall rules. *eccerr0r wrote:*   

> ... but can this done automatically, so that if I decided to start to listen to port 443, I wouldn't have to manually punch a hole through this?

 How often are you adding new listeners, that this is a serious concern? *eccerr0r wrote:*   

> Hmm, however, filtering the output chain sounds like a plan.  It might just work though need to think about this some more. I hope there are no legitimate reasons to send the NACK packets.

 There are legitimate uses of TCP RST other than the one you want to suppress.

----------

## eccerr0r

I think the ugliest program is bittorrent which doesn't really have a defined port, or at least I don't want it to have a well defined port.  Fewer the better.

I think for now the suppressing of the RSTs seems to be working.  I can still connect to my machine okay from remote, but yeah need to do some more testing.

I still do not understand why the bot swarm decided to hit my machine so hard.   Very frustrating.

----------

## AlexJGreen

_Last edited by AlexJGreen on Mon Dec 28, 2020 3:31 am; edited 1 time in total

----------

## eccerr0r

 *coderanger wrote:*   

> No one can control the state of a socket on the attacker's side and therefore no benefits in additional dropping packages coming to the closed ports.
> 
> 

 

You know... I can.

Though I can't control what they send, but I can control what they need to remember.  What I wanted to do is not respond to packets -- because I don't respond and the stateful nature of TCP, *THEY* have to memorize that they have a outstanding SYN packet which they are looking for a SYNACK or RST that will never come.  So I *can* control how long their socket stays open.  They can choose to forget by cancelling their connection.

As long as the socket is closed on my end (which is instantaneous on closed ports), I'm happy, SCREW THEM.

:)

Honestly if I had large or unlimited bandwidth I would not mind sending the RSTs, ICMP echo-replies, or even SYNACK because I don't have a problem with the guesses that will never succeed.  However due to limited bandwidth, this stuff costs me, and best not to respond.

----------

