| View previous topic :: View next topic |
| Author |
Message |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
 Posted: Wed Jan 15, 2020 9:25 am Post subject: sneaky ping... way to not respond to closed ports? |
 |
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
 |
e3k
Guru
Joined: 01 Oct 2007
Posts: 515
Location: Quantum Flux
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
| Posted: Wed Jan 15, 2020 10:06 am Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
e3k
Guru
Joined: 01 Oct 2007
Posts: 515
Location: Quantum Flux
|
| Posted: Wed Jan 15, 2020 11:53 am Post subject: |
|
|
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?
_________________
Flux & Contemplation - Portrait of an Artist in Isolation
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Wed Jan 15, 2020 1:43 pm Post subject: |
|
|
| You'd want to filter the output chain to suppress TCP NACK replies not part of an established connection. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
| Posted: Wed Jan 15, 2020 4:49 pm Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
e3k
Guru
Joined: 01 Oct 2007
Posts: 515
Location: Quantum Flux
|
| Posted: Wed Jan 15, 2020 5:11 pm Post subject: |
|
|
| 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.
_________________
Flux & Contemplation - Portrait of an Artist in Isolation
|
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
| Posted: Wed Jan 15, 2020 6:31 pm Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23062
|
| Posted: Thu Jan 16, 2020 3:11 am Post subject: |
|
|
| 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 |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
| Posted: Thu Jan 16, 2020 3:51 am Post subject: |
|
|
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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
AlexJGreen
Tux's lil' helper
Joined: 19 Sep 2018
Posts: 149
|
| Posted: Fri Jan 17, 2020 1:05 am Post subject: Re: sneaky ping... way to not respond to closed ports? |
|
|
_
Last edited by AlexJGreen on Mon Dec 28, 2020 3:31 am; edited 1 time in total |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9883
Location: almost Mile High in the USA
|
| Posted: Fri Jan 17, 2020 1:28 am Post subject: Re: sneaky ping... way to not respond to closed ports? |
|
|
| 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/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
|
Networking & Security
