Gentoo Archives: gentoo-user

From: James <wireless@×××××××××××.com>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: Stealth Ethernet testing
Date: Sat, 22 Oct 2005 19:22:37
Message-Id: loom.20051022T191025-741@post.gmane.org
In Reply to: Re: [gentoo-user] Stealth Ethernet testing by Hans-Werner Hilse
1 Hans-Werner Hilse <hilse <at> web.de> writes:
2
3 >
4 > Hi,
5 >
6 > On Fri, 21 Oct 2005 19:19:15 +0000 (UTC)
7 > James <wireless <at> tampabay.rr.com> wrote:
8 >
9 > > Well, after much ado, it seems quite easy (trivial) to hide
10 >> an ethernet interface, while being able to collect reems
11 >> of local ethernet traffic based data, from both snort and ethereal.
12
13 > Yep, it's up and doesn't have an IP. If this is sufficient for you,
14 > fine then.
15
16 Well, let me see how much *quieter* I can make the interface. I do
17 need to make the ethernet interface 100% undetectable.
18
19 > > On any system, 'ping 0.0.0.0' receives responses from the local
20 > > interface.
21
22 > No, if you specify an interface for those packets, it most probably
23 > won't receive anything. But that's nitpicking here...
24
25 Hmm you should try this and ping your local ip (before setting it
26 to 0.0.0.0). It has to be the local host, as the latencies for any
27 other hosts on the switch/hub are almost an order of magnitude
28 higher. Futhermore, you can disconnect any system from it's ethernet
29 cable, and 'ping 0.0.0.0' is the same thing and 'ping localhost'
30 and 'ping 127.0.0.1', while the interface is disconnected.
31
32 snort -dvi eth0 still runs great and the eth seems undetectable
33
34
35 > > What I need is for folks to test and verify that an ethernet
36 > > interface setup this way, is indeed invisible (undetectable)
37 > > by other systems.
38
39 > It surely isn't. It's up, listening at least to broadcasts and
40 > multicasts (well, it's written uppercase in the ipconfig output).
41
42 Hmm, none of the commands I tried with arp, arping or hping
43 discovered the passive ethernet interface configured to 0.0.0.0
44 on the same flat hub....
45
46 However, there is one thing I should point out. NONE of the
47 systems have any entry in the their hostname file except their
48 own name, nor is DNS running on this test network.
49 Only IP addresses, ethernet with MACs and not networked services
50 so the arp tables are empty intil explicit communications occur.
51 No NFS, no samba; natta.
52
53 It's a test network for machines and everything is
54 minimize. ON the gentoo systems there is no domain name,
55 they only query DNS servers as needed (if the machines
56 only access another machine via IP, then DNS resolution
57 is not necessary, and network chatter has been minimized.
58
59
60 So if you have syntax that will discover any of the 'listen
61 only interfaces' please send me a specific example. Nothing
62 I have tried with ping, arping, arp, arpscan, arpwatch,or hping*
63 discovers these ethernet interfaces. I'm not saying they are
64 100% stealth, but, I have not found a method to discover the
65 interfaces, for this, minimize network. Even the gentoo
66 system configured to 0.0.0.0 is not discoverable, as of yet.
67
68 > > If you find this is not true, please tell me what you did and
69 > > what tool/syntax you used to discover/detect a system with an
70 > > ethernet interface set up this way....
71
72 > emerge hping2, emerge arping. And then play a little bit. Note that
73 > ethernet frames don't rely on IPs to get to their targets. In the above
74 > described situation, I would try to send a bunch of different ethernet
75 > frames to that machine and see what happenes. If I were you, I would
76 > dedicate another machine for the testing stage that sniffs if the
77 > machine answers anything. "ping" isn't really the tool of choice here.
78
79 yes, as you have suggested, but the steath systems
80 (ifconfig eth0 inet 0.0.0.0) are still not discoverable. If you disagree
81 (and hopefully you do) please send me explicit syntax.
82
83 > If you really don't want to chose a hardware based solution and go the
84 > software way, you should carefully inspect /proc/sys/net/... and have a
85 > read in linux docs how to chose sysctls for not letting linux itself
86 > spit out packages.
87
88 OK, after I fully explore the possibilities with the aforementioned
89 tools, I'll look into this. A systmems ability to resist responses
90 (icmp, mac scans, etc) is really quite facinating and I'm sure also
91 related to kernel configuration and low level ethernet drivers.
92
93 > But using this way, it is scientifically impossible (well, nearly) to
94 > 100% negate the theory that a package might get through. I really
95 > recommend the already mentioned way, cutting the Tx wires. After all,
96 > this is simple and you can be sure that you didn't forget anything.
97
98 Agreed. However, before I build a custom piece of hardware/cable that
99 open-circuits the transmit line from the desire stealth interface,
100 I need to fully characterize things available in software, and from which
101 tools these software/config tricks hid interfaces. Open-circuiting
102 the stealth interface is not always an option, so fully characterizing
103 the efforts to minimize responses of the pseudo-stealth interface,
104 via configs, software, kernel and low level drivers, will go a long
105 way to approaching stealth behavior of an ethernet interaface. If
106 only a few tools/hacks can discover the existence, then I can make
107 prepartions in the firewall and other upstream routing/interfaces
108 so as to prevent or alert such machinations.
109
110
111 Send me some explicit syntax scans with arpping, hping* ro whatever if
112 you can so I can verify that these specific scans/searchs/broadcast
113 successfully solict a response from stealth interface.
114
115 Thanks,
116
117 James
118
119
120
121
122 --
123 gentoo-user@g.o mailing list