* 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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.