Cyber Stalking and IpFire

[nickh (Nick Howitt)]

But this not so effective unless you hijack DNS lookups and force them to use PiHole. Otherwise, if they configure their PC/Device to use explicit DNS servers rather than those handed out by DCHP, they can completely bypass your DNS servers. With your set up, you need to hijack any tcp/udp port 53 traffic not coming from PiHole and send it to PiHole. You need to consider what to do with DNS over TLS (block it?). Then there are the various DNS over HTTPS (DoH) services (various browsers and anti-virus programs for a start) which need to be blocked. Firefox has a canary domain you can use for that purpose… Perhaps also block UDP:443. And so on. It is not so straightforward.

[trish]

@nickh

you need to hijack any tcp/udp port 53 traffic not coming from PiHole and send it to PiHole. You need to consider what to do with DNS over TLS (block it?).

You made a very good point,

@trish

To improve your network awareness
You need to block outgoing DNS, and force clients to use IPFIRE DNS

This guide would only forward outgoing traffic to port 53 to IPfire unbound,

I am not sure how to setup firewall rules to force traffic to port 53 and to port 853 back to Pihole.

[bbitsch (Bernhard Bitsch)]

@trish

I am not sure how to setup firewall rules to force traffic to port 53 and to port 853 back to Pihole.

This task is called port forwarding with source=green

[nickh (Nick Howitt)]

The only thing is, with your description of your set up, you need to create an exclusion for traffic from PiHole or it will go round in circles.

[hvacguy (Shaun HVAC)]

No one is blocking DNS on IPfire they are redirecting DNS to IPFire.
A PC in your lan does not have to use IPFire’s DNS. It offers up DNS. But A PC user can change it to any DNS it wants.
Chrome browser may choose 8.8.8.8.
Firefox may use 1.1.1.1
This can stop that. By silently redirecting all DNS requests. Your own MITM attack.
This can be found in the wiki.

Force clients to use IPFire DNS Server - The IPFire Documentation

[nickh (Nick Howitt)]

For anything hijacked you may also need an SNAT rule so DNS traffic to PiHole from the Green LAN appears to come from Green0 and not the LAN IP. This is because otherwise packets get sent from a LAN device from to IPfire and get redirected to PiHole which is also on the green LAN. PiHole returns the packet directly to the LAN device which won’t like it as he sent his packet to Green0 and will only accept a return packet from where he sent it and not direct from PiHole.

[bbitsch (Bernhard Bitsch)]

Excellent finding.
One more reason to implement the RPZ mechanism of unbound. The functionality is similiar to PiHole.

[trish]

@bbitsch

@trish

I am not sure how to setup firewall rules to force traffic to port 53 and to port 853 back to Pihole.

This task is called port forwarding with source=green

OK, I wasn’t sure if the DNS queries would work using forwarding it, I don’t understand DNS well , especially DNSSEC

Here is an example of a port forwarding, @bbitsch would be kind enough to comment if this looks right?

To keep it simple:

IPFire Green IP address : 192.168.1.1
PIHOLE IP address:        192.168.1.33

If you use “service groups” just like I do, you can define the actual ports in the “Firewall groups” and Click on Service Groups

[trish]

Could you describe this in simple terms ?

Should the source IP be the same as PIHOLE ? e.g. 192.168.1.33

and SNAT Source IP : GREEN 192.168.1…1 ?

[nickh (Nick Howitt)]

I guess you are talking about the SNAT rule?

If so, source - Green LAN, Destination = PiHole, SNAT to Green0. If you want, limit your ports to your DNSNTP service group.

[trish]

Thank you for the suggestions,
Not sure what I messed up

I got this Error messages
Source and destination IP addresses are from the same subnet.

The rule looks like this:

Source: Standard Networks GREEN
NAT: Source NAT : GREEN
Destination: IP address of Pihole
Protocol : Preset Service Group DNS/NTP

[nickh (Nick Howitt)]

Ouch. I remember that. I had to get creative. The problem is that I can’t run IPF for the moment…

Try setting the source to the LAN subnet of Green.

Ultimately it is a bit of a over-restriction of the UI.

[nickh (Nick Howitt)]

I can’t see how to do it and there is nowhere to put a manual rule in the UI. I am wondering if it does it for you. Can you give the output to iptables -nvL -t nat?

[bbitsch (Bernhard Bitsch)]

Port forwarding is done with DNAT, I suppose.

[nickh (Nick Howitt)]

Yes. In this case I am pretty certain we require SNAT to successfully hijack the DNS. It can be done with a manual rule but it means using firewall-local - www.ipfire.org - firewall.local.

[bbitsch (Bernhard Bitsch)]

For the topic Pi-hole with IPFire see

Redirect all traffic from Green to PiHole

Furthermore : By using Pi-hole on eth green and blue, disturbs the LOG of Proxy at IPFire and you will not be able check every client communication and requested URL’s at IPFire Proxy-Logs . The LOG will show just the IP of Pi-hole as a client, that requested a domain . I cannot confirm this. Since yesterday I use the proxy for some clients and I can not observe something like this. IPFire is configured as follows: My configuration (Pi-Hole is in the green zone): # IPFire Domain Name Sys…

and

Pi-Hole and IPFire, which way round?

Hello, In the old forum (IPFire Community) somebody posted a dns_blocklist.sh that can consume Pi Hole lists (hosts formats) but is also capable to consume AdBlock lists. I have used it for many years and I have to say it is more effective than Pi Hole (I stopped using Pi Hole after discovered this). The source: Needless to say again, you can use as many input lists as you like: I have added about 10 lists that contains hosts or IP addresses, and another couple being from AdBlock lists ( br…

[trish]

@nickh

Yes. In this case I am pretty certain we require SNAT to successfully hijack the DNS. It can be done with a manual rule but it means using firewall-local - www.ipfire.org - firewall.local.

What about changing the rule to
Source: Firewall GREEN (192.68.1.1)
NAT: Source NAT : New Source GREEN (192.68.1.1)
Destination: 192.168.1.33 (IP address of Pihole)
Protocol : Preset Service Group DNS/NTP

[nickh (Nick Howitt)]

But the source isn’t Green0, even though the packet is coming via Green0. As far as I can see, it will need a custom rule in the start section:

iptables -I CUSTOMPOSTROUTING -t nat -s your_green_LAN_subnet -d 192.168.1.33 -p tcp -m multiport --dports 53,853 -j SNAT --to-source 192.168.1.1
iptables -I CUSTOMPOSTROUTING -t nat -s your_green_LAN_subnet -d 192.168.1.33 -p udp -m multiport --dports 53,123 -j SNAT --to-source 192.168.1.1

If you leave off the port and protocol selector you can do it in a single rule and it should be safe.

You will also need a rule in the stop section:

iptables -F CUSTOMPOSTROUTING -t nat

You must try the commands manually first at the command line to verify they work.

TBH, I think the stop section should be defaulted to flush all custom chains unless there is a very good reason not to that I am missing. Then the user would not have to bother with the stop section.

[hvacguy (Shaun HVAC)]

High jacking DOT port 853.
Is this not going to break TLS.
My understanding is block port 853.
Force users / redirect port 53 per the wiki.
Setup IPfire as DNS using DOT.
Users will use port 53 to IPFire DNS.
IPFire will get DNS using DOT.

[nickh (Nick Howitt)]

I tend to agree that hijacking DoT will break it but am not too familiar with DoT, so, as someone mentioned redirecting tcp:853, I just provided the rules.