Hi, On Fri, 21 Oct 2005 19:19:15 +0000 (UTC) James <[EMAIL PROTECTED]> wrote:
> Well, after much ado, it seems quite easy (trivial) to hide an ethernet > interface, while being able to collect reems of local ethernet traffic > based data, from both snort and ethereal. No, it's not that easy - depending on your requirements on the "hiding". > Here's the normal ethernet interace on a portable: > /sbin/ifconfig -a > eth0 Link encap:Ethernet HWaddr 00:90:F5:0D:30:0E > inet addr:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > issued: > > route delete default > ifconfig eth0 inet 0.0.0.0 > > and voila: > /sbin/infconif -a > eth0 Link encap:Ethernet HWaddr 00:90:F5:0D:30:0E > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Yep, it's up and doesn't have an IP. If this is sufficient for you, fine then. > On any system, 'ping 0.0.0.0' receives responses from the local > interface. No, if you specify an interface for those packets, it most probably won't receive anything. But that's nitpicking here... > What I need is for folks to test and verify that an ethernet > interface setup this way, is indeed invisible (undetectable) > by other systems. It surely isn't. It's up, listening at least to broadcasts and multicasts (well, it's written uppercase in the ipconfig output). > If you find this is not true, please tell me what you did and > what tool/syntax you used to discover/detect a system with an > ethernet interface set up this way.... emerge hping2, emerge arping. And then play a little bit. Note that ethernet frames don't rely on IPs to get to their targets. In the above described situation, I would try to send a bunch of different ethernet frames to that machine and see what happenes. If I were you, I would dedicate another machine for the testing stage that sniffs if the machine answers anything. "ping" isn't really the tool of choice here. If you really don't want to chose a hardware based solution and go the software way, you should carefully inspect /proc/sys/net/... and have a read in linux docs how to chose sysctls for not letting linux itself spit out packages. But using this way, it is scientifically impossible (well, nearly) to 100% negate the theory that a package might get through. I really recommend the already mentioned way, cutting the Tx wires. After all, this is simple and you can be sure that you didn't forget anything. -hwh -- [email protected] mailing list
