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 |