4

I need to set up a server (preferably RedHat/CentOS/Fedora but the Debian family would work out as well) with no services available on a given interface.

I cannot use iptables (which would be the simplest solution).

I could check which ones are enabled and either disable them by hand or force a bind to another interface but there is a risk that after an update/upgrade/additional soft installation the changes would be reverted or an extra service deployed.

Is there a way to configure a network interface so that it does not allow any service to bind to it, so that there is no port listening on it?

8
  • 1
    Sure: configure it down. But I suspect that's not what you mean, is it? You want the interface up and operating, but without anyone allowed to bind to it. iptables would be much the easiest way to do this; why can you not use it?
    – MadHatter
    Nov 18, 2013 at 12:38
  • @MadHatter: right, I want it to be up :) One of the main reasons is that we have a scanner which will have issues with iptables (and with firewalls in general).
    – WoJ
    Nov 18, 2013 at 12:40
  • A scanner? Do you mean a device that makes digital images of printed matter? Or a network scanner? If the latter, what sort of issues do you think it's likely to have?
    – MadHatter
    Nov 18, 2013 at 12:43
  • A network scanner. We are likely to face drops from the firewall if we go for an aggressive scan (following a discussion with one of the developers) so I would prefer to go for an iptables-less setup before diving into troubleshooting, should some issues arise (we already probably had a few of these). I am also curious about the existence of such setting :)
    – WoJ
    Nov 18, 2013 at 12:48
  • I don't have any idea what you mean by "we are likely to face drops from the firewall if we go for an aggressive scan". How do you think an iptables firewall set to send TCP resets to NEW inbound connections will differ from simply having no listening daemon, and the kernel sending TCP resets?
    – MadHatter
    Nov 18, 2013 at 12:51

2 Answers 2

0

I think I finally understand the problem. Main misunderstanding of me (and I suppose some others) was I suggested that a scanner is somewhere outside.

If you plan to use this host as a scanner than iptables may be really overwhelmed.

If so, you need some setup protecting host applications but not creating session records for the scanner traffic.

The solution is simple: create a container (LXC or OpenVZ) and hide your scanner staff there. Use a bridged connection setup of your container to the real network.

Thus your scanner will have a dedicated IP address and host applications will never bind It. In basic setup container's traffic will skip iptables.

If you want to additionally protect the container, turn on iptable lookup for the bridge (net.bridge.bridge-nf-call-iptables = 1 in sysctl.conf) and add the rules as follow:

-I FORWARD -p ip -s <rogue_network> -d <scanner_ip>    -j ACCEPT
-I FORWARD -p ip -s <scanner_ip>    -d <rogue_network> -j ACCEPT
-I FORWARD -j REJECT --reject-with icmp-host-unreachable

UPD:
Previous is not working properly - forget to disable connection tracking:

-t raw -I PREROUTING -p ip -s <rogue_network> -d <scanner_ip>    -j NOTRACK
-t raw -I PREROUTING -p ip -s <scanner_ip>    -d <rogue_network> -j NOTRACK
-t raw -I PREROUTING -j REJECT --reject-with icmp-host-unreachable
2
  • This is a very interesting solution. I will look closely look at that. Thanks!
    – WoJ
    Nov 21, 2013 at 10:48
  • @WoJ You are wellcome. Moving "solution check" was very anticipatory. Not yet sure, it is really working. As well as there may be more other solutions around stateless firewall setup with disabled connection tracking.
    – Veniamin
    Nov 21, 2013 at 15:20
1

I don't know of any way to tell the kernel not to allow binding to a given network interface. You say that you'll consider iptables, so for my money having the line

iptables -I INPUT 1 -p tcp -m state --state NEW -j REJECT --reject-with tcp-reset

will have the same effect (for daemons binding to TCP ports) as simply not having a daemon bound; in both cases a TCP reset will be issued. Similarly, the line

iptables -I INPUT 2 -p udp -m state --state NEW -j REJECT --reject-with icmp-port-unreachable

will do the same thing for new connections to UDP ports as having no listener bound: the kernel will emit an ICMP port-unreachable packet in either case.

This is an extremely simple iptables setup, and is unlikely to be overwhelmed by any amount of traffic that you can put through that NIC.

2
  • Since there are apparently no mechanisms to deny the binding I will go for iptables :(
    – WoJ
    Nov 20, 2013 at 8:02
  • @WoJ You really do not have reasons to worry about. Iptables can be overwhelmed if connections are allowed, tracked and recorded in the connection table. A setup such this does not do It. So, overhead is approximately as no iptables at all.
    – Veniamin
    Nov 20, 2013 at 8:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .