top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Getting iptables not to reply

+1 vote
654 views

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'.

posted Sep 30, 2013 by Abhay Kulkarni

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
Do you want to respond with ACK, FIN, or RST?
commented Sep 30, 2013 by Sanketi Garg
Err should've been FIN, SYN, or RST
commented Oct 2, 2013 by anonymous

1 Answer

+1 vote

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  **********, 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 **********, 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.

Abhay: 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
answer Sep 30, 2013 by Ahmed Patel
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.
commented Sep 30, 2013 by Ahmed Patel
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.
commented Oct 1, 2013 by Anderson
Similar Questions
+1 vote
IPtables: if you reboot the machine configurations are not loaded?

I have a problem with iptables on CentOS 6.2.

I configured:

chkconfig iptables on
and the file /etc/sysconfig/iptables

If you reboot the machine configurations are not loaded. iptables-L gives me the default configurations (not assigned) if I (a machine booted): service iptables start then then it works. How can I fix?

0 votes
IPTables not flushing on Fedora?

I'm playing around with iptables and have inserted a few new rules. Now, I want to flush them all so I use

iptables -F

Then, I restart the firewall with

service iptables restart

and everything looks like it's restarting alright. But when I list the rules using

iptables -L

I get a list of rules THAT INCLUDE all of the rules I've defined before the flush! Am I reading this wrong or is something weird with my iptables?

+1 vote
iptables DNAT reply packets with RST flag are sent using private ip?

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+2 votes
how to replace the next iptables rule with nft?

Can someone help on how to replace the next iptables rule with nft:

iptables -t raw -A PREROUTING -i eth0 -j CT --notrack

Is this possible with nft or not?

0 votes
iptables with logging vs denyhosts

I have been using denyhosts for almost a year. To date I have only prevented one person logging in and that is ME ( I used the wrong login name).
Also, I know of no successful break-ins.

My iptables is as follows:

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N block
-A INPUT -j block
-A FORWARD -j block
-A block -i wifi_card -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_external -p tcp -m tcp --dport 12123 -j ACCEPT
-A block -i Nic_enternal -j ACCEPT
-A block -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A block -i lo -m conntrack --ctstate NEW -j ACCEPT
-A block -j DROP

First, I think that the above will keep the bad guys out, Is that a true statement?

Sencondly, I have added a LOG rule just above the DROP rule and I have been monitoring it for about 1 1/2 weeks. As each entry is logged I have been adding it to /etc/hosts.deny. Currently there are 4318 ip adresses in the file and the number of packets that have been logged is 51592.

Denyhosts is for stopping ssh attempts and nothing else as I understand it.

Having over 4300 lines in /etc/hosts.deny causes almost no delay in logging in remotely.

Am I being to paranoid about keeping the bad guys out or is the iptable above completely adequate?

I would very much like to here your opinion on this,

...