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@xxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: >>>> Do you want to respond with ACK, FIN, or RST? >>>> >>>> jack seth <bird_112@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx >>>>> 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@xxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
