Re: idiot reponse

[Selphie Keller]

postfix =)

/^From: .*@electricforestfestival\.com/ DISCARD

On Wed, 26 Feb 2020 at 09:54, Christopher Morrow 
wrote:

>
>
> On Wed, Feb 26, 2020 at 11:46 AM Mike Hammett  wrote:
>
>> I send to nanog-ow...@nanog.org, but I never hear back.
>>
>>
>>
> I had sent this privately but I thought/think: nanog-admin@
>
> I could totally be wrong :)
>

Re: TCP-AMP DDoS Attack - Fake abuse reports problem

[Selphie Keller]

Yeah this type of attack is a pain in the ass to deal with.

Attacker is spoofing your IP addresses to millions of random web servers
all over the Internet that see it as a typical SYN Flood those with
automated reporting are likely blowing up OVH's abuse@ making a pain for
them as well.
However, OVH likely could easily check netflow or some other audit means to
see your server didn't actually send out SYN packets to these servers. They
likely are able to confirm the influx of inbound SYN-ACK packets that can
be up to six depending on the TCP/IP stack of the server.
The others are correct if you send out TCP Reset rejections you can tare
down these bad states on the victim reflector's side to avoid getting retry
SYN-ACK's.

At this point I would consider whatever IP that you have that's getting
attacked as burned, you're best bet is to drop those affected subnets and
get new ones and avoid getting them exposed to whoever is attacking you.

Spoofing issues has been the bane of any operator for years, till all the
ASN's are on board with proper anti spoofing, ddos abuse of spoofing will
be on-going and always an issue.

On Thu, 20 Feb 2020 at 15:18, Octolus Development  wrote:

> A very old attack method called TCP-AMP ( https://pastebin.com/jYhWdgHn )
> has been getting really popular recently.
>
> I've been a victim of it multiple times on many of my IP's and every time
> it happens - My IP's end up getting blacklisted in major big databases. We
> also receive tons of abuse reports for "Port Scanning".
>
> Example of the reports we're getting:
> tcp: 51.81.XX.XX:19342 -> 209.208.XX.XX:80 (SYN_RECV)
> tcp: 51.81.XX.XX:14066 -> 209.208.XX.XX:80 (SYN_RECV)
>
> OVH are threatening to kick us off their network, because we are victims
> of this attack. And requesting us to do something about it, despite the
> fact that there is nothing you can do when you are being victim of an DDoS
> Attack.
>
> Anyone else had any problems with these kind of attacks?
>
> The attack basically works like this;
> - The attacker scans the internet for TCP Services, i.e port 80.
> - The attacker then sends spoofed requests from our IP to these TCP
> Services, which makes the remote service attempt to connect to us to
> initiate the handshake.. This clearly fails.
> ... Which ends up with hundreds of request to these services, reporting us
> for "port flood".
>
>
>

Re: FB?

[Selphie Keller]

Yeah I just saw that date and that is odd, I got the link yesterday from
somewhere and didn't notice the date was old.

They do mention the configuration change issue in this one though that is
dated today 14th -
https://www.cbsnews.com/news/facebook-instagram-down-wednesday-facebook-blames-server-configuration-for-longest-ever-outage/

>From my understanding yesterday is they invalidated their world cache and
all the traffic hit their backend quickly overwhelming their servers. It
was strange that they didn't really talk about the issue just some brief
messages on their twitter saying it wasn't ddos.




On Thu, 14 Mar 2019 at 15:08, Luke Guillory 
wrote:

> That’s old.
>
>
>
> By Robert Johnson on Thursday, September 23, 2010 at 7:29 PM
>
>
>
>
>
> Luke
>
>
>
> Ns
>
>
>
>
>
>
>
> *From:* NANOG [mailto:nanog-boun...@nanog.org] *On Behalf Of *Selphie
> Keller
> *Sent:* Thursday, March 14, 2019 4:06 PM
> *To:* Mike Hammett
> *Cc:* NANOG list
> *Subject:* Re: FB?
>
>
>
> I did see this article indicating they had somehow invalidated their cache
> in a botched deployment of changes -
> https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/
>
>
>
> On Thu, 14 Mar 2019 at 06:18, Mike Hammett  wrote:
>
> So what happened at Facebook today? I saw one article quoting Roland
> saying it was a route leak, but I haven't seen any other sources that
> aren't just quoting Roland. Usually there are a few independent posts out
> there by now.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>
>

Re: FB?

[Selphie Keller]

I did see this article indicating they had somehow invalidated their cache
in a botched deployment of changes -
https://www.facebook.com/notes/facebook-engineering/more-details-on-todays-outage/431441338919/

On Thu, 14 Mar 2019 at 06:18, Mike Hammett  wrote:

> So what happened at Facebook today? I saw one article quoting Roland
> saying it was a route leak, but I haven't seen any other sources that
> aren't just quoting Roland. Usually there are a few independent posts out
> there by now.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>

Re: The root KSK roll has occurred

[Selphie Keller]

Pretty awesome moment in history, confirmed my DNS resolvers are showing
20326. Also, seeing the new key on public resolvers like cloudflare and
level3, google 8.8.8.8 and 8.8.4.4 still have 19036, likely cache.



On Thu, 11 Oct 2018 at 10:07, Mehmet Akcin  wrote:

> Congratulations for rolling the root zone KSK.
>
> On Thu, Oct 11, 2018 at 9:01 AM Matt Larson  wrote:
>
>> On behalf of the root zone management partners (ICANN and Verisign), I
>> would like to report that the root KSK rollover occurred at 1600 UTC today,
>> 11 October, with the publication of the root zone with serial number
>> 2018101100.
>>
>> For the 48 hours after the rollover, we will be monitoring several
>> mailing lists, including this one, so please reply here with any issues or
>> concerns.
>>
>> Matt
>> --
>> Matt Larson, VP of Research
>> ICANN Office of the CTO
>>
>>

Re: Oct. 3, 2018 EAS Presidential Alert test

[Selphie Keller]

I did receive the alert on samsung devices:  note 8 (tmobile), note 3 (no
sim card/no service), and galaxy s6 (verizon)
~12:18 MDT (GMT-6)

On Wed, 3 Oct 2018 at 13:55, Robbie Trencheny  wrote:

> I did not receive on my iPhone or Apple Watch (LTE) either. Both are
> T-Mobile and I'm in Oakland, CA.
>
> On Wed, Oct 3, 2018 at 12:21 Andy Ringsmuth  wrote:
>
>> Did anyone on AT&T or an iPhone receive the test today? I believe it was
>> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 2:20
>> EDT.
>>
>> I’m in CDT, so 1:18 and 1:20 p.m. CDT.
>>
>> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the
>> sending of this at 1:52 p.m. CDT, nothing on phones. I have an office full
>> of AT&T iPhones and not a single one of them alerted.
>>
>> FEMA says https://www.fema.gov/emergency-alert-test
>>
>> "Cell towers will broadcast the WEA test for approximately 30 minutes
>> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones
>> that are switched on, within range of an active cell tower, and whose
>> wireless provider participates in WEA should be capable of receiving the
>> test message. Some cell phones will not receive the test message, and cell
>> phones should only receive the message once."
>>
>> My wife, with a Sprint iPhone, received the test.
>>
>>
>> 
>> Andy Ringsmuth
>> 5609 Harding Drive
>> Lincoln, NE 68521-5831
>> (402) 304-0083
>> a...@andyring.com
>>
>> --
> --
> Robbie Trencheny (@robbie )
> 925-884-3728
> robbie.io
>

Re: Google Captcha

[Selphie Keller]

Yeah google captcha is fun, I trigger this all the time when relentlessly
searching for something, ironically I giggle at the idea that my searching
is so extreme it's classified as a bot at times.

On Fri, 14 Sep 2018 at 10:32, Justin Wilson  wrote:

> In the experience of the community what causes the “Unusual traffic”
> messages when doing google searches? This ISP network hands out public IP
> addresses to each and every customer. No batting going on.  Does Google
> typically drop entire /24’s into this if they see an issue?  The initial
> troubleshooting we have done involves disconnecting the customer router and
> going direct with a laptop.  Still the same captcha.  We clock “I am not a
> robot” and the search goes through, but it re-appaers the next search.
>
> Looking for a direction to look.  What typically causes this? I know what
> the page says, but looking for specifics.
>
> Thanks
>
>
> Justin Wilson
> j...@mtin.net
>
> www.mtin.net
> www.midwest-ix.com
>
>

Re: Packets Broker (aka: WAN Accelerator (aka: Congestion Algorithms (aka: You call yourself a network engineer?) )

[Selphie Keller]

I have some good success with kcptun - https://github.com/xtaci/kcptun it's
designed to handle problematic links.

On 11 December 2017 at 17:34, Alain Hebert  wrote:

> Hi,
>
> We're used to fix Long Fat Network issues ourself...
>
> But I'm stuck in a case where we need to transparently proxy TCP
> connections to apply congestion algorithms (cubic, htcp, etc) since some of
> our newer customers are ... well ... refusing to acknowledge that reality.
>
> Any good lead for a 1U platform averaging ~10Gbps of throughput, that
> isn't some PC hack in a box?
>
> ( off-lists would be nice, unless you think that could be useful to
> others )
>
> Thanks for your time.
>
> --
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> 
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
>

Re: Proxying NetFlow traffic correctly

[Selphie Keller]

samplicate is very good, been using it for 6 years for netflow duplication
using botth the spoofing and non, depending on the sensor's needs if it
needs to retain the source ip or not.



On 6 June 2017 at 20:39, Dobbins, Roland  wrote:

>
>
> On Jun 7, 2017, at 06:32, Sami via NANOG mailto:nanog@
> nanog.org>> wrote:
>
> My goal is to centralize NetFlow traffic into a single machine and then
> proxy some flows to other destinations for further analysis
>
> 
>
> Or nprobe, as was already mentioned.
>
> ---
> Roland Dobbins mailto:rdobb...@arbor.net>>
>

Re: Syn flood to TCP port 21 from priveleged port (80)

[Selphie Keller]

Yeah it is an odd ball attack for sure, here is a 5000 packet sample of
what I was seeing in connection to this attack
https://mystagic.io/80to21.pcap , don't think it's the entire /0 for ftp
port as I am not seeing it on many other subnets, which is why I am
thinking someone did a pre-scan before conducting this wacky attack,
otherwise, I would have likely seen other port 21's seeing activity, but so
far any IP that didn't have 21 as an actual service isn't seeing the syn
packets. This could be unique to my location, others observing this attack
may be able to chime in and report what they are seeing if they seen 80 src
syn to port 21 where 21 isn't an actual ftp running. Yeah this is pretty
easy to filter.

On 1 November 2016 at 13:48, Ken Chase  wrote:

> Not sure why reflected RSTs are the goal here, they're not much of an
> amplification
> to the original syn size. Additionally causing a mild dos of my clients'
> stuff
> when it begins throttling # of connections, ie noticeable. (not that i
> want to
> help scriptkids improve their attacks...). Im guessing port 80 was chosen
> for improved
> fw piercing.
>
> Sure is widespread though, 5 clients on very different networks all seeing
> similar
> saturation. Someone has a nice complete prescanned list of open ftps for
> the
> entire internet out there (or are they just saturating the whole /0?)
>
> Easy to filter though:
>
> tcp and src port 80 and src net '(141.138.128.0/21 or 95.131.184.0/21)'
> and dst port 21
>
> Adapt for your fw rules of choice.
>
> /kc
>
>
> On Tue, Nov 01, 2016 at 07:39:40PM +, Van Dyk, Donovan said:
>   >I think Ken has nailed it. I think the source addresses are spoofed so
> you reflect the connection (tcp syn ack) to those source addresses. Get
> enough of those connections and the server is dead.
>   >
>   >Since your port 21 is open
>   >
>   >telnet 109.72.248.114 21
>   >Trying 109.72.248.114...
>   >Connected to 109.72.248.114.
>   >Escape character is '^]'.
>   >
>   >Your address was probably scanned and saw it could be used in the
> attack.
>   >
>   >Regards
>   >--
>   >Donovan Van Dyk
>   >
>   >SOC Network Engineer
>   >
>   >Office: +1.954.620.6002 x911
>   >
>   >Fort Lauderdale, FL USA
>   >
>   >
>   >
>   >
>   >The information contained in this electronic mail transmission and its
> attachments may be privileged and confidential and protected from
> disclosure. If the reader of this message is not the intended recipient (or
> an individual responsible for delivery of the message to such person), you
> are strictly prohibited from copying, disseminating or distributing this
> communication. If you have received this communication in error, please
> notify the sender immediately and destroy all electronic, paper or other
> versions.
>   >
>   >
>   >On 11/1/16, 3:29 PM, "Ken Chase"  wrote:
>   >
>   >seeing an awful lot of port 80 hitting port 21. (Why would port 80
>   >ever be used as source?). Also saw a buncha cpanel "FAILED: FTP"
> alerts flickering
>   >on and off as the service throttled itself at a couple client sites
> I manage.
>   >
>   >I see 540 unique source IPs hitting 32 destinations on my network
> in just 1000
>   >packets dumped on one router.
>   >
>   >All from multiple sequential registered /24s in whois, but all from
> one
>   >management company:
>   >
>   >141.138.128.0/21 and 95.131.184.0/21
>   >
>   >role:   William Hill Network Services
>   >abuse-mailbox:  networkservi...@williamhill.co.uk
>   >address:Infrastructure Services 2 City Walk Sweet Street
> Leeds LS11 9AR
>   >
>   >AS49061
>   >
>   >course, synfloods can be spoofed... perhaps they're hoping for a
> retaliation
>   >against WHNS.
>   >
>   >/kc
>   >
>   >On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
>   >  >Hello,
>   >  >
>   >  >A couple of cuts from tcpdump output:
>   >  >
>   >  >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags
> [S], seq 1376379765, win 8192, length 0
>   >  >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags
> [S], seq 2254756684, win 8192, length 0
>   >  >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags
> [S], seq 3619475318, win 8192, length 0
>   >  >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags
> [S], seq 2412690982, win 8192, length 0
>   >  >
>   >  >Does anyone seeing this right now (18:31 UTC)? I see this traffic
>   >  >on at least two completely independent ISPs near Moscow. The
>   >  >rate is about a few dozen PPS hitting all BGP-announced networks.
>   >  >
>   >  >--??
>   >  >wbr, Oleg.
>   >  >
>   >  >"Anarchy is about taking complete responsibility for yourself."
>   >  >?? ?? ?? Alan Moore.
>   >
> --
> Ken Chase - m...@sizone.org Guelph Canada
>
>

Re: Syn flood to TCP port 21 from priveleged port (80)

[Selphie Keller]

yeah it looks like the person behind the flood may have scanned for active
ftp servers, not seeing any activity on other observation subnets of this
flood, and so far the only servers showing this port 80 to port 21 is ones
that do have actual ftp servers, however, the connection is not actually
establishing it's only showing SYN incoming and a SYN-ACK outgoing and
never gets a completed 3way handshake, so it could be a very odd reflected
syn-ack flood against possible web servers origin ip addresses.

On 1 November 2016 at 14:28, Emille Blanc 
wrote:

> > Does the synflood have tcp option headers?
>
>
>
> Not seeing any here. From this morning.
>
>
>
> 12:45:46.180665 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok]
> 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40)
>
> 12:45:46.180667 194.73.173.17.80 > 216.57.181.189.21: S [tcp sum ok]
> 1158156467:1158156467(0) win 8192 (DF) (ttl 60, id 18499, len 40)
>
> 12:45:46.284617 141.138.128.137.80 > 216.57.182.18.21: S [tcp sum ok]
> 2595766696:2595766696(0) win 8192 (DF) (ttl 69, id 6478, len 40)
>
>
>
> *From:* Selphie Keller [mailto:selphie.kel...@gmail.com]
> *Sent:* November-01-16 1:13 PM
> *To:* Emille Blanc
> *Cc:* Ken Chase; Oleg A. Arkhangelsky; nanog@nanog.org
>
> *Subject:* Re: Syn flood to TCP port 21 from priveleged port (80)
>
>
>
> Does the synflood have tcp option headers?
>
>
>
> I am seeing this same activity at our forward observation system, however
> it's not showing any tcp options like mss,sack,timestamps etc, was curious
> if others were seeing the same
>
>
>
> [root@oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] ==
> 2)'
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>
> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
>
>
>
> 13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq
> 3599006989, win 8192, length 0
>
> 13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq
> 2409909072, win 8192, length 0
>
> 13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq
> 1006681302, win 8192, length 0
>
> 13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq
> 3627295948, win 8192, length 0
>
> 13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq
> 3627295948, win 8192, length 0
>
> 13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq
> 3818041920, win 8192, length 0
>
> 13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq
> 3584410928, win 8192, length 0
>
>
>
>
>
>
>
>
>
> On 1 November 2016 at 13:52, Emille Blanc 
> wrote:
>
> Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take).
>
> Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at
> boundary, 502 unique sources to 10 destination hosts on our AS.
>
> Obligatory data should this be of use to anyone listening in.
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
> Sent: November-01-16 12:29 PM
> To: Oleg A. Arkhangelsky
> Cc: nanog@nanog.org
> Subject: Re: Syn flood to TCP port 21 from priveleged port (80)
>
> seeing an awful lot of port 80 hitting port 21. (Why would port 80
> ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts
> flickering
> on and off as the service throttled itself at a couple client sites I
> manage.
>
> I see 540 unique source IPs hitting 32 destinations on my network in just
> 1000
> packets dumped on one router.
>
> All from multiple sequential registered /24s in whois, but all from one
> management company:
>
> 141.138.128.0/21 and 95.131.184.0/21
>
> role:   William Hill Network Services
> abuse-mailbox:  networkservi...@williamhill.co.uk
> address:Infrastructure Services 2 City Walk Sweet Street Leeds
> LS11 9AR
>
> AS49061
>
> course, synfloods can be spoofed... perhaps they're hoping for a
> retaliation
> against WHNS.
>
> /kc
>
> On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
>   >Hello,
>   >
>   >A couple of cuts from tcpdump output:
>   >
>   >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S],
> seq 1376379765, win 8192, length 0
>   >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S],
> seq 2254756684, win 8192, length 0
>   >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S],
> seq 3619475318, win 8192, length 0
>   >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq
> 2412690982, win 8192, length 0
>   >
>   >Does anyone seeing this right now (18:31 UTC)? I see this traffic
>   >on at least two completely independent ISPs near Moscow. The
>   >rate is about a few dozen PPS hitting all BGP-announced networks.
>   >
>   >--??
>   >wbr, Oleg.
>   >
>   >"Anarchy is about taking complete responsibility for yourself."
>   >?? ?? ?? Alan Moore.
>
> --
> Ken Chase - m...@sizone.org Guelph Canada
>
>
>

Re: Syn flood to TCP port 21 from priveleged port (80)

[Selphie Keller]

Does the synflood have tcp option headers?

I am seeing this same activity at our forward observation system, however
it's not showing any tcp options like mss,sack,timestamps etc, was curious
if others were seeing the same

[root@oakridge-intercept(~)]> tcpdump -nn -i eth0 'tcp and (tcp[13] == 2)'

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:09:32.772506 IP 95.131.190.214.80 > 67.220.207.169.21: Flags [S], seq
3599006989, win 8192, length 0
13:09:32.809446 IP 95.131.185.150.80 > 67.220.207.169.21: Flags [S], seq
2409909072, win 8192, length 0
13:09:33.306737 IP 141.138.133.161.80 > 67.220.207.169.21: Flags [S], seq
1006681302, win 8192, length 0
13:09:33.946427 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq
3627295948, win 8192, length 0
13:09:33.946469 IP 141.138.134.193.80 > 67.220.207.170.21: Flags [S], seq
3627295948, win 8192, length 0
13:09:34.263905 IP 194.73.173.103.80 > 67.220.207.170.21: Flags [S], seq
3818041920, win 8192, length 0
13:09:34.415558 IP 194.73.173.243.80 > 67.220.207.169.21: Flags [S], seq
3584410928, win 8192, length 0




On 1 November 2016 at 13:52, Emille Blanc 
wrote:

> Ditto. Same sources; 141.138.128.0/21 and 95.131.184.0/21 (give or take).
>
> Out of 1000 packet sample taken at 12:45:46 PDT (19:45:46 UTC) at
> boundary, 502 unique sources to 10 destination hosts on our AS.
>
> Obligatory data should this be of use to anyone listening in.
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
> Sent: November-01-16 12:29 PM
> To: Oleg A. Arkhangelsky
> Cc: nanog@nanog.org
> Subject: Re: Syn flood to TCP port 21 from priveleged port (80)
>
> seeing an awful lot of port 80 hitting port 21. (Why would port 80
> ever be used as source?). Also saw a buncha cpanel "FAILED: FTP" alerts
> flickering
> on and off as the service throttled itself at a couple client sites I
> manage.
>
> I see 540 unique source IPs hitting 32 destinations on my network in just
> 1000
> packets dumped on one router.
>
> All from multiple sequential registered /24s in whois, but all from one
> management company:
>
> 141.138.128.0/21 and 95.131.184.0/21
>
> role:   William Hill Network Services
> abuse-mailbox:  networkservi...@williamhill.co.uk
> address:Infrastructure Services 2 City Walk Sweet Street Leeds
> LS11 9AR
>
> AS49061
>
> course, synfloods can be spoofed... perhaps they're hoping for a
> retaliation
> against WHNS.
>
> /kc
>
> On Tue, Nov 01, 2016 at 09:44:23PM +0300, Oleg A. Arkhangelsky said:
>   >Hello,
>   >
>   >A couple of cuts from tcpdump output:
>   >
>   >21:31:54.995170 IP 141.138.131.115.80 > 109.72.248.114.21: Flags [S],
> seq 1376379765, win 8192, length 0
>   >21:31:55.231925 IP 194.73.173.154.80 > 109.72.241.198.21: Flags [S],
> seq 2254756684, win 8192, length 0
>   >21:27:50.413927 IP 95.131.188.179.80 > 109.72.248.114.21: Flags [S],
> seq 3619475318, win 8192, length 0
>   >21:27:50.477014 IP 95.131.191.77.80 > 109.72.248.114.21: Flags [S], seq
> 2412690982, win 8192, length 0
>   >
>   >Does anyone seeing this right now (18:31 UTC)? I see this traffic
>   >on at least two completely independent ISPs near Moscow. The
>   >rate is about a few dozen PPS hitting all BGP-announced networks.
>   >
>   >--??
>   >wbr, Oleg.
>   >
>   >"Anarchy is about taking complete responsibility for yourself."
>   >?? ?? ?? Alan Moore.
>
> --
> Ken Chase - m...@sizone.org Guelph Canada
>
>

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Selphie Keller]

Nick,

Very cool, learn something new every day :)

[root@stellarfrost(~)]> nicinfo 103.11.67.167
# NicInfo v.1.1.1

[ NOTICE ] Terms of Service
 1 By using the ARIN RDAP/Whois service, you are agreeing to the
RDAP/Whois Terms of Use
 About https://www.arin.net/whois_tou.html

# Query type is IP4ADDR. Result type is IP.

[ RESPONSE DATA ]
  1= NET-103-11-67-0-1
 |--- 1= Gaiacom, L.C. ( GL-299 )
 ||--- 1= GCM NY NOC ( GNN-ARIN )
 |`--- 2= GCM NET ABUSE ( GNA35-ARIN )
 `--- 2= Los Angeles NOC ( LAN55-ARIN )

   [ IP NETWORK ]
   Handle:  NET-103-11-67-0-1
Start Address:  103.011.067.000
  End Address:  103.011.067.255
   IP Version:  v4
 Last Changed:  Mon, 13 Jun 2016 15:20:51 -0700
 Registration:  Wed, 25 May 2016 17:17:12 -0700

   [ ENTITY ]
   Handle:  GL-299
 Name:  Gaiacom, L.C.
Roles:  Registrant
 Last Changed:  Fri, 15 Aug 2014 11:26:53 -0700
 Registration:  Wed, 04 Dec 2013 13:01:12 -0800

   [ ENTITY ]
   Handle:  GNN-ARIN
 Name:  GCM NY NOC
 Organization:  GCM NY NOC
Email:  n...@gaiacom.net
Phone:  +1-310-421-9099 ( work, voice )
Phone:  +1-310-421-9098 ( work, fax )
Roles:  Noc, Technical, Administrative
   Status:  Validated
 Last Changed:  Sat, 20 Aug 2016 09:21:23 -0700
 Registration:  Tue, 26 Nov 2013 22:58:12 -0800

   [ ENTITY ]
   Handle:  GNA35-ARIN
 Name:  GCM NET ABUSE
 Organization:  GCM NET ABUSE
Email:  n...@maya.net
Phone:  +1-310-421-9099 ( work, voice )
Phone:  +1-310-421-9098 ( work, fax )
Roles:  Abuse
   Status:  Validated
 Last Changed:  Wed, 03 Aug 2016 13:51:02 -0700
 Registration:  Tue, 26 Nov 2013 23:39:45 -0800

   [ ENTITY ]
   Handle:  LAN55-ARIN
 Name:  Los Angeles NOC
 Organization:  Los Angeles NOC
Email:  n...@maya.net
Phone:  +1-213-587-7995 ( work, voice )
Phone:  +1-213-587-7995 ( work, cell )
Phone:  +1-213-587-7995 ( work, fax )
Roles:  Technical, Noc
   Status:  Validated
 Last Changed:  Mon, 13 Jun 2016 15:14:38 -0700
 Registration:  Mon, 13 Jun 2016 15:14:38 -0700

# Use "nicinfo 1=" to show NET-103-11-67-0-1
# Use "nicinfo 1.1=" to show Gaiacom, L.C. ( GL-299 )
# Use "nicinfo 1.2=" to show Los Angeles NOC ( LAN55-ARIN )
# Use "nicinfo https://rdap.arin.net/registry/ip/103.011.067.000"; to
directly query this resource in the future.
# Use "nicinfo -h" for help.

On 31 October 2016 at 17:21, Nick Hilliard  wrote:

> Selphie Keller wrote:
> > APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would
> show
> > the full chain and a proper abuse contact for this subnet.
>
> the tl;dr on the thread scrollback was:
>
> 1. whois is irredeemably broken
> 2. use rdap, which supports referrals
> 3. open source RDAP client: https://github.com/arineng/nicinfo
>
> Nick
>

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Selphie Keller]

Hi,

I noticed this thread and wanted to provide some information, subnet
103.11.67.0/24 is not an illicit squat this subnet is apart of
103.11.64.0/22 which was transferred from APNIC to ARIN back this last
February and is listed publicly at
https://www.arin.net/knowledge/statistics/transfers.html within the
"Inter-RIR Transfers to the ARIN Region", also WebNX AS18450 does have the
LOA's on file for the subnet.

I do agree with the others in this thread about the lack of WHOIS  as
looking up 103.11.67.0/24 does indeed provide very little information to go
on so I can see how this could be misunderstood as a squat of the subnet
due to the lack of whois information which is an updating issue
ARIN/APNIC's part, hopefully can get this resolved so that ARIN shows the
chain:

APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show
the full chain and a proper abuse contact for this subnet.

As for the spamming/spam email part of this thread, please send the said
spam email/emails with headers in question to ab...@webnx.com, this way we
can investigate and sort it out. We do take spamming seriously and will
work quickly to get it resolved.

-Selphie K