* Getting iptables not to reply
@ 2013-09-30 15:58 jack seth
2013-09-30 17:32 ` Shawn Wilson
0 siblings, 1 reply; 6+ messages in thread
From: jack seth @ 2013-09-30 15:58 UTC (permalink / raw)
To: netfilter@vger.kernel.org
Ok, if you have an 'accept' rule for a service that is not currently running, is it possible to have iptables to simply not respond instead of reporting the port as 'closed'? During a port scan at grc.com, if the router doesn't reply the port will be reported as 'stealth'.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Getting iptables not to reply
2013-09-30 15:58 Getting iptables not to reply jack seth
@ 2013-09-30 17:32 ` Shawn Wilson
2013-09-30 17:35 ` Shawn Wilson
0 siblings, 1 reply; 6+ messages in thread
From: Shawn Wilson @ 2013-09-30 17:32 UTC (permalink / raw)
To: jack seth, netfilter@vger.kernel.org
Do you want to respond with ACK, FIN, or RST?
jack seth <bird_112@hotmail.com> wrote:
>Ok, if you have an 'accept' rule for a service that is not currently
>running, is it possible to have iptables to simply not respond instead
>of reporting the port as 'closed'? During a port scan at grc.com, if
>the router doesn't reply the port will be reported as 'stealth'.
> --
>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: Getting iptables not to reply
2013-09-30 17:32 ` Shawn Wilson
@ 2013-09-30 17:35 ` Shawn Wilson
2013-09-30 18:48 ` Tom van Leeuwen
0 siblings, 1 reply; 6+ messages in thread
From: Shawn Wilson @ 2013-09-30 17:35 UTC (permalink / raw)
To: jack seth, netfilter@vger.kernel.org
Err should've been FIN, SYN, or RST
Shawn Wilson <ag4ve.us@gmail.com> wrote:
>Do you want to respond with ACK, FIN, or RST?
>
>jack seth <bird_112@hotmail.com> wrote:
>>Ok, if you have an 'accept' rule for a service that is not currently
>>running, is it possible to have iptables to simply not respond instead
>>of reporting the port as 'closed'? During a port scan at grc.com, if
>>the router doesn't reply the port will be reported as 'stealth'.
>
>> --
>>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: Getting iptables not to reply
2013-09-30 17:35 ` Shawn Wilson
@ 2013-09-30 18:48 ` Tom van Leeuwen
2013-09-30 18:58 ` Tom van Leeuwen
0 siblings, 1 reply; 6+ messages in thread
From: Tom van Leeuwen @ 2013-09-30 18:48 UTC (permalink / raw)
To: Shawn Wilson, jack seth, netfilter@vger.kernel.org
Hi,
It seems Jack does not want any response...
So what happens when you hit a machine that has a port closed? Well:
this happens (telnet 127.0.0.30 443):
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
20:42:07.706751 IP 127.0.0.1.34056 > 127.0.0.30.443: Flags [S], seq
2590507944, win 43690, options [mss 65495,sackOK,TS val 3717641 ecr
0,nop,wscale 7], length 0
20:42:07.706778 IP 127.0.0.30.443 > 127.0.0.1.34056: Flags [R.], seq 0,
ack 2590507945, win 0, length 0
In response to my TCP SYN packet on loopback ip 127.0.0.30:443, which
does not have a service running, you see the kernel respond with a TCP RST.
Jack: You're talking about a router. Is the router being hit here on a
closed port, or is some machine behind the router being hit on a closed
port?
Only option I see, which really sucks and __I DO_NOT_RECOMMEND_THIS__
because it may also DROP legitimate RST packets when the service
actually wants to send it:
iptables -I OUTPUT -p tcp -s 127.0.0.30 --sport 443 --tcp-flags RST RST
-j DROP
I'm interested in a more clean solution though!
Regards,
Tom van Leeuwen
On 09/30/2013 07:35 PM, Shawn Wilson wrote:
> Err should've been FIN, SYN, or RST
>
> Shawn Wilson <ag4ve.us@gmail.com> wrote:
>> Do you want to respond with ACK, FIN, or RST?
>>
>> jack seth <bird_112@hotmail.com> wrote:
>>> Ok, if you have an 'accept' rule for a service that is not currently
>>> running, is it possible to have iptables to simply not respond instead
>>> of reporting the port as 'closed'? During a port scan at grc.com, if
>>> the router doesn't reply the port will be reported as 'stealth'.
>>> --
>>> 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
> --
> 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: Getting iptables not to reply
2013-09-30 18:48 ` Tom van Leeuwen
@ 2013-09-30 18:58 ` Tom van Leeuwen
2013-09-30 23:56 ` Shawn Wilson
0 siblings, 1 reply; 6+ messages in thread
From: Tom van Leeuwen @ 2013-09-30 18:58 UTC (permalink / raw)
To: Shawn Wilson, jack seth, netfilter@vger.kernel.org
Just FYI, the RST sending code is normal behaviour (RFC793):
Quote:
If the state is CLOSED (i.e., TCB does not exist) then
all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response.
On 09/30/2013 08:48 PM, Tom van Leeuwen wrote:
> Hi,
>
> It seems Jack does not want any response...
> So what happens when you hit a machine that has a port closed? Well:
> this happens (telnet 127.0.0.30 443):
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
> 20:42:07.706751 IP 127.0.0.1.34056 > 127.0.0.30.443: Flags [S], seq
> 2590507944, win 43690, options [mss 65495,sackOK,TS val 3717641 ecr
> 0,nop,wscale 7], length 0
> 20:42:07.706778 IP 127.0.0.30.443 > 127.0.0.1.34056: Flags [R.], seq 0,
> ack 2590507945, win 0, length 0
>
> In response to my TCP SYN packet on loopback ip 127.0.0.30:443, which
> does not have a service running, you see the kernel respond with a TCP RST.
>
> Jack: You're talking about a router. Is the router being hit here on a
> closed port, or is some machine behind the router being hit on a closed
> port?
>
> Only option I see, which really sucks and __I DO_NOT_RECOMMEND_THIS__
> because it may also DROP legitimate RST packets when the service
> actually wants to send it:
> iptables -I OUTPUT -p tcp -s 127.0.0.30 --sport 443 --tcp-flags RST RST
> -j DROP
>
> I'm interested in a more clean solution though!
>
> Regards,
> Tom van Leeuwen
>
> On 09/30/2013 07:35 PM, Shawn Wilson wrote:
>> Err should've been FIN, SYN, or RST
>>
>> Shawn Wilson <ag4ve.us@gmail.com> wrote:
>>> Do you want to respond with ACK, FIN, or RST?
>>>
>>> jack seth <bird_112@hotmail.com> wrote:
>>>> Ok, if you have an 'accept' rule for a service that is not currently
>>>> running, is it possible to have iptables to simply not respond instead
>>>> of reporting the port as 'closed'? During a port scan at grc.com, if
>>>> the router doesn't reply the port will be reported as 'stealth'.
>>>> --
>>>> 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
>> --
>> 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
> --
> 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: Getting iptables not to reply
2013-09-30 18:58 ` Tom van Leeuwen
@ 2013-09-30 23:56 ` Shawn Wilson
0 siblings, 0 replies; 6+ messages in thread
From: Shawn Wilson @ 2013-09-30 23:56 UTC (permalink / raw)
To: Tom van Leeuwen, jack seth, netfilter@vger.kernel.org
If your output policy is default drop (ie, allow only what you use - you find interresting stuff like the Pandora music service doing weird stuff which is cool anyway), you get that behavior. Since we're dealing with output, you can only allow users or a white list of apps. I'd log the hell out of stuff if you're going to do this either way.
Tom van Leeuwen <tom.van.leeuwen@saasplaza.com> wrote:
>Just FYI, the RST sending code is normal behaviour (RFC793):
>Quote:
>If the state is CLOSED (i.e., TCB does not exist) then
>all data in the incoming segment is discarded. An incoming
>segment containing a RST is discarded. An incoming segment not
>containing a RST causes a RST to be sent in response.
>
>On 09/30/2013 08:48 PM, Tom van Leeuwen wrote:
>> Hi,
>>
>> It seems Jack does not want any response...
>> So what happens when you hit a machine that has a port closed? Well:
>> this happens (telnet 127.0.0.30 443):
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>decode
>> listening on lo, link-type EN10MB (Ethernet), capture size 65535
>bytes
>> 20:42:07.706751 IP 127.0.0.1.34056 > 127.0.0.30.443: Flags [S], seq
>> 2590507944, win 43690, options [mss 65495,sackOK,TS val 3717641 ecr
>> 0,nop,wscale 7], length 0
>> 20:42:07.706778 IP 127.0.0.30.443 > 127.0.0.1.34056: Flags [R.], seq
>0,
>> ack 2590507945, win 0, length 0
>>
>> In response to my TCP SYN packet on loopback ip 127.0.0.30:443, which
>> does not have a service running, you see the kernel respond with a
>TCP RST.
>>
>> Jack: You're talking about a router. Is the router being hit here on
>a
>> closed port, or is some machine behind the router being hit on a
>closed
>> port?
>>
>> Only option I see, which really sucks and __I DO_NOT_RECOMMEND_THIS__
>> because it may also DROP legitimate RST packets when the service
>> actually wants to send it:
>> iptables -I OUTPUT -p tcp -s 127.0.0.30 --sport 443 --tcp-flags RST
>RST
>> -j DROP
>>
>> I'm interested in a more clean solution though!
>>
>> Regards,
>> Tom van Leeuwen
>>
>> On 09/30/2013 07:35 PM, Shawn Wilson wrote:
>>> Err should've been FIN, SYN, or RST
>>>
>>> Shawn Wilson <ag4ve.us@gmail.com> wrote:
>>>> Do you want to respond with ACK, FIN, or RST?
>>>>
>>>> jack seth <bird_112@hotmail.com> wrote:
>>>>> Ok, if you have an 'accept' rule for a service that is not
>currently
>>>>> running, is it possible to have iptables to simply not respond
>instead
>>>>> of reporting the port as 'closed'? During a port scan at grc.com,
>if
>>>>> the router doesn't reply the port will be reported as 'stealth'.
>
>>>>> --
>>>>> 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
>>> --
>>> 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
>> --
>> 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:[~2013-09-30 23:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-30 15:58 Getting iptables not to reply jack seth
2013-09-30 17:32 ` Shawn Wilson
2013-09-30 17:35 ` Shawn Wilson
2013-09-30 18:48 ` Tom van Leeuwen
2013-09-30 18:58 ` Tom van Leeuwen
2013-09-30 23:56 ` Shawn Wilson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox