The Goal is not to mitigate or take action against the malicious activity.
Goal is to detect the hijacking event by trying to reduce false posivites
as much as possible.
I know false positives is one of the key factor to consider.
I am just trying to distinguish between a legitimate advertisement a
On 28/02/2017 07:15, Nagarjun Govindraj via NANOG wrote:
So what if you detect in 1.4 minutes of 3.1 minutes? Or even 8
minutes? What then?
You certainly couldn't do anything to prevent it after 3.1 minutes.
First you need to analyze whether the BGP hijack is a false positive or not.
Could be t
On Tue, Feb 28, 2017 at 12:15 AM, Nagarjun Govindraj <
nagarjun.govind...@imaginea.com> wrote:
>
> Well, the idea behind the mail was to know if anyone in the community are
> doing real time BGP IP prefix hijacking.
> Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes.
> So I
Well, the idea behind the mail was to know if anyone in the community are
doing real time BGP IP prefix hijacking.
Like Artemis detection tool claims to be detecting in 1.4 ~ 3.1 minutes. So
I wanted to know if anyone in the community are using such tools for
detecting hijacks, if yes how much time
Christopher Morrow wrote:
> Also: "How reliable are the alerts being sent?"
also: do the smtp servers which handle mail for the domain of the
alerting email address use the IP address space as they're notifying about?
Nick
Also: "How reliable are the alerts being sent?"
On Mon, Feb 27, 2017 at 12:19 PM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:
> you probably want to ask the people that make these systems, yes?
>
> On Sun, Feb 26, 2017 at 7:12 AM, Nagarjun Govindraj via NANOG <
> nanog@nanog.org> wrote:
you probably want to ask the people that make these systems, yes?
On Sun, Feb 26, 2017 at 7:12 AM, Nagarjun Govindraj via NANOG <
nanog@nanog.org> wrote:
> Hi Nanog,
>
> what are the detection times for BGP IP prefix hijack detection systems
> adopted by community members/operators (if any) ?
>
>
Once upon a time, valdis.kletni...@vt.edu said:
> There's only 2 certs. You generate 2 certs with the same hash, and *then* get
> the CA to sign one of them.
The point is that the signed cert you get back from the CA will have a
different hash, and the things that they change that cause the hash
On Mon, 27 Feb 2017 07:23:43 -0500, Jon Lewis said:
> On Sun, 26 Feb 2017, Keith Medcalf wrote:
>
> > So you would need 6000 years of computer time to compute the collision
> > on the SHA1 signature, and how much additional time to compute the
> > trapdoor (private) key, in order for the cert to be
On Sun, 26 Feb 2017, Keith Medcalf wrote:
So you would need 6000 years of computer time to compute the collision
on the SHA1 signature, and how much additional time to compute the
trapdoor (private) key, in order for the cert to be of any use?
1) Wasn't the 6000 years estimate from an article
On Mon, 27 Feb 2017 01:15:28 -0500, "Patrick W. Gilmore" said:
> In the example above, the CA knows the SHA-1 hash of the cert it issued. (We
> are assuming there is a CA which still does SHA-1.) How do you get that CA to
> believe the two OTHER certs with DIFFERENT hashes you have to create so yo
> 1. Create a certificate C[ert] for a single domain you control with hash h(c).
> 2. Create a second certificate A[ttack] marked as a certificate
>authority such that h(C) = h(A).
> 3. Have a certificate authority sign cert C
> 4. Present the signature for A along with A for whatever nefarious
12 matches
Mail list logo
