wireless " intruder "

[haaber]

Hello, I have a intriguing problem, partially qubes-related. I have a
"intruder" in my wifi network. I have no idea how to physically localise
that offensive antenna, but that is not a qubes subject (if you have any
ideas, they are welcome!). Of course I can just change the SSID and pwd,
but this is not the whole point:

When I portscan the offensive object using nmap (all ports are
filtered.) it counter-fires and kills off my mirage-firewall! That is
fancy. The network structure is

sys-net - mirage-firewall -qubes-firewall - dispVM

and nmap runs in dispVM. I am quite surprised and willing to "play" a
bit with this enemy, but I would need some help. In particular: How can
I log packets while scannning? Is there a way to find out how/why the
mirage firewall (0.7) dies? That suggests a weakness which is relevant
to many of us! Cheers, Bernhard

[David Hobach]

Your firewalls might interfere with the nmap replies and thus everything is shown as filtered.

Also the above network setup looks weird (why two firewalls in a chain?).

Maybe nmap causes the mirage death. That wouldn't be a good job by mirage though and should be reported as bug to the dev.

Anyway I'd recommend doing nmap directly from sys-net or from a VM that is directly connected to sys-net.

[haaber]

On 1/3/21 1:04 PM, David Hobach wrote:
> On 1/3/21 12:43 PM, haaber wrote:
>> Hello, I have a intriguing problem, partially qubes-related. I have a
>> "intruder" in my wifi network. I have no idea how to physically localise
>> that offensive antenna, but that is not a qubes subject (if you have any
>> ideas, they are welcome!). Of course I can just change the SSID and pwd,
>> but this is not the whole point:
>>
>> When I portscan the offensive object using nmap (all ports are
>> filtered.) it counter-fires and kills off my mirage-firewall!  That is
>> fancy. The network structure is
>>
>> sys-net - mirage-firewall -qubes-firewall - dispVM
>>
>> and nmap runs in dispVM. I am quite surprised and willing to "play" a
>> bit with this enemy, but I would need some help. In particular: How can
>> I log packets while scannning? Is there a way to find out how/why the
>> mirage firewall (0.7) dies? That suggests a weakness which is relevant
>> to many of us!    Cheers,  Bernhard
>
> Your firewalls might interfere with the nmap replies and thus everything
> is shown as filtered.

I did it in sys-net but they remain "filtered". That is not a
firewall-artefact.

> Maybe nmap causes the mirage death. That wouldn't be a good job by
> mirage though and should be reported as bug to the dev.

I thought that, too. How would verify it is really nmap? As a test, I
scanned two phones in my wifi (in the same dispVM), without any trouble,
using the same command. I re-scanned the offensive object, 181 seconds
later mirage is dead again. Fascinating.



P.S: I will see if I can use my phone as AP honypot using the same SSID
& pwd to find that antenna using signal strength (the idea is that I can
move it), but usually that is very hard, due to natural "shadows" and
reflections.

[David Hobach]

>> On 1/3/21 12:43 PM, haaber wrote:
>>> In particular: How can I log packets while scannning?

If mirage died due to incoming packets, you should see the offensive payload with e.g. wireshark.
The attack couldn't be on a lower layer as that is handled by your wifi driver in sys-net only.

In companies triangulation tends to be used to find wifi attackers IIRC. So you're likely on the right path.

[Ulrich Windl]

On 1/3/21 2:24 PM, haaber wrote:
...

>> Maybe nmap causes the mirage death. That wouldn't be a good job by
>> mirage though and should be reported as bug to the dev.
> I thought that, too. How would verify it is really nmap? As a test, I
> scanned two phones in my wifi (in the same dispVM), without any trouble,
> using the same command. I re-scanned the offensive object, 181 seconds
> later mirage is dead again. Fascinating.

Are there logs (the famous "last words")?

...

[haaber]

(my) mirage does not log. It has a fixed size of 32 MB, not much space
for logging .. and dom0 has no useful info on that incident.

[Thomas Leonard]

It should log to the console, which is recorded by dom0 in guest-mirage-firewall.log (you can also get to it via qubes-manager IIRC).

Most likely it ran out of memory adding NAT entries for all the ports. Is this the current release version (using mini-os and PV) or the Git version (using solo5 and PVH)? The solo5 version has some problems with memory at the moment (https://github.com/mirage/qubes-mirage-firewall/issues/120 - seems to be reporting inaccurate heap stats).