Re: SA Internet security issues
Daniel Schroder <[email protected]> Wed, 5 Jul 2017 13:20:09 +0200
| Newsgroups | gmane.org.operators.ioz |
|---|---|
| Message-ID | <CAMvWrAvbee33UCStA24zz40iP0a8UXQ92G+WWEbipg_LDsq76w@mail.gmail.com> |
--===============0491016332==
Content-Type: multipart/alternative; boundary="001a11418c7044bcf60553903163"
--001a11418c7044bcf60553903163
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Really don't want to reply to this :/
Point: You can't have a root dns server routed locally on Ipv4, routed
internationally on Ipv6, with no easy way of checking if they are the same
machine, one with around Ipv4 - 40ms (max) other ipv6 - 170 ms (round trip
internationally).
Point: dnsec enables you to _detect_ spoofing, then you just need to find
the source. If a query (drill -TD) returns a different address than a non
dnsec query, you know you have a problem.
Point: Isps have been known to redirect dns requests, if you want
citations, google "dns hijacking"
Point: Tenet do not route via jinx for ipv6, on the same address given over
dns for disa.tenet.ac.za, This is from internet exchanges, IF you routing
via an internet exchange, then what is (he.net) doing wrong, and they don't
often make mistakes. ALSO the fact that there is a response that is LESS
than a trip via london, back to cpt, then back to london, then to me,
implies the response was not a international return trip, unless obviously
I've made an error, if I haven't that reply is originating internationally.
Nothing wrong with that, but you can't have two responses that don't add
up. HOWEVER it could also be a simple routing issue, out via international,
in locally, but it's not easy to check all this, and that is a problem.
Should have been picked up and understood and sorted out.
Point: All Ipv6 routed root dns servers go via jinx just fine, except for
tenet, this could be a simple BGP announcement issue, easy to solve, but
does not answer the 175 ms response if disa.tenet.ac.za is routed
internationally. (See above point)
Point: If I know how to hijack, spoof and otherwise cause DNS problems (I
fix them), then there are many other who do, WHY is a dnsec sighned DNS
reply an issue, just to be sure of responses. Even if a root anchor is
established, it can be used, it can be changed, unless there are control
issues.
Point: running a dns server that runs queries chained, is a lot quicker and
secure than trusting your ISPs supplied cache servers. This also allows a
lot more efficient and quicker CDN source reply, as well as making it more
difficult to reroute queries.
Point: Most server operating systems that are new try ipv6 first unless
specified, and I know desktop machines always try ipv6 first unconfigured,
so I'm hoping you understand the potential problems here.
Don't get me wrong, but I really do like to get to the root of problems,
and don't enjoy debates that waste everyones time, but I do read
everything, including the fine print and things need to add up, otherwise
everything based on the those basics suffers.
Below is my output, there is one return that is out.
Daniel
root@deelap:~# dig +nssearch za | awk -F ' ' '{print $11, $12, $13, $14}' |
column -t
2001:67c:1010:19::53 in 10 ms.
194.146.106.78 in 11 ms.
196.4.160.27 in 11 ms.
2001:500:14:6055:ad::1 in 11 ms.
204.61.216.55 in 11 ms.
196.21.79.50 in 28 ms.
2001:4200:ffff:a::1 in 168 ms.
2001:500:2e::1 in 177 ms.
192.5.4.1 in 178 ms.
On Wed, Jul 5, 2017 at 10:06 AM, Nishal Goburdhan <[email protected]=
a
> wrote:
>
> > On 04 Jul 2017, at 12:19, Daniel Schroder <[email protected]>
> wrote:
> >
> > Just want to point out the obvious, DNSEC helps finding sources of DN=
S
> > spoofing,
>
> um=E2=80=A6.no.
> a DNSSEC signed reponse will be something that can be validated to
> determine accuracy of the answer received.
> that=E2=80=99s not the same as finding the source of what/whom is doing s=
poofing.
>
>
> > which is often used by high tier ISPs to redirect traffic, or
> > on compromised hardware.
>
> citation needed please.
>
>
> > It's useful to have a DNS server that chases
> > DNS queries, and have some form of trusting the reply, if you do your
> > online banking, from a [1]co.za second level domain, you can't do the
> > query via dnsec, so your only other option is using other open dns
> > servers,
>
> not quite; you can also use your ISP=E2=80=99s DNS servers, or, run your=
own.
>
>
> > however it's easy to spoof or hijack queries from there as well.
>
> yes, considerably easier, than if you used your ISP, whom you, presumably
> trust.
>
>
> > Also I have a feeling Ipv6 is also going to become a problem.
> > Especially in terms of routing, the primaries for za do not all route
> > locally,
>
> that=E2=80=99s a broad statement, with little evidence. from a pretty we=
ll
> connnected, dual-stacked host in JNB, i see:
> nishal@jnb:~$ dig +nssearch za | awk -F ' ' '{print $11, $12, $13, $14}'
> 194.146.106.78 in 0 ms.
> 204.61.216.55 in 1 ms.
> 2001:67c:1010:19::53 in 1 ms.
> 2001:500:14:6055:ad::1 in 1 ms.
> 196.4.160.27 in 3 ms.
> 2001:4200:ffff:a::1 in 17 ms.
> 196.21.79.50 in 17 ms.
> 2001:500:2e::1 in 170 ms.
> 192.5.4.1 in 179 ms.
>
> for good measure, i also pasted in the results from a host in CPT below
> [2].
> all of this tells me that 1 host isn=E2=80=99t dual stacked (naughty 3741=
!), and
> one host is likely hosted out of ZA. i don=E2=80=99t see any of the IPv6=
problems
> you allude to.
> since there is no requirement to have all secondaries inside your country=
,
> and i recognise three of those hosts as anycast, i=E2=80=99ll ask again -=
what IPv6
> problem are you seeing, and are you sure it=E2=80=99s not just from your
> perspective?
>
> =E2=80=94n.
>
> [2] nishal@cpt:~$ dig +nssearch za | awk -F ' ' '{print $11, $12, $13,
> $14}'
> 196.21.79.50 in 0 ms.
> 204.61.216.55 in 7 ms.
> 2001:500:14:6055:ad::1 in 7 ms.
> 194.146.106.78 in 16 ms.
> 2001:67c:1010:19::53 in 16 ms.
> 196.4.160.27 in 17 ms.
> 2001:4200:ffff:a::1 in 32 ms.
> 2001:500:2e::1 in 156 ms.
> 192.5.4.1 in 282 ms.
>
> _______________________________________________
> IOZ mailing list
> [email protected]
> http://lists.internet.org.za/mailman/listinfo/ioz
>
--001a11418c7044bcf60553903163
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Really don't want to reply to this :/
Point: You can't have a root dns server routed locally on Ipv4, routed
internationally on Ipv6, with no easy way of checking if they are the
same machine, one with aroundA Ipv4 - 40ms (max) other ipv6 - 170 ms
(round trip internationally).
Point: dnsec enables you to _detect_ spoofing, then you just need to
find the source. If a query (drill -TD) returns a different address
than a non dnsec query, you know you have a problem.
Point: Isps have been known to redirect dns requests, if you want
citations, google "dns hijacking"
Point: Tenet do not route via jinx for ipv6, on the same address given
over dns for [1]disa.tenet.ac.za, This is from internet exchanges, IF
you routing via an internet exchange, then what is ([2]he.net) doing
wrong, and they don't often make mistakes.A ALSO the fact that there
is a response that is LESS than a trip via london, back to cpt, then
back to london, then to me, implies the response was not a
international return trip, unless obviously I've made an error, if I
haven't that reply is originating internationally. Nothing wrong with
that, but you can't have two responses that don't add up. HOWEVER it
could also be a simple routing issue, out via international, in
locally, but it's not easy to check all this, and that is a problem.
Should have been picked up and understood and sorted out.A
Point: All Ipv6 routed root dns servers go via jinx just fine, except
for tenet, this could be a simple BGP announcement issue, easy to
solve, but does not answer the 175 ms response if [3]disa.tenet.ac.zaA
is routed internationally. (See above point)
Point: If I know how to hijack, spoof and otherwise cause DNS problems
(I fix them), then there are many other who do, WHY is a dnsec sighned
DNS reply an issue, just to be sure of responses. Even if a root anchor
is established, it can be used, it can be changed, unless there are
control issues.
Point: running a dns server that runs queries chained, is a lot quicker
and secure than trusting your ISPs supplied cache servers. This also
allows a lot more efficient and quicker CDN source reply, as well as
making it more difficult to reroute queries.
Point: Most server operating systems that are new try ipv6 first unless
specified, and I know desktop machines always try ipv6 first
unconfigured, so I'm hoping you understand the potential problems here.
Don't get me wrong, but I really do like to get to the root of
problems, and don't enjoy debates that waste everyones time, but I do
read everything, including the fine print and things need to add up,
otherwise everything based on the those basics suffers.
Below is my output, there is one return that is out.
Daniel
root@deelap:~# dig +nssearch za | awk -F ' ' '{print $11, $12, $13,
$14}' | column -t
2001:67c:1010:19::53A A A inA 10A A ms.
194.146.106.78A A A A A A A A A inA 11A A ms.
196.4.160.27A A A A A A A A A A A inA 11A A ms.
2001:500:14:6055:ad::1A inA 11A A ms.
204.61.216.55A A A A A A A A A A inA 11A A ms.
196.21.79.50A A A A A A A A A A A inA 28A A ms.
2001:4200:ffff:a::1A A A A inA 168A ms.
2001:500:2e::1A A A A A A A A A inA 177A ms.
192.5.4.1A A A A A A A A A A A A A A inA 178A ms.
On Wed, Jul 5, 2017 at 10:06 AM, Nishal Goburdhan
<[4][email protected]> wrote:
> On 04 Jul 2017, at 12:19, Daniel Schroder
<[5][email protected]> wrote:
>
>A A Just want to point out the obvious, DNSEC helps finding
sources of DNS
>A A spoofing,
uma|.no.
a DNSSEC signed reponse will be something that can be validated to
determine accuracy of the answer received.
thatas not the same as finding the source of what/whom is doing
spoofing.
>A which is often used by high tier ISPs to redirect traffic, or
>A A on compromised hardware.
citation needed please.
>A A It's useful to have a DNS server that chases
>A A DNS queries, and have some form of trusting the reply, if you
do your
>A A online banking, from a [1][6]co.za second level domain, you
can't do the
>A A query via dnsec, so your only other option is using other open
dns
>A A servers,
not quite;A you can also use your ISPas DNS servers, or, run your
own.
> however it's easy to spoof or hijack queries from there as well.
yes, considerably easier, than if you used your ISP, whom you,
presumably trust.
>A A Also I have a feeling Ipv6 is also going to become a problem.
>A A Especially in terms of routing, the primaries for za do not
all route
>A A locally,
thatas a broad statement, with little evidence.A from a pretty well
connnected, dual-stacked host in JNB, i see:
nishal@jnb:~$ dig +nssearch za | awk -F ' ' '{print $11, $12, $13,
$14}'
194.146.106.78 in 0 ms.
204.61.216.55 in 1 ms.
2001:67c:1010:19::53 in 1 ms.
2001:500:14:6055:ad::1 in 1 ms.
196.4.160.27 in 3 ms.
2001:4200:ffff:a::1 in 17 ms.
196.21.79.50 in 17 ms.
2001:500:2e::1 in 170 ms.
192.5.4.1 in 179 ms.
for good measure, i also pasted in the results from a host in CPT
below [2].
all of this tells me that 1 host isnat dual stacked (naughty 3741
!), and one host is likely hosted out of ZA.A i donat see any of
the IPv6 problems you allude to.
since there is no requirement to have all secondaries inside your
country, and i recognise three of those hosts as anycast, iall ask
again - what IPv6 problem are you seeing, and are you sure itas not
just from your perspective?
an.
[2]A nishal@cpt:~$ dig +nssearch za | awk -F ' ' '{print $11, $12,
$13, $14}'
196.21.79.50 in 0 ms.
204.61.216.55 in 7 ms.
2001:500:14:6055:ad::1 in 7 ms.
194.146.106.78 in 16 ms.
2001:67c:1010:19::53 in 16 ms.
196.4.160.27 in 17 ms.
2001:4200:ffff:a::1 in 32 ms.
2001:500:2e::1 in 156 ms.
192.5.4.1 in 282 ms.
_______________________________________________
IOZ mailing list
[7][email protected]
[8]http://lists.internet.org.za/mailman/listinfo/ioz
References
1. http://disa.tenet.ac.za/
2. http://he.net/
3. http://disa.tenet.ac.za/
4. mailto:[email protected]
5. mailto:[email protected]
6. http://co.za/
7. mailto:[email protected]
8. http://lists.internet.org.za/mailman/listinfo/ioz
--001a11418c7044bcf60553903163--
--===============0491016332==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
IOZ mailing list
[email protected]
http://lists.internet.org.za/mailman/listinfo/ioz
--===============0491016332==--