Re: Malicious-DNS

2019-02-18 Thread Sten Carlsen 
Or do the combination, setup the fake server and use tcpdump or
wireshark to capture all access. That should catch all ports and protocols.

On 18-02-2019 21.05, Kevin Darcy wrote:
> Another approach is to define a "fake" vitaminc.pro
>  domain, point it at an internal webserver
> (assuming you have a spare, or can spin one up for the purpose), and
> see what clients are hitting it.
>
> Of course, that assumes the communication is web-based. If it's some
> other protocol(s), you'd need to monitor that protocol, or those
> protocols, on the "decoy" server. One would need to know more about
> the behavior of the malware involved.
>
> Speaking of which, Virustotal doesn't seem to think there's anything
> suspicious about vitaminc.pro . Haven't checked
> my other sources of Threat Intelligence, but usually there's
> *something* on VT if a domain is being used as a C
>
>                                                                      
>                    - Kevin
>
>
> On Mon, Feb 18, 2019 at 9:24 AM Tony Finch  > wrote:
>
> MEjaz mailto:me...@cyberia.net.sa>> wrote:
> >
> > If I enabled the system performs will slow down?
>
> Depends on how much load your servers are under and what their
> capacity
> is.
>
> An alternative to query logs, when you are searching for a known query
> name, is to use tcpdump. It's a tedious and fiddly to convert the
> name to
> DNS wire format and then into a pcap filter expression, so I have
> a little
> script to do that (quoted below after my .sig). The command you
> want is
> like:
>
> tcpdump -np udp port 53 and '(' udp[20] == 8 and udp[21] == 118
> and udp[22] == 105 and udp[23] == 116 and udp[24] == 97 and
> udp[25] == 109 and udp[26] == 105 and udp[27] == 110 and udp[28]
> == 99 and udp[29] == 3 and udp[30] == 112 and udp[31] == 114 and
> udp[32] == 111 ')'
>
> Tony.
> -- 
> f.anthony.n.finch  mailto:d...@dotat.at>> 
> http://dotat.at/
> Southeast Iceland: Northerly 6 to gale 8, veering northeasterly 5
> to 7. Rough
> or very rough. Rain or wintry showers. Good, occasionally poor.
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> use Net::DNS::DomainName;
>
> die "usage: $0 \n"
>     unless @ARGV == 1;
>
> my $text = shift;
> my $wire = new Net::DNS::DomainName($text)->canonical;
>
> my @wire = unpack 'C*', $wire;
>
> pop @wire unless $text =~ m{\.$};
>
> printf "'(' %s ')'\n",
>     join ' and ',
>     map { sprintf "udp[%d] == %d",
>               20 + $_, $wire[$_] }
>     0 .. $#wire;
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> die "usage: tcpdump-qname.pl  \n"
>     unless @ARGV == 1;
>
> my $name = shift;
>
> my @name = unpack 'C*', $name;
>
> printf "%s\n", join ', ', @name;
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

"MALE BOVINE MANURE!!!" 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Malicious-DNS

2019-02-18 Thread Kevin Darcy 
Another approach is to define a "fake" vitaminc.pro domain, point it at an
internal webserver (assuming you have a spare, or can spin one up for the
purpose), and see what clients are hitting it.

Of course, that assumes the communication is web-based. If it's some other
protocol(s), you'd need to monitor that protocol, or those protocols, on
the "decoy" server. One would need to know more about the behavior of the
malware involved.

Speaking of which, Virustotal doesn't seem to think there's anything
suspicious about vitaminc.pro. Haven't checked my other sources of Threat
Intelligence, but usually there's *something* on VT if a domain is being
used as a C


 - Kevin


On Mon, Feb 18, 2019 at 9:24 AM Tony Finch  wrote:

> MEjaz  wrote:
> >
> > If I enabled the system performs will slow down?
>
> Depends on how much load your servers are under and what their capacity
> is.
>
> An alternative to query logs, when you are searching for a known query
> name, is to use tcpdump. It's a tedious and fiddly to convert the name to
> DNS wire format and then into a pcap filter expression, so I have a little
> script to do that (quoted below after my .sig). The command you want is
> like:
>
> tcpdump -np udp port 53 and '(' udp[20] == 8 and udp[21] == 118 and
> udp[22] == 105 and udp[23] == 116 and udp[24] == 97 and udp[25] == 109 and
> udp[26] == 105 and udp[27] == 110 and udp[28] == 99 and udp[29] == 3 and
> udp[30] == 112 and udp[31] == 114 and udp[32] == 111 ')'
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Southeast Iceland: Northerly 6 to gale 8, veering northeasterly 5 to 7.
> Rough
> or very rough. Rain or wintry showers. Good, occasionally poor.
>
>
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> use Net::DNS::DomainName;
>
> die "usage: $0 \n"
> unless @ARGV == 1;
>
> my $text = shift;
> my $wire = new Net::DNS::DomainName($text)->canonical;
>
> my @wire = unpack 'C*', $wire;
>
> pop @wire unless $text =~ m{\.$};
>
> printf "'(' %s ')'\n",
> join ' and ',
> map { sprintf "udp[%d] == %d",
>   20 + $_, $wire[$_] }
> 0 .. $#wire;
> #!/usr/bin/perl
>
> use warnings;
> use strict;
>
> die "usage: tcpdump-qname.pl \n"
> unless @ARGV == 1;
>
> my $name = shift;
>
> my @name = unpack 'C*', $name;
>
> printf "%s\n", join ', ', @name;
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re:

2019-02-18 Thread Kevin Darcy 
I've already posted a solution for this. Basically, "Define root zone.
Delegate teamviewer.com from root zone. Define teamviewer.com as 'type
forward'".

"Recursion yes" is implied. No views necessary. It doesn't make any sense
anyway, to have the same match-clients list for all of one's views, since
the first one matched is the one that's used.

Did you not see my response, or did you perhaps dislike the approach I
suggested?

There was some subsequent discussion about not relying on DNS resolution as
one's *only* control over what sites one's clients can or cannot access.
While I agree with that, my position is that there's nothing wrong with
controlling DNS resolution, in addition to other controls.

  - Kevin

On Mon, Feb 18, 2019 at 10:44 AM Roberto Carna 
wrote:

> Dear I've implemented two views, one for local resolution and the other
> for forward a public zone to our resolver.
>
> But now I have a problem:
>
> If I define the same clients for the local zone view and forward view,
> depending on the order of the views the client can resolve or not the
> query. In this case client 10.12.1.1 will match view INT and not view EXT:
>
> acl internal { 10.12.1. 1; };
> acl external { 10.12.1.1; };
>
> view "INT" {
> match-clients { internal; };
> recursion no;
> zone "company.com" {
> type master;
> file "/etc/bind/zones/company.com.db";
> };
>
> view "EXT" {
> match-clients { external; };
> recursion yes;
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 172.1 8.1.1;
> };
> };
>
> If I define just one view with local and forward zones, I have to define
> "recursion yes" because the forward zone need this option, but in this case
> a query for a local zone is trying to be resolved against ROOT Servers and
> finally against master zone but it takes some seconds:
>
> acl unique { 10.12.1. 1; };
>
> view "INT-EXT" {
> match-clients { unique; };
> recursion yes;
> zone "company.com" {
> type master;
> file "/etc/bind/zones/company.com.db";
> };
> zone "teamviewer.com" {
> type forward;
> forward only;
> forwarders {
> 172.1 8.1.1;
> };
> };
>
> How can I define same clients to try resolving first view and -if there is
> no response- they try with second view ???
>
> Or is there any other way to do what I want?
>
> Regards
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[no subject]

2019-02-18 Thread Roberto Carna 
Dear I've implemented two views, one for local resolution and the other for
forward a public zone to our resolver.

But now I have a problem:

If I define the same clients for the local zone view and forward view,
depending on the order of the views the client can resolve or not the
query. In this case client 10.12.1.1 will match view INT and not view EXT:

acl internal { 10.12.1. 1; };
acl external { 10.12.1.1; };

view "INT" {
match-clients { internal; };
recursion no;
zone "company.com" {
type master;
file "/etc/bind/zones/company.com.db";
};

view "EXT" {
match-clients { external; };
recursion yes;
zone "teamviewer.com" {
type forward;
forward only;
forwarders {
172.1 8.1.1;
};
};

If I define just one view with local and forward zones, I have to define
"recursion yes" because the forward zone need this option, but in this case
a query for a local zone is trying to be resolved against ROOT Servers and
finally against master zone but it takes some seconds:

acl unique { 10.12.1. 1; };

view "INT-EXT" {
match-clients { unique; };
recursion yes;
zone "company.com" {
type master;
file "/etc/bind/zones/company.com.db";
};
zone "teamviewer.com" {
type forward;
forward only;
forwarders {
172.1 8.1.1;
};
};

How can I define same clients to try resolving first view and -if there is
no response- they try with second view ???

Or is there any other way to do what I want?

Regards
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Malicious-DNS

2019-02-18 Thread Tony Finch 
MEjaz  wrote:
>
> If I enabled the system performs will slow down?

Depends on how much load your servers are under and what their capacity
is.

An alternative to query logs, when you are searching for a known query
name, is to use tcpdump. It's a tedious and fiddly to convert the name to
DNS wire format and then into a pcap filter expression, so I have a little
script to do that (quoted below after my .sig). The command you want is
like:

tcpdump -np udp port 53 and '(' udp[20] == 8 and udp[21] == 118 and udp[22] == 
105 and udp[23] == 116 and udp[24] == 97 and udp[25] == 109 and udp[26] == 105 
and udp[27] == 110 and udp[28] == 99 and udp[29] == 3 and udp[30] == 112 and 
udp[31] == 114 and udp[32] == 111 ')'

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Northerly 6 to gale 8, veering northeasterly 5 to 7. Rough
or very rough. Rain or wintry showers. Good, occasionally poor.


#!/usr/bin/perl

use warnings;
use strict;

use Net::DNS::DomainName;

die "usage: $0 \n"
unless @ARGV == 1;

my $text = shift;
my $wire = new Net::DNS::DomainName($text)->canonical;

my @wire = unpack 'C*', $wire;

pop @wire unless $text =~ m{\.$};

printf "'(' %s ')'\n",
join ' and ',
map { sprintf "udp[%d] == %d",
  20 + $_, $wire[$_] }
0 .. $#wire;
#!/usr/bin/perl

use warnings;
use strict;

die "usage: tcpdump-qname.pl \n"
unless @ARGV == 1;

my $name = shift;

my @name = unpack 'C*', $name;

printf "%s\n", join ', ', @name;

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users