Security risk associated with a NIC's promiscuous mode?
Is there any security risk associated with a NIC's promiscuous mode while running tcpdump and/or arpwatch? Thanks, John -- John Conover, [EMAIL PROTECTED], http://www.johncon.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security risk associated with a NIC's promiscuous mode?
John Conover wrote: Is there any security risk associated with a NIC's promiscuous mode while running tcpdump and/or arpwatch? A mild one. For example, I believe there was recently a security bug in tcpdump's string handling which could be exploited by tcpdump seeing a maliciously-crafted packet. Running the NIC in promisc mode means that packet just has to go by, rather than being sent specificly to the machine running the sniffer... In other words, it's not a great idea to run a sniffer on your most important fileserver or whatever, rather than an isolated laptop or other test system. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security risk associated with a NIC's promiscuous mode?
John Conover wrote: [ ... ] A mild one. For example, I believe there was recently a security bug in tcpdump's string handling which could be exploited by tcpdump seeing a maliciously-crafted packet. Running the NIC in promisc mode means that packet just has to go by, rather than being sent specificly to the machine running the sniffer... In other words, it's not a great idea to run a sniffer on your most important fileserver or whatever, rather than an isolated laptop or other test system. Thanks, Chuck; That's the kind of stuff I was concerned about. Sure, you're welcome. The issue is much like building out (or writing code for) a firewall or router or IDS. Anything which gets exposed to untrusted traffic ought to be considered at risk, and the software ought to be written with extreme care to not trust the data-- don't trust an IP packet to really tell you what size it is (you may not have sniffed all of that data, depending on how you configured PCAP or BPF), don't trust Content-length headers in email or HTTP traffic to be valid without double-checking (trying to memcpy -1 bytes makes programs unhappy [1]), don't trust headers to be of reasonable size, etc. If at all possible, anything running a sniffer ought to be dedicated for the purpose, or only used for brief periods by a human sysadmin (ie, not running forever under the incurious gaze of a daemon). If possible and convenient, the rest of your network should not trust or depend on your sniffer box at all. -- -Chuck [1]: On the other hand, being able to drop -1 gold pieces in Hack could be considered a feature, at least to most people. :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security risk associated with a NIC's promiscuous mode?
On Fri, 7 Oct 2005, John Conover wrote: Is there any security risk associated with a NIC's promiscuous mode IF you're on a switched LAN, you'll only see traffic destined for MACs that the switched has learned on your port (your NICs), plus multi/broadcast. Unless you configure switch mirroring or trunking. ~BAS while running tcpdump and/or arpwatch? Thanks, John -- John Conover, [EMAIL PROTECTED], http://www.johncon.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Security risk associated with a NIC's promiscuous mode?
On 10/7/05, Chuck Swiger [EMAIL PROTECTED] wrote: A mild one. For example, I believe there was recently a security bug in tcpdump's string handling which could be exploited by tcpdump seeing a maliciously-crafted packet. Running the NIC in promisc mode means that packet just has to go by, rather than being sent specificly to the machine running the sniffer... In other words, it's not a great idea to run a sniffer on your most important fileserver or whatever, rather than an isolated laptop or other test system. You can also change the ownership of the bpf0 entry in /dev to something other than root, and run tcpdump as that user. Obviously you would want to secure that account so it can only be accessed by you, and you may even want to change ownership to that user only when you want to sniff, changing it back to root when done. In any case, this would mitigate the risk in case a tcpdump/libpcap vulnerability is discovered. I wouldn't do this if it was for a daemon or a cron, though, since they would perform dumps at specific (IE predictable) times of day. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
