Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Amazon was only announcing 44.224.0.0/11 at first.

https://bgp.tools/prefix/44.235.216.0/24

On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette 
wrote:

> In message <
> cao3camot9gc_evd-cczg06a-o_majmltxlhbxfnaudomyqo...@mail.gmail.com>,
> Siyuan Miao  wrote:
>
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> >security team :-)
>
> Sorry.  I'm missing something here.  If the hijack was of 44.235.216.0/24,
> then
> how did AWS propagate a "more specific" than that?
>
>
> Regards,
> rfg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
>

Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509

[Ronald F. Guilmette]

In message 
, 
Siyuan Miao  wrote:

>Hjacking didn't last too long. AWS started announcing a more specific
>announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
>security team :-)

Sorry.  I'm missing something here.  If the hijack was of 44.235.216.0/24, then
how did AWS propagate a "more specific" than that?


Regards,
rfg

Re: Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Just noticed another thing:

➜  ~ whois -h whois.ripe.net -- "--list-versions AS1299" | tail -n10
2862  2022-07-11T14:44:49Z  ADD/UPD
2863  2022-07-27T11:17:25Z  ADD/UPD
2864  2022-08-02T08:43:02Z  ADD/UPD
2865  2022-08-10T12:11:29Z  ADD/UPD


*2866  2022-08-17T10:47:43Z  ADD/UPD2867  2022-08-18T12:53:37Z  ADD/UPD*
% This query was served by the RIPE Database Query Service version 1.103
(WAGYU)

➜  ~ whois -h whois.ripe.net -- "--show-version 2865 AS1299" | grep 209243
➜  ~ whois -h whois.ripe.net -- "--show-version 2866 AS1299" | grep 209243
import: from  AS209243 accept AS209243
mp-import:  afi ipv6 from AS209243 accept AS209243


*➜  ~ whois -h whois.ripe.net  -- "--show-version
2867 AS1299" | grep 209243import: from  AS209243 accept
AS-SET209243mp-import:  afi ipv6 from AS209243 accept AS-SET209243*

Looks like the first thing that AS209243 had done after they got AS1299
transit is ... hijacking an Amazon prefix ..?

On Tue, Aug 23, 2022 at 1:51 AM Siyuan Miao  wrote:

> Hi folks,
>
> Recently I read a post regarding the recent incident of Celer Network and
> noticed a very interesting and successful BGP hijacking towards AS16509.
>
> The attacker AS209243 added AS16509 to their AS-SET and a more specific
> route object for the /24 where the victim's website is in ALTDB:
> (Below is our IRRd4 server NRTM logging, UTC timezone)
>
> irrd.log-20220817.gz:31106270-ADD 96126
>
> irrd.log-20220817.gz:31106280-
>
> irrd.log-20220817.gz:31106281-as-set: AS-SET209243
>
> irrd.log-20220817.gz:31106306-descr:  quickhost set
>
> irrd.log-20220817.gz:31106332-members:AS209243, AS16509
>
> irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31106438-source: ALTDB
>
> irrd.log-20220817.gz:31147549-ADD 96127
>
> irrd.log-20220817.gz:31147559-
>
> irrd.log-20220817.gz:31147560-route:  44.235.216.0/24
>
> irrd.log-20220817.gz:31147588-descr:  route
>
> irrd.log-20220817.gz:31147606-origin: AS16509
>
> irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31147702-source: ALTDB
>
>
> Then they started announcing the prefix ... under another AWS ASN (AS14618)
> I guess AS1299 Arelion doesn't check if the origin AS of an announcement
> is in the customer's AS-SET but it's pretty normal and understandable.
>
>
> https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24=true=1660694458=1661032798=0=null=bgp
>
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 34854 1299 209243 14618 has been
> announced
> Path: 34854, 1299, 209243, 14618,
> Community: 1299:35000,34854:3001
> Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1
>
> Hjacking didn't last too long. AWS started announcing a more specific
> announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> security team :-)
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 58057 34549 5511 1299 16509 has been
> announced
> Path: 58057, 34549, 5511, 1299, 16509,
> Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
> Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251
>
> The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
> seems to notice them ...
>
> irrd.log-20220819.gz:26517714-ADD 96196
>
> irrd.log-20220819.gz:26517724-
>
> irrd.log-20220819.gz:26517725:as-set: AS-SET209243
>
> irrd.log-20220819.gz:26517750-descr:  quickhost set
>
> irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497
>
> irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net
> 20220817
>
> irrd.log-20220819.gz:26517891-source: ALTDB
>
>
>
> irrd.log-20220819.gz:26517910-DEL 96197
>
> irrd.log-20220819.gz:26517920-
>
> irrd.log-20220819.gz:26517921-route:  44.235.216.0/24
>
> irrd.log-20220819.gz:26517949-descr:  route
>
> irrd.log-20220819.gz:26517967-origin: AS16509
>
> irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220819.gz:26518063-source: ALTDB
>
>
>
> Nowadays hijacking a service by forging AS path is pretty easy and RPKI
> won't be able to solve this (as it validates origin AS and prefixes only)
> :-(
>
> Regards,
> Siyuan
>
>
>

Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Hi folks,

Recently I read a post regarding the recent incident of Celer Network and
noticed a very interesting and successful BGP hijacking towards AS16509.

The attacker AS209243 added AS16509 to their AS-SET and a more specific
route object for the /24 where the victim's website is in ALTDB:
(Below is our IRRd4 server NRTM logging, UTC timezone)

irrd.log-20220817.gz:31106270-ADD 96126

irrd.log-20220817.gz:31106280-

irrd.log-20220817.gz:31106281-as-set: AS-SET209243

irrd.log-20220817.gz:31106306-descr:  quickhost set

irrd.log-20220817.gz:31106332-members:AS209243, AS16509

irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31106438-source: ALTDB

irrd.log-20220817.gz:31147549-ADD 96127

irrd.log-20220817.gz:31147559-

irrd.log-20220817.gz:31147560-route:  44.235.216.0/24

irrd.log-20220817.gz:31147588-descr:  route

irrd.log-20220817.gz:31147606-origin: AS16509

irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31147702-source: ALTDB


Then they started announcing the prefix ... under another AWS ASN (AS14618)
I guess AS1299 Arelion doesn't check if the origin AS of an announcement is
in the customer's AS-SET but it's pretty normal and understandable.

https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24=true=1660694458=1661032798=0=null=bgp


Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 34854 1299 209243 14618 has been announced
Path: 34854, 1299, 209243, 14618,
Community: 1299:35000,34854:3001
Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1

Hjacking didn't last too long. AWS started announcing a more specific
announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
security team :-)

Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 58057 34549 5511 1299 16509 has been
announced
Path: 58057, 34549, 5511, 1299, 16509,
Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251

The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
seems to notice them ...

irrd.log-20220819.gz:26517714-ADD 96196

irrd.log-20220819.gz:26517724-

irrd.log-20220819.gz:26517725:as-set: AS-SET209243

irrd.log-20220819.gz:26517750-descr:  quickhost set

irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497

irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net 20220817

irrd.log-20220819.gz:26517891-source: ALTDB



irrd.log-20220819.gz:26517910-DEL 96197

irrd.log-20220819.gz:26517920-

irrd.log-20220819.gz:26517921-route:  44.235.216.0/24

irrd.log-20220819.gz:26517949-descr:  route

irrd.log-20220819.gz:26517967-origin: AS16509

irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220819.gz:26518063-source: ALTDB



Nowadays hijacking a service by forging AS path is pretty easy and RPKI
won't be able to solve this (as it validates origin AS and prefixes only)
:-(

Regards,
Siyuan

DNS-OARC 39 Call for Contributions

[John Todd]

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in 
Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite 
part of the meeting will be colocated with RIPE 85.


The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are 
welcome. For inspiration, we provide a non-exhaustive list of ideas:


- Operations: Any operational gotchas, lessons learned from an outage, 
details/reasons for a recent outage (how to improve TTR, tooling).

- Deployment: DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly 
detection.
- Scaling: DNS performance management and metrics. Increasing DNS Server 
Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage, 
rollovers, qname minimization, DoH/DoT



As it is a hybrid workshop, we'd like to encourage brevity; 
presentations should not be longer than 20 minutes (with additional time 
for questions).



Workshop Milestones:

2022-09-06    Deadline for submission (23:59 UTC)
2022-09-08    Preliminary list of contributions published
2022-09-20    Full agenda published
2022-10-03    Deadline for slideset submission and Rehearsal
2022-10-22    OARC 39 Workshop - Day1
2022-10-23    OARC 39 Workshop - Day2


The Registration page and details for presentation submission are 
published at:


    

To allow the Programme Committee to make objective assessments of 
submissions, so as to ensure the quality of the workshop, submissions 
SHOULD include slides. Draft slides are acceptable on submission.


Additional information for speakers at OARC 39:

 - Your talk will be broadcast live and recorded for future reference
 - Your presentation slides will be available for delegates and others 
to download and refer to, before, during and after the meeting
 - Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. 
It would be very useful to have your slides (even if draft) ready for 
this.


Note: DNS-OARC provides registration fee waivers for the workshop to 
support those who are part of underrepresented groups to speak at and/or 
attend DNS-OARC. More details will be provided when registration opens.



If you have questions or concerns you can contact the Programme 
Committee:


    https://www.dns-oarc.net/oarc/programme

via 

John Todd, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social 
events.  Please contact  if your organization is 
interested in becoming a sponsor.


(Please note that OARC is run on a non-profit basis, and is not in a 
position to reimburse expenses or time for speakers at its meetings.)



--
John Todd - jt...@quad9.net
General Manager - Quad9 Recursive Resolve

Re: dump of NOS config examples

[Vincent Bernat]

Here are some real word configurations: 
https://github.com/jerikan-network/cmdb/tree/generated-public/output 
(including IOS, JunOS and IOS-XR, but no NX-OS).


On 2022-08-20 18:25, guardian.wheel9...@fastmail.com wrote:

Hi,

I am looking for a large dump of example, real but scrubbed, whatever, 
nx-os, junos, panos, ios, eos, hell any common NOS, configs. (Right now 
I really need nx-os but I'll get to the rest soon)


To be clear, I am not looking for anyone's private config or network 
info. I just need a large sample of configs to test some config parsing 
code I have. Looking for every random ugly feature / config option out 
there. The bigger and uglier the better. (Files that still even have the 
horrid control chars ^M, \r\n and worse that come out of network devices 
are the best!!)


Once again, not looking for hack dump of random company X(though I'll 
take anything legal). Hoping to not going fishing in malware infested 
waters for questionable zip files. While I cannot really think of what 
kind of source would give me what I am looking for on the up and up, 
that's what I am hoping for.


Thanx for any help anyone can provide.

Re: dump of NOS config examples

[guardian . wheel9069]

No, config references are not real configs. For the most part they don’t have 
object names, indentation, control chars, or any of the other things you deal 
with in real configs.

Ahh, I had not thought of the practice tests!! That is a great idea. The 
“answer keys” of a bunch of config practice tests should be as close as you get 
to real configs without being real configs. 

Anyone know where a big dump of various vendor practice tests answers are? 

On Sun, Aug 21, 2022, at 2:18 AM, Jay Hennigan wrote:
> On 8/20/22 09:25, guardian.wheel9...@fastmail.com wrote:
> > Hi,
> > 
> > I am looking for a large dump of example, real but scrubbed, whatever, 
> > nx-os, junos, panos, ios, eos, hell any common NOS, configs. (Right now 
> > I really need nx-os but I'll get to the rest soon)
> 
> > To be clear, I am not looking for anyone's private config or network 
> > info. I just need a large sample of configs to test some config parsing 
> > code I have. Looking for every random ugly feature / config option out 
> > there. The bigger and uglier the better. (Files that still even have the 
> > horrid control chars ^M, \r\n and worse that come out of network devices 
> > are the best!!)
> 
> Most vendors publish a command reference document that lists and 
> describes every possible configuration command including all of the 
> random ugly ones.
> 
> Would this be sufficient or are you looking for working random ugly 
> configurations? Vendor certification practice tests could be another source.
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>