Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added dns.spoof.proxy and dns.spoof.proxy.srv. #496

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

M0WA
Copy link
Contributor

@M0WA M0WA commented Mar 17, 2019

dns.spoof.proxy is boolean and switches on/off dns proxying.
dns.spoof.proxy.srv can either be set to 'system' (linux/mac only)
to use the system-dns for proxing or an ip.

this features proxies all dns requests seen to a given dns server
and fakes the responses if neccessary

dns.spoof.proxy is boolean and switches on/off dns proxying.
dns.spoof.proxy.srv can either be set to 'system' (linux/mac only)
                    to use the system-dns for proxing or an ip.
@codecov-io
Copy link

codecov-io commented Mar 17, 2019

Codecov Report

Merging #496 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #496   +/-   ##
=======================================
  Coverage   51.06%   51.06%           
=======================================
  Files           3        3           
  Lines          47       47           
=======================================
  Hits           24       24           
  Misses         23       23

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0810a1f...a1197f7. Read the comment docs.

@@ -80,17 +99,44 @@ func (mod DNSSpoofer) Author() string {
return "Simone Margaritelli <evilsocket@gmail.com>"
}

func (mod *DNSSpoofer)getSystemResolver() (net.IP,error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this won't work on platforms that are not GNU/Linux i think ...

Copy link
Contributor Author

@M0WA M0WA Mar 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not work very well on Linux either, because it just uses the first nameserver occurrance in a hardcoded filename and therefore the setting "system" on dns.spoof.proxy.srv is more a convenience feature for me. maybe a default of 8.8.8.8 might be better (instead of "system" as default).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just another parameter to let the user specify the default resolver?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think thats already possible, if i understand u correctly.
dns.spoof.proxy.srv can either be set to 'system' (linux/mac only) to use the system-dns for proxing or an ip.

@evilsocket
Copy link
Member

i'm not sure about this PR: why not just using a combination of dns.spoof and packet.proxy ?

@M0WA
Copy link
Contributor Author

M0WA commented Mar 17, 2019

@packet.proxy:
My final goal was to be able to control bettercaps behaviour on a per domain and per client level while behaving like a dns server. A distinction on a wildcard domain is not possible with iptables afaik. If it is, it is much more expensive than a pcap bpf filter.

i.e.
for client A google.com resolves to 1.1.1.1
for client A yahoo.com resolves to 1.1.1.2

for client B google.com resolves to / proxied request
for client B yahoo.com resolves to 1.1.1.3

for client C google.com resolves to / proxied request
for client C yahoo.com resolves to 1.1.1.3

In my setup I am currently running bettercap on the std-gateway that also does dns.
Sometimes I want to test stuff on a certain client while another should continue working "as normal",
even on domain level.

I could do some external setup with dnsmasq achieving the same functionality as above (actually I did),
but it is better to have it be controlled "in one place" also limiting the amount of logs i have to grep and many more reasons...

@mrbluecoat
Copy link

I agree, this would be very helpful for my use case as well.

@M0WA, can you share a gist with your dnsmasq solution?

puppywang pushed a commit to puppywang/bettercap that referenced this pull request Oct 9, 2020
@josh1631
Copy link

So Im really new to this my question is does this mean at the moment this program is stuck

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants