4

Is it possible to disable either the tx or the rx in a NIC? I am setting up a network monitoring machine and I would like to be sure that no packet will be introduced by this machine at the network.

One approach would be use some sort of netfilter feature to block all out coming packet from that interface. But this add extra work to the server since it will need to filter all packets that may leave the interface.

Vinicius Tinti
  • 325
  • 4
  • 9
  • If the machine can't transmit at all how will it acknowledge TCP packets? I'd also expect neither the machine's interface or switch will actually come up without correct wiring. – Keith Stokes Dec 12 '13 at 13:54

4 Answers4

5

The easiest way to do this is to use a custom-built cable with doesn't have the TX pin connected. Cables are trivial to make, you just have to follow the correct color pattern. You'll also have to make sure you put the TX-disabled connector in the computer and not the switch, but that's easy to fix if you get it wrong. :)

John
  • 9,070
  • 1
  • 29
  • 34
  • I think that would be a good way but I was looking for a software solution. Anyway if I did not find one I would go with it. – Vinicius Tinti Dec 12 '13 at 13:28
  • Any software solution you come up with will require some sort of overhead on the server. The easiest software solution would be `iptables -F OUTPUT; iptables -P OUTPUT DROP`, but as you mentioned, even that imposes some overhead even if it only to "drop all outgoing packets". – John Dec 12 '13 at 13:32
0

I am setting up a network monitoring machine and I would like to be sure that no packet will be introduced by this machine at the network.

That part doesn't make much sense.

And then how do you plan on using the system itself? Even a network monitoring system would need access to send traffic. Email Notifications, SMS notifications, ping tests outbound, etc. It can't operate effectively if all it does is receive.

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • If you assume a separate "management" or "monitoring" network (which I did since I'm in an environment like that now), it makes perfect sense. Dual-homed monitoring system that reports only on the "protected" back-end monitoring/management network. – John Dec 12 '13 at 14:12
  • Sorry, stil don't get it. You can have a separate monitoring/mgmt VLAN with dual-homed systems, sure...but why would you want to prevent either nic from TX? One nic should be monitoring using ping and other methods to check for issues (as well as receiving traps), the other should be sending notifications. If you'll explain it, maybe I'll get it. I just don't see it yet. – TheCleaner Dec 12 '13 at 14:18
  • You prevent the NIC that's on the mirrored port from TX. The NIC on the management port can transmit/receive as usual. I'm assuming the box to not be actively monitoring (e.g. via ping), but only to be sniffing traffic (promiscuous mode). – John Dec 12 '13 at 14:41
  • OK, to me "port mirroring" isn't the same as a "network monitoring system. Maybe that's the difference in how we are seeing the question. I'm seeing "network monitoring system" as something like Nagios/WUG/Zenoss/etc. Not just a mirrored port doing traffic sniffing. A mirrored port shouldn't allow received/TX traffic from that NIC anyway...it should only be replicating the traffic from the original port. – TheCleaner Dec 12 '13 at 14:46
  • To me, using port mirroring to sniff traffic is a part of a network monitoring system - the other part is the Nagios/Zenoss bit. – John Dec 12 '13 at 14:50
  • @TheCleaner I have two NIC as John said. One of them is connected to a vlan trunk. The other one is used to remote access. Sorry if I have used a bad term for network monitoring I think "sniffing" would be more clear. – Vinicius Tinti Dec 12 '13 at 15:45
  • I don't have time to check, but I'm pretty sure my statement `A mirrored port shouldn't allow received/TX traffic from that NIC anyway...it should only be replicating the traffic from the original port.` is correct. Not to beat a dead horse...John's answer is certainly valid. – TheCleaner Dec 12 '13 at 16:11
0

If running Linux you can use iptable to block all traffic:

iptable -F iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP

Reno
  • 11
  • 1
0

[The question is a bit old but I think none of the responses captured the full answer.]

Assumptions

  1. The scenario is as John described: a network sniffing system with:

    • one NIC for remote management (which therefore must receive and transmit)
    • a second NIC which will receive mirrored packets from the network switch (but which must not transmit)

  2. The management interface is eth0 and the sniffing interface is eth1.

Approach

  1. I agree that the best solution includes a modified cable, if your switch supports it. In addition to ACLs on the network switch (see below), this cable is a line of defense against configuration errors which inadvertently leak information via the sniffing interface.
  2. The iptables commands below don't protect you against attacks via the monitored interface, even with a modified cable. Be certain that your sniffing system:
    • doesn't have any services (like ssh) listening on the sniffing interface
    • has IP forwarding disabled in the kernel (via /proc/sys/net/ipv4/ip_forward or /etc/sysctl.conf for preference)
    • uses unique passwords
    • isn't trusted by any other system
    • is kept up to date with security patches
    • has inbound (i.e. from the sniffing system to the switch) ACLs on the network switch port for the management interface, to control what the sniffing system can emit
    • has inbound ACLs on the network switch port for the sniffing interface, to drop all packets.

Commands

For iptables under Linux:

iptables --insert OUTPUT 1 --out-interface eth1 --jump DROP
iptables --flush FORWARD
iptables --append FORWARD --jump DROP
iptables --policy FORWARD DROP

This first line inserts a rule at the start of the output rules table, and shouldn't affect other traffic.

YMMV because I haven't tested ;-).

--klodefactor

klodefactor
  • 1