Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
sneaky ping... way to not respond to closed ports?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Wed Jan 15, 2020 9:25 am    Post subject: sneaky ping... way to not respond to closed ports? Reply with quote

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?
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
e3k
Guru
Guru


Joined: 01 Oct 2007
Posts: 518
Location: Inner Space

PostPosted: Wed Jan 15, 2020 9:43 am    Post subject: Reply with quote

if you want your host to be silent when contacted on a closed port use DROP instead of REJECT in iptables.
_________________
CLOSED|||||||||||LISTEN
SYN-SENT --> SYN-RECEIVED
ESTABLISHED <-- SYN-RECEIVED
ESTABLISHED --> ESTABLISHED
ESTABLISHED --> <DATA> --> ESTABLISHED
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Wed Jan 15, 2020 10:06 am    Post subject: Reply with quote

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....
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
e3k
Guru
Guru


Joined: 01 Oct 2007
Posts: 518
Location: Inner Space

PostPosted: Wed Jan 15, 2020 11:53 am    Post subject: Reply with quote

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?
_________________
CLOSED|||||||||||LISTEN
SYN-SENT --> SYN-RECEIVED
ESTABLISHED <-- SYN-RECEIVED
ESTABLISHED --> ESTABLISHED
ESTABLISHED --> <DATA> --> ESTABLISHED
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6486

PostPosted: Wed Jan 15, 2020 1:43 pm    Post subject: Reply with quote

You'd want to filter the output chain to suppress TCP NACK replies not part of an established connection.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Wed Jan 15, 2020 4:49 pm    Post subject: Reply with quote

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.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
e3k
Guru
Guru


Joined: 01 Oct 2007
Posts: 518
Location: Inner Space

PostPosted: Wed Jan 15, 2020 5:11 pm    Post subject: Reply with quote

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.
_________________
CLOSED|||||||||||LISTEN
SYN-SENT --> SYN-RECEIVED
ESTABLISHED <-- SYN-RECEIVED
ESTABLISHED --> ESTABLISHED
ESTABLISHED --> <DATA> --> ESTABLISHED
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Wed Jan 15, 2020 6:31 pm    Post subject: Reply with quote

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.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15313

PostPosted: Thu Jan 16, 2020 3:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Thu Jan 16, 2020 3:51 am    Post subject: Reply with quote

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.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
coderanger
Tux's lil' helper
Tux's lil' helper


Joined: 19 Sep 2018
Posts: 103
Location: Ukraine

PostPosted: Fri Jan 17, 2020 1:05 am    Post subject: Re: sneaky ping... way to not respond to closed ports? Reply with quote

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?

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.
What really matters is a traffic coming from countries where you have audience - everything else must be blocked.

For example, I block traffic from
- cloud providers like aws
- countries I do not expect mails/http requests from
- countries already seen in suspicious activity
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7444
Location: almost Mile High in the USA

PostPosted: Fri Jan 17, 2020 1:28 am    Post subject: Re: sneaky ping... way to not respond to closed ports? Reply with quote

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.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
coderanger
Tux's lil' helper
Tux's lil' helper


Joined: 19 Sep 2018
Posts: 103
Location: Ukraine

PostPosted: Fri Jan 17, 2020 9:58 am    Post subject: Re: sneaky ping... way to not respond to closed ports? Reply with quote

eccerr0r wrote:
limited bandwidth, this stuff costs


Thanks for the explanation. Now I understand.
Unfortunately linux kernel has no appropriate sysctl variable to enable blackhole for packages received on closed ports like freebsd kernel has. And it looks to me the only option is to go with DROP rule :(
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum