byt3bl33d3r/dnschef-ngDNSChef (NG) - DNS proxy for Penetration Testers and Malware Analysts
[!NOTE] Esta é uma versão atualizada de DNSChef originalmente escrito por @iphelix``` _ _ __
| | v0.7 | | / |
| | __ ___ | | | | ______ _ __ __ _ /| '_ \/ __|/ __| '_ \ / _ \ _|______| '_ \ / _| | (| | | | _ \ (__| | | | __/ | | | | | (| | _,|| ||/_|| ||___|| || ||_, | / | |_/ D O C U M E N T A T I O N
O DNSChef é um proxy DNS altamente configurável para Testadores de Penetração e Analistas de Malware. Um proxy DNS (também conhecido como "Fake DNS") é uma ferramenta usada para análise de tráfego de rede de aplicativos, entre outros usos. Por exemplo, um proxy DNS pode ser usado para falsificar requisições para "badguy.com" e apontá-las para uma máquina local para terminação ou interceptação em vez de um host real em algum lugar da Internet.
Existem vários proxies DNS por aí. A maioria simplesmente aponta todas as consultas DNS para um único endereço IP ou implementa apenas filtragem rudimentar. O DNSChef foi desenvolvido como parte de um teste de penetração onde havia a necessidade de um sistema mais configurável. Como resultado, o DNSChef é um aplicativo multiplataforma capaz de forjar respostas com base em listas de domínios inclusivas e exclusivas, suportando vários tipos de registros DNS, correspondência de domínios com curingas, fazendo proxy de respostas reais para domínios não correspondentes, definindo arquivos de configuração externos, IPv6 e muitos outros recursos. Você pode encontrar uma explicação detalhada de cada um dos recursos e usos sugeridos abaixo.
O uso de um proxy DNS é recomendado em situações em que não é possível forçar um aplicativo a usar algum outro servidor proxy diretamente. Por exemplo, alguns aplicativos móveis ignoram completamente as configurações de proxy HTTP do sistema operacional. Nesses casos, o uso de um servidor proxy DNS como o DNSChef permitirá que você engane esse aplicativo para encaminhar conexões ao destino desejado.
## Novos Recursos
- Requer Python 3.11+
- Suporta transferência de arquivos via DNS (somente sobre `A`,`AAAA`,`TXT` por enquanto...)
- O arquivo de configuração agora é TOML
- API HTTP opcional (permite consultar logs e atualizar a configuração remotamente)
- Totalmente assíncrono para maior desempenho (usa AsyncIO)
- Logging estruturado e uma série de melhorias de qualidade de vida
- Agora é um pacote Python
- Dockerizado
- Inclui vários PRs e correções do repositório original
## Instalação
Para instalar a versão mais recente, você deve usar [pipx](https://pypa.github.io/pipx/) (a menos que você seja um merda que gosta de coisas mal feitas):
pipx install dnschef-ng
Se você quiser a API HTTP (requer algumas dependências extras):
pipx install dnschef-ng[api]
Instale a versão mais recente do Git usando pipx:
pipx install git+https://github.com/byt3bl33d3r/dnschef-ng.git
Instale a versão mais recente do Git usando pipx com as dependências para a API HTTP:
pipx install "git+https://github.com/byt3bl33d3r/dnschef-ng.git#egg=dnschef-ng[api]"
## Configurando um Proxy DNS
Antes de começar a usar o DNSChef, você deve configurar sua máquina para usar um servidor de nomes DNS com a ferramenta em execução. Você tem várias opções com base no sistema operacional que vai usar:
- **Linux** - Edite o */etc/resolv.conf* para incluir uma linha no topo com o host de análise de tráfego (por exemplo, adicione "nameserver 127.0.0.1" se estiver rodando localmente). Alternativamente, você pode adicionar um endereço de servidor DNS usando ferramentas como o Network Manager. Dentro do Network Manager, abra as Configurações de IPv4, selecione *Somente endereços (DHCP) automáticos* ou *Manual* no menu suspenso *Método* e edite a caixa de texto *Servidores DNS* para incluir um endereço IP com o DNSChef em execução.
- **Windows** - Selecione *Conexões de Rede* no *Painel de Controle*. Em seguida, selecione uma das conexões (por exemplo, "Conexão Local"), clique com o botão direito nela e selecione Propriedades. Dentro da caixa de diálogo que aparece, selecione *Protocolo IP (TCP/IP)* e clique em Propriedades. Por fim, selecione o botão de opção *Usar os seguintes endereços de servidor DNS* e insira o endereço IP com o DNSChef em execução. Por exemplo, se estiver rodando localmente, insira 127.0.0.1.
- **OS X** - Abra *Preferências do Sistema* e clique no ícone *Rede*. Selecione a interface ativa e preencha o campo *Servidor DNS*. Se estiver usando o Airport, você terá que clicar no botão *Avançado...* e editar os servidores DNS a partir daí. Alternativamente, você pode editar o */etc/resolv.conf* e adicionar um servidor de nomes falso no topo (por exemplo, "nameserver 127.0.0.1").
- **iOS** - Abra *Ajustes* e selecione *Geral*. Em seguida, selecione *Wi-Fi* e clique na seta azul à direita de um Ponto de Acesso ativo na lista. Edite a entrada de DNS para apontar para o host com o DNSChef em execução. Certifique-se de ter desabilitado a interface Celular (se disponível).
- **Android** - Abra *Configurações* e selecione *Sem fio e redes*. Clique em *Configurações de Wi-Fi* e selecione *Avançado* após pressionar o botão *Opções* no telefone. Ative a caixa de seleção *Usar IP estático* e configure um servidor DNS personalizado.
Se você não tiver a capacidade de modificar as configurações de DNS do dispositivo manualmente, ainda terá várias opções envolvendo técnicas como [ARP Spoofing](http://en.wikipedia.org/wiki/ARP_spoofing), [Rogue DHCP](http://www.yersinia.net/doc.htm) e outros métodos criativos.
Por fim, você precisa configurar um serviço falso para onde o DNSChef apontará todas as requisições. Por exemplo, se você está tentando interceptar tráfego web, deve subir um servidor web separado rodando na porta 80 ou configurar um proxy web (por exemplo, Burp) para interceptar o tráfego. O DNSChef apontará as consultas para o seu host de proxy/servidor com serviços devidamente configurados.
## Executando o DNSChef
O DNSChef é um aplicativo multiplataforma desenvolvido em Python que deve ser executado na maioria das plataformas que possuem um interpretador Python. Este guia se concentrará em ambientes Unix; no entanto, todos os exemplos abaixo foram testados e funcionam também no Windows.
Vamos experimentar o DNSChef com sua funcionalidade de monitoramento mais básica. Execute o seguinte comando como root (necessário para iniciar um servidor na porta 53):
# ./dnschef.py
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
Sem nenhum parâmetro, o DNSChef rodará em modo proxy completo. Isso significa que todas as requisições serão simplesmente encaminhadas para um servidor DNS upstream (8.8.8.8 por padrão) e retornadas ao host de consulta. Por exemplo, vamos consultar um registro "A" para um domínio e observar os resultados:
$ host -t A thesprawl.org
thesprawl.org has address 108.59.3.64
O DNSChef imprimirá a seguinte linha de log mostrando hora, endereço IP de origem, tipo de registro solicitado e, o mais importante, qual nome foi consultado:
[23:54:03] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Esse modo é útil para monitoramento simples de aplicativos, quando você precisa descobrir quais domínios o aplicativo usa para suas comunicações.
O DNSChef tem suporte total para IPv6, que pode ser ativado usando os sinalizadores *-6* ou *--ipv6**. Ele funciona exatamente como o modo IPv4, com a exceção de que a interface de escuta padrão é alterada para ::1 e o servidor DNS padrão é alterado para 2001:4860:4860::8888. Aqui está um exemplo de saída:
# ./dnschef.py -6
_ _ __
| | version 0.2 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
[email protected]
[*] Using IPv6 mode.
[*] DNSChef started on interface: ::1
[*] Using the following nameservers: 2001:4860:4860::8888
[*] No parameters were specified. Running in full proxy mode
[00:35:44] ::1: proxying the response of type 'A' for thesprawl.org
[00:35:44] ::1: proxying the response of type 'AAAA' for thesprawl.org
[00:35:44] ::1: proxying the response of type 'MX' for thesprawl.org
NOTA: Por padrão, o DNSChef cria um listener UDP. Você pode usar TCP em vez disso com o argumento *--tcp* discutido posteriormente.
## Executando a API HTTP do DNSChef
> [!WARNING]
> A API não possui autenticação. Permita/negue o acesso no nível de rede por meio de grupos de segurança, iptables, firewall etc.
`uvicorn dnschef.api:app`
Você pode então visualizar a documentação OpenAPI em `http://127.0.0.1:8000/docs````
$ uvicorn dnschef.api:app
INFO: Started server process [28327]
INFO: Waiting for application startup.
_ _ __
| | version 0.6.0 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
@iphelix // @byt3bl33d3r
2023-09-28 11:24:59 cooking replies domain=*.thesprawl.org record=192.0.2.1 section=A
2023-09-28 11:24:59 cooking replies domain=*.thesprawl.org record=2001:db8::1 section=AAAA
-- SNIP --
2023-09-28 11:24:59 cooking replies domain=*.thesprawl.org record=1 . alpn=h2 ipv4hint=127.0.0.1 ipv6hint=::1 section=HTTPS
INFO: Application startup complete.
2023-09-28 11:24:59 DNSChef is active interface=127.0.0.1 ipv6=False nameservers=['8.8.8.8'] port=53 tcp=False
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
Now, that you know how to start DNSChef let's configure it to fake all replies to point to 127.0.0.1 using the --fakeip parameter:
# ./dnschef.py --fakeip 127.0.0.1 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[23:55:57] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
[23:55:57] 127.0.0.1: proxying the response of type 'AAAA' for google.com
[23:55:57] 127.0.0.1: proxying the response of type 'MX' for google.com
In the above output you can see that DNSChef was configured to proxy all requests to 127.0.0.1. The first line of log at 08:11:23 shows that we have "cooked" the "A" record response to point to 127.0.0.1. However, further requests for 'AAAA' and 'MX' records are simply proxied from a real DNS server. Let's see the output from requesting program:
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address 2001:4860:4001:803::1001
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
As you can see the program was tricked to use 127.0.0.1 for the IPv4 address. However, the information obtained from IPv6 (AAAA) and mail (MX) records appears completely legitimate. The goal of DNSChef is to have the least impact on the correct operation of the program, so if an application relies on a specific mailserver it will correctly obtain one through this proxied request.
Let's fake one more request to illustrate how to target multiple records at the same time:
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[*] Cooking all AAAA replies to point to ::1
[00:02:14] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
[00:02:14] 127.0.0.1: cooking the response of type 'AAAA' for google.com to ::1
[00:02:14] 127.0.0.1: proxying the response of type 'MX' for google.com
In addition to the --fakeip flag, I have now specified --fakeipv6 designed to fake 'AAAA' record queries. Here is an updated program output:
$ host google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
Once more all of the records not explicitly overriden by the application were proxied and returned from the real DNS server. However, IPv4 (A) and IPv6 (AAAA) were both faked to point to a local machine.
DNSChef supports multiple record types:
NOTE: For usability not all DNS record types are exposed on the command line. Additional records such as PTR, TXT, SOA, etc. can be specified using the --file flag and an appropriate record header. See the external definitions file section below for details.
At last let's observe how the application handles queries of type ANY:
# ./dnschef.py --fakeip 127.0.0.1 --fakeipv6 ::1 --fakemail mail.fake.com --fakealias www.fake.com --fakens ns.fake.com -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking all A replies to point to 127.0.0.1
[*] Cooking all AAAA replies to point to ::1
[*] Cooking all MX replies to point to mail.fake.com
[*] Cooking all CNAME replies to point to www.fake.com
[*] Cooking all NS replies to point to ns.fake.com
[00:17:29] 127.0.0.1: cooking the response of type 'ANY' for google.com with all known fake records.
DNS ANY record queries results in DNSChef returning every faked record that it knows about for an applicable domain. Here is the output that the program will see:
# host -t ANY google.com localhost
google.com has address 127.0.0.1
google.com has IPv6 address ::1
google.com mail is handled by 10 mail.fake.com.
google.com is an alias for www.fake.com.
google.com name server ns.fake.com.
Using the above example, consider you only want to intercept requests for thesprawl.org and leave queries to all other domains such as webfaction.com without modification. You can use the --fakedomains parameter as illustrated below:
# ./dnschef.py --fakeip 127.0.0.1 --fakedomains thesprawl.org -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking replies to point to 127.0.0.1 matching: thesprawl.org
[00:23:37] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 127.0.0.1
[00:23:52] 127.0.0.1: proxying the response of type 'A' for mx9.webfaction.com
From the above example the request for thesprawl.org was faked; however, the request for mx9.webfaction.com was left alone. Filtering domains is very useful when you attempt to isolate a single application without breaking the rest.
NOTE: DNSChef will not verify whether the domain exists or not before faking the response. If you have specified a domain it will always resolve to a fake value whether it really exists or not.
In another situation you may need to fake responses for all requests except a defined list of domains. You can accomplish this task using the --truedomains parameter as follows:
# ./dnschef.py --fakeip 127.0.0.1 --truedomains thesprawl.org,*.webfaction.com -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking replies to point to 127.0.0.1 not matching: *.webfaction.com, thesprawl.org
[00:27:57] 127.0.0.1: proxying the response of type 'A' for mx9.webfaction.com
[00:28:05] 127.0.0.1: cooking the response of type 'A' for google.com to 127.0.0.1
There are several things going on in the above example. First notice the use of a wildcard (*). All domains matching *.webfaction.com will be reverse matched and resolved to their true values. The request for 'google.com' returned 127.0.0.1 because it was not on the list of excluded domains.
NOTE: Wildcards are position specific. A mask of type *.thesprawl.org will match www.thesprawl.org but not www.test.thesprawl.org. However, a mask of type ..thesprawl.org will match thesprawl.org, www.thesprawl.org and www.test.thesprawl.org.
There may be situations where defining a single fake DNS record for all matching domains may not be sufficient. You can use an external file with a collection of DOMAIN=RECORD pairs defining exactly where you want the request to go.
For example, let create the following definitions file and call it dnschef.toml:```toml
[A]
".google.com"="192.0.2.1"
"thesprawl.org"="192.0.2.2"
".wordpress.*"="192.0.2.3"
Observe o cabeçalho de seção `[A]`, ele define o tipo de registro para o DNSChef. Agora vamos observar cuidadosamente a saída de várias consultas:
# ./dnschef.py --file dnschef.toml -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking A replies for domain *.google.com with '192.0.2.1'
[+] Cooking A replies for domain thesprawl.org with '192.0.2.2'
[+] Cooking A replies for domain *.wordpress.* with '192.0.2.3'
[00:43:54] 127.0.0.1: cooking the response of type 'A' for google.com to 192.0.2.1
[00:44:05] 127.0.0.1: cooking the response of type 'A' for www.google.com to 192.0.2.1
[00:44:19] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 192.0.2.2
[00:44:29] 127.0.0.1: proxying the response of type 'A' for www.thesprawl.org
[00:44:40] 127.0.0.1: cooking the response of type 'A' for www.wordpress.org to 192.0.2.3
[00:44:51] 127.0.0.1: cooking the response of type 'A' for wordpress.com to 192.0.2.3
[00:45:02] 127.0.0.1: proxying the response of type 'A' for slashdot.org
Tanto *google.com* como *www.google.com* corresponderam à entrada *\*.google.com* e resolveram corretamente para *192.0.2.1*. Por outro lado, o pedido *www.thesprawl.org* foi simplesmente encaminhado em vez de ser modificado. Por fim, todas as variações de *wordpress.com*, *www.wordpress.org*, etc. corresponderam à máscara *\*.wordpress.\** e resolveram corretamente para *192.0.2.3*. Por último, uma consulta indefinida *slashdot.org* foi simplesmente encaminhada com uma resposta real.
Você pode especificar cabeçalhos de seção para todos os outros tipos de registro DNS suportados, incluindo aqueles não explicitamente expostos na linha de comando: [A], [AAAA], [MX], [NS], [CNAME], [PTR], [NAPTR] e [SOA]. Por exemplo, vamos definir uma nova seção [PTR] no arquivo `dnschef.toml`:```toml
[PTR]
"*.2.0.192.in-addr.arpa"="fake.com"
Vamos observar o comportamento do DNSChef com este novo tipo de registro:
./dnschef.py --file dnschef.toml -q
[sudo] password for iphelix:
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking PTR replies for domain *.2.0.192.in-addr.arpa with 'fake.com'
[00:11:34] 127.0.0.1: cooking the response of type 'PTR' for 1.2.0.192.in-addr.arpa to fake.com
E aqui está o que um cliente pode ver ao realizar consultas de DNS reverso:
$ host 192.0.2.1 localhost
1.2.0.192.in-addr.arpa domain name pointer fake.com.
Alguns registros exigem formatação exata. Bons exemplos são SOA e NAPTR```toml [SOA] "*.thesprawl.org" = "ns.fake.com. hostmaster.fake.com. 1 10800 3600 604800 3600"
[NAPTR] ".thesprawl.org" = "100 10 U E2U+sip !^.$!sip:[email protected]! ."
Veja o arquivo de exemplo `dnschef.toml` para exemplos adicionais.
## Staging de Arquivos
O DNSChef pode fazer "staging" de qualquer arquivo por meio de DNS. Atualmente, o staging de arquivos é suportado apenas com registros `A`, `AAAA` e `TXT` (mais serão adicionados). Para instruir o DNSChef a fazer staging de um arquivo, adicione a seguinte seção ao seu `dnschef.toml`:```toml
[A]
"*.wat.org" = { file = "/home/payload.exe", chunk_size = 4 }
[AAAA]
"*.gorgetowngeronimos.org" = { file = "/home/payload.exe", chunk_size = 16 }
[!NOTE] A configuração
chunk_sizeé opcional e seu comportamento depende muito do tipo de consulta. Exemplo: como consultasAretornam um endereço IPv4, ochunk_sizemáximo permitido é de 4 bytes. Definir ochunk_sizepara qualquer valor acima de 4 será ignorado.
Uma consulta A para *.wat.org contendo um número no nome DNS retornará agora o chunk correspondente do arquivo. Por exemplo, a consulta ns0.wat.org retornará um endereço IPv4 contendo o primeiro chunk do arquivo (4 bytes). Uma consulta para test1.wat.org retornará o segundo chunk do arquivo, etc.
Ao usar domínios curinga como nos exemplos acima, os números de "chunk" podem ser colocados em qualquer lugar e não precisam estar juntos. Por exemplo, uma consulta A para 1aliens2.wat.org retornará o 12º chunk do arquivo.
Os registros TXT suportam opções adicionais para o preparo de arquivos, pois permitem mais flexibilidade:```toml
[TXT]
"ns*.dungbeetle.org" = { file = "~/payload.exe", chunk_size = 189, response_format = "{prefix}test-{chunk}", response_prefix_pool = ["atlassian-domain-verification=", "onetrust-domain-verification=", "docusign=" ] }
Com esta configuração, qualquer consulta `TXT` para `ns*.dungbeetle.org` retornará um trecho do nosso arquivo localizado localmente no sistema de arquivos em `~/payload.exe`.
As configurações `response_format` e `response_prefix_pool` são opcionais, mas permitem personalizar ainda mais a resposta `TXT` do DNS.
A configuração `response_format` define o formato da resposta `TXT`:
- A variável `{prefix}` será substituída aleatoriamente por um dos valores definidos no array `response_prefix_pool`.
- A variável `{chunk}` será substituída pelo trecho do arquivo.
Com a configuração acima, uma consulta `TXT` para `ns1.dungbeetle.org` retornará a seguinte resposta:```
docusign=test-<BASE64_ENCODED_FILE_CHUNK_N1>
Se você realizar outra consulta TXT (por exemplo, ns10.dungbeetle.org), verá que o prefixo mudará:```
atlassian-domain-verification=test-<BASE64_ENCODED_FILE_CHUNK_N10>
## Filtragem Avançada
Você pode combinar entradas de um arquivo e da linha de comando. Por exemplo, o seguinte comando usa os parâmetros `--file` e `--fakedomains`:
# ./dnschef.py --file dnschef.toml --fakeip 6.6.6.6 --fakedomains=thesprawl.org,slashdot.org -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[+] Cooking A replies for domain *.google.com with '192.0.2.1'
[+] Cooking A replies for domain thesprawl.org with '192.0.2.2'
[+] Cooking A replies for domain *.wordpress.* with '192.0.2.3'
[*] Cooking A replies to point to 6.6.6.6 matching: *.wordpress.*, *.google.com, thesprawl.org
[*] Cooking A replies to point to 6.6.6.6 matching: slashdot.org, *.wordpress.*, *.google.com, thesprawl.org
[00:49:05] 127.0.0.1: cooking the response of type 'A' for google.com to 192.0.2.1
[00:49:15] 127.0.0.1: cooking the response of type 'A' for slashdot.org to 6.6.6.6
[00:49:31] 127.0.0.1: cooking the response of type 'A' for thesprawl.org to 6.6.6.6
[00:50:08] 127.0.0.1: proxying the response of type 'A' for tor.com
Observe que a definição de *thesprawl.org* no parâmetro da linha de comando teve precedência sobre *dnschef.toml*. Isso pode ser útil se você quiser sobrescrever valores no arquivo de configuração. slashdot.org ainda resolve para o endereço IP falso porque foi especificado no parâmetro *--fakedomains*. A requisição de tor.com é simplesmente repassada via proxy, pois não foi especificada nem na linha de comando nem no arquivo de configuração.
## Outras configurações
Por razões de segurança, o DNSChef escuta na interface local 127.0.0.1 (ou ::1 para IPv6) por padrão. Você pode fazer o DNSChef escutar em outra interface usando o parâmetro *--interface*:
# ./dnschef.py --interface 0.0.0.0 -q
[*] DNSChef started on interface: 0.0.0.0
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
[00:50:53] 192.0.2.105: proxying the response of type 'A' for thesprawl.org
ou para IPv6:
# ./dnschef.py -6 --interface :: -q
[*] Using IPv6 mode.
[*] DNSChef started on interface: ::
[*] Using the following nameservers: 2001:4860:4860::8888
[*] No parameters were specified. Running in full proxy mode
[00:57:46] 2001:db8::105: proxying the response of type 'A' for thesprawl.org
Por padrão, o DNSChef usa o servidor DNS público do Google para fazer requisições de proxy. No entanto, você pode definir uma lista personalizada de servidores de nomes usando o parâmetro *--nameservers*:
# ./dnschef.py --nameservers 4.2.2.1,4.2.2.2 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 4.2.2.1, 4.2.2.2
[*] No parameters were specified. Running in full proxy mode
[00:55:08] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
É possível especificar uma porta de servidor de nomes não padrão usando a notação IP#PORT:
# ./dnschef.py --nameservers 192.0.2.2#5353 -q
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 192.0.2.2#5353
[*] No parameters were specified. Running in full proxy mode
[02:03:12] 127.0.0.1: proxying the response of type 'A' for thesprawl.org
Ao mesmo tempo, é possível iniciar o próprio DNSChef em uma porta alternativa usando o parâmetro `-p port#`:
# ./dnschef.py -p 5353 -q
[*] Listening on an alternative port 5353
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] No parameters were specified. Running in full proxy mode
O protocolo DNS pode ser usado sobre UDP (padrão) ou TCP. O DNSChef implementa um modo TCP que pode ser ativado com a flag `--tcp`.
| Registro | Descrição | Argumento | Exemplo |
|---|
| A | Endereço IPv4 | --fakeip | --fakeip 192.0.2.1 |
| AAAA | Endereço IPv6 | --fakeipv6 | --fakeipv6 2001:db8::1 |
| MX | Servidor de e-mail | --fakemail | --fakemail mail.fake.com |
| CNAME | Registro CNAME | --fakealias | --fakealias www.fake.com |
| NS | Servidor de nomes | --fakens | --fakens ns.fake.com |