Re: PSA: change your fedex.com account logins

[Steve Atkins]

> On May 31, 2019, at 2:17 PM, Richard  
> wrote:
> 
> 
> 
>> Date: Friday, May 31, 2019 08:04:13 -0400
>> From: Jason Kuehl > 
>> Is it possible, yes. I've seen it several times now at my place of
>> work. Targeted attacks are a thing.
>> 
 
 Dan Hollis wrote:
 
 Phishing scheme didn't happen.
 
 fedex has had a number of major compromises so it's not a
 stretch that their user database was stolen and sold to spammers.
 
> 
> When I have looked into this type of issue for my unique addressing
> some did trace back to back-end db hacks (e.g., adobe), but I found
> that the most likely culprit was the 3rd-party bulk mailer that
> handled the organization's marketing mail. It could be a non-zeroed
> disk thrown into the trash or an inside job, but it almost always
> traced back to one or two bulk mailing companies. 

The most common issue for quite a while was malware on the windows
desktops of employees with access to the companies ESP account.

The web browser saves username and password to autofill the ESPs
web interface in a very predictable place. Malware exfiltrates that. Bad
guys compromise ESP account, download all the lists they can find
(and then start spamming on the company dime).

That's why ESPs pushed quite so hard to get multifactor authentication
of some sort adopted by their customers. But a lot of them didn't do
that (partly, I suspect, because the ESP account was accessed by
multiple employees) and even if they did that didn't stop the lists
that had already been downloaded.

Actual compromises of the ESP, or bad behaviour of it's employees,
seem to be rather rare but customer account compromise is
everywhere.

Cheers,
  Steve

Re: plaintext email?

[Steve Atkins]

/me gestures at this thread

If you needed more reason that NANOG might not be the place to discuss email 
issues at any higher level than port numbers, this is it.

(I especially liked the "I use plain text everywhere!" message sent as HTML).

mailop lives at the perpetually-TLS-challenged 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

ietf-smtp lives at https://www.ietf.org/mailman/listinfo/ietf-smtp

Cheers,
  Steve

Re: Comcast

[Steve Atkins]

> On Jun 29, 2018, at 10:53 AM, Daniel Corbe  wrote:
> 
> Can someone from Comcast contact me off list?
> 
> Your customers can’t reach my network right now.
> 

It's much bigger than just your network, and probably bigger than just Comcast.

They're aware of it, but probably kind of busy.

Cheers,
  Steve

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Steve Atkins]

> On Feb 27, 2018, at 4:29 PM, Filip Hruska  wrote:
> 
> 
> 
> This is just stupid.   
> 
> 
> 
> OVH is one of the largest server providers in the world - of course they will 
> be at the top of that list.   
> 
> What exactly should they do, according to you?

Read their abuse@ alias. Shut down those customers who are being abusive.
Currently they do neither. Every so often they'll privately admit that they've 
been
doing an unconscionably bad job of mitigating abuse from their networks and
promise to do better, then don't.

Given some of their customers have been consistently abusive for years from the 
same
domain and the same IP address the problem isn't "Oh, the bad people keep
signing up with new credit cards! Oh, poor us!" or any other reasoning based on
being a large, inexpensive provider.

> Why should people de-peer them?   

If the overall cost of the bad traffic exceeds the benefit of the good traffic. 
I'm
sure it doesn't, but that people are even suggesting it is telling.

Cheers,
  Steve

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks

[Steve Atkins]

> On Feb 27, 2018, at 1:16 PM, Eric Kuhnke  wrote:
> 
> I question whether there is *any* high volume hoster out there that has a
> reputation for successfully addressing abuse issues coming from their
> customer base, and cuts off services...  By high volume hoster I define it
> as companies where anybody with a credit card can buy a $2 to $15/month
> VPS/VM in a fully automated process.
> 
> OVH just happens to be one of the largest and probably ranks in the top 10
> worldwide by number of hypervisors and VPS. I doubt whether any of their
> 30-40 competitors that are smaller than them do much better, considering
> the ratio of clued and attentive staff to VMs.

OVH are worse than that. Floods of the same spam coming from the
*same IP addresses* for years at a time. Continuous probes. A total refusal
to police their network or even respond to reports of issues.

They're not a major source of abuse because of their size, it's because
they've chosen to be.

Cheers,
  Steve

Re: aggregate6 - a fast versatile prefix list compressor

[Steve Atkins]

> On Dec 1, 2017, at 2:16 AM, Elmar K. Bins  wrote:
> 
> na...@studio442.com.au (Julien Goodwin) wrote:
> 
>>> The first optimisation is to remove any supplied prefixes which are
>>> superfluous because they are already included in another supplied
>>> prefix. For example, 2001:67c:208c:10::/64 would be removed if
>>> 2001:67c:208c::/48 was also supplied.
>>> 
>>> The second optimisation identifies adjacent prefixes that can be
>>> combined under a single, shorter-length prefix. For example,
>>> 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the
>>> single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and
>>> 10.0.1.0/24 can be joined into 10.0.0.0/23.
>> 
>> Will it catch cases like:
>> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22
> 
> I guess the developers will have implemented a loop that runs until no
> more optimizations have been found. Which would of course catch it as
> 
> Iteration 1
> 10.0.0.0/24 + 10.0.1.0/24
> -> 10.0.0.0/23
> 
> Iteration 2
> 10.0.0.0/23 + 10.0.2.0/23
> -> 10.0.0.0/22
> 

The usual trick is to build a prefix tree then walk the tree, which catches
this sort of case in one step.

Cheers,
  Steve

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Steve Atkins]

> On Nov 30, 2017, at 1:22 AM, Bjørn Mork  wrote:
> 
> "John Levine"  writes:
> 
>> Broken rDNS is just broken, since there's approximately no reason ever
>> to send from a host that doesn't know its own name.
> 
> rDNS is not a host attribute, and will therefore tell you exactly
> nothing about the host.

It tells you something about the competence of the operator and
whether the host is intended by the owners to send email.

Or, for a more empirical way to look at it, there's reasonable correlation
between having missing, generic or incorrect reverse DNS and the host
being a source of unwanted or malicious email.

Cheers,
  Steve

Re: Purchased IPv4 Woes

[Steve Atkins]

> On Mar 19, 2017, at 8:32 PM, Justin Wilson  wrote:
> 
> 
> Then you have the lists which want money to be removed.  I have an IP that 
> was blacklisted by hotmail. Just a single IP. I have gone through the 
> procedures that are referenced in the return e-mails.  No response.  My next 
> step says something about a $2500 fee to have it investigated.  I know 
> several blacklists which are this way.  Luckily, many admins do not use such 
> lists.

This reads like you're leaving out some critical details of the story.

Cheers,
  Steve

Re: IPv6 automatic reverse DNS

[Steve Atkins]

> On Oct 28, 2016, at 6:04 PM, Karl Auer  wrote:
> 
>> 1b) anti spam filters believe in the magic of checking
>> forward/reverse match.
> 
> Someone in this thread said that only malware-infested end-users are
> behind IP addresses with no reverse lookup. Well - no. As long as we
> keep telling anyone who isn't running a full-bore commercial network to
> "consume, be silent, die", we are holding everyone back, including
> ourselves.

If you send mail over IPv6 from an address with no reverse DNS you
will see quite a lot of this sort of thing:

550 5.7.1 [*] Our system has detected that this message
5.7.1 does not meet IPv6 sending guidelines regarding PTR records and
5.7.1 authentication. Please review
5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more
5.7.1 information.

> 
> It's fine to use no-reverse-lookup as a component of a spamminess
> score. It's not OK to use it as proof of spamminess.

People running large mailservers made that decision some time
ago. Disagreeing with them won't make them accept your email.

Cheers,
  Steve

Re: IPv6 automatic reverse DNS

[Steve Atkins]

> On Oct 28, 2016, at 4:02 PM, Baldur Norddahl  
> wrote:
> 
> Hello
> 
> Many service providers have IPv4 reverse DNS for all their IP addresses. If 
> nothing is more relevant, this will often just be the IPv4 address hashed 
> somehow and tagged to the ISP domain name. For some arcane reason it is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
> 
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
> 
> It should be simple to build a DNS server that will automatically generate a 
> hostname value for every reverse lookup received, and also be able to parse 
> that hostname value to return the correct IPv6 address on forward lookups.
> 
> Does any DNS server have that feature?

It's easy enough to implement with plugins on some servers.

> Should we have it?

Meh.

> Why not?

Because having an automatically generated reverse DNS is a sign that the IP 
address is not really intended to be offering public services, rather it's a 
malware-infested end user machine.

> 
> I know of some arguments for:
> 
> 1a) mail servers like it

... because it's a sign that the mail is coming from a real mailserver 
configured by a competent admin, rather than being a random compromised 
machine. That's not the case if you're just synthesizing reverse DNS for 
arbitrary IP addresses on your network.

> 
> 1b) anti spam filters believe in the magic of checking forward/reverse match.

For the same reason as above. Spam filters are also often smart enough to 
recognize, and treat as dubious, synthesized reverse DNS.

If you have synthesized reverse DNS on your smarthost you're likely to have a 
bad time, perhaps initially, perhaps the first time someone notices bad mail 
coming from it and doesn't recognize it as a legitimate smarthost.

> 
> 2) traceroute will be nicer

Most of those hosts a traceroute goes through should hopefully have stable IP 
addresses and meaningful, not synthesized, reverse DNS, I'd think. Consumer 
endpoints are the only ones where you might expect that not to be the case and 
synthesized reverse DNS might be an improvement there.

> 
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
> 
> 4) Output from "who" command on Unix will look nicer (maybe).
> 
> Regards,
> 
> Baldur

Cheers,
  Steve

Re: Should abuse mailboxes have quotas?

[Steve Atkins]

> On Oct 27, 2016, at 9:47 AM, Leo Bicknell  wrote:
> 
> In a message written on Thu, Oct 27, 2016 at 08:03:11AM -0700, Stephen 
> Satchell wrote:
>> For the last couple of weeks, every single abuse mail I've tried to send
>> to networks in a very short list of countries has bounced back with
>> "mailbox exceeds quota".  I take this to mean that there isn't someone
>> actively reading, acting on, and deleting e-mail from abuse@.
> 
> Are there any ISP's left that read and respond to abuse@ in a timely
> fashion?  I haven't seen one in at least a decade.  Maybe I e-mail the
> wrong ones.

Lots. There are also quite a lot that don't.

There are also many who you can't easily tell. Mail to abuse@ doesn't
bounce, their abuse issues aren't horrific relative to the size of their
customer base, so they're doing something right. And yet they have
persistently abusive customers who sit on their networks for years.
I've met the abuse staff at quite a few of those, and they're doing good work,
but it's only visible statistically, not on a per-incident level.

If mail to abuse@ doesn't bounce, give them the benefit
of the doubt until statistics say otherwise.

Cheers,
  Steve

Re: "Defensive" BGP hijacking?

[Steve Atkins]

> On Sep 13, 2016, at 12:22 AM, Bryant Townsend  wrote:
> 
> *Events that caused us to perform the BGP hijack*: After the DDoS attacks
> subsided, the attackers started to harass us by calling in using spoofed
> phone numbers. Curious to what this was all about, we fielded various calls
> which allowed us to ascertain who was behind the attacks by correlating
> e-mails with the information they provided over the phone. Throughout the
> day and late into the night, these calls and threats continued to increase
> in number. Throughout these calls we noticed an increasing trend of them
> bringing up personal information of myself and employees. At this point I
> personally filled a police report in preparation to a possible SWATing
> attempt.  As they continued to harass our company, more and more red flags
> indicated that I would soon be targeted. This was the point where I decided
> I needed to go on the offensive to protect myself, my partner, visiting
> family, and my employees. 

I think you're saying that the BGP hijack wasn't done in as part of an attempt 
to
mitigate a DDoS, rather that you used the tools you had available
to go on the offensive in response to phone calls you received. Am I reading
that right?

Cheers,
  Steve

Re: Handling of Abuse Complaints

[Steve Atkins]

> On Aug 29, 2016, at 9:37 AM, Paul Ferguson  wrote:
> 
> I would suggest that violation of the ISP’s ToS should also be consideration, 
> since what may be illegal in one jurisdiction may not be illegal in some 
> other jurisdictions.

Unless your abuse / security desk is staffed by lawyers it's probably better to 
avoid words like "criminal" and "unlawfully" altogether and stick to "in 
violation of our ToS".

> Repeated abuse and violations of an ISP’s ToS should also be a consideration 
> to terminate a customer relationship, and ISPs are fully within their rights 
> to take this type of action.

And don't need to lean on "it's probably illegal" to do so, nor imply that if 
it were legal they wouldn't necessarily enforce their ToS.

(All assuming that being abused as part of a dDoS reflector actually is against 
your ToS. If it's not things get more complex.)

Cheers,
  Steve

> 
> - ferg
> 
> 
> 
>> On Aug 29, 2016, at 9:31 AM, Gareth Tupper  
>> wrote:
>> 
>> "unlawfully" is probably redundant, unless these are otherwise law-abiding 
>> cyber criminals.
>> 
>> /pedant
>> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
>> Sent: Monday, August 29, 2016 9:28 AM
>> To: Jason Lee 
>> Cc: nanog@nanog.org
>> Subject: Re: Handling of Abuse Complaints
>> 
>> Dear Customer,
>> 
>> Cyber criminals are using your network (and ours) to unlawfully attack other 
>> computers on the Internet.
>> 
>> The specific security problem with your DNS server at 127.0.0.1 was first 
>> reported to you on Date1 (original message attached). Please be advised that 
>> we will interrupt network access to that server on Date2.
>> This will likely disrupt your service.
>> 
>> To avoid disruption, please contact me at Email with a mitigation plan no 
>> later than close of business Date3.
>> 
>> I stand ready to assist any way that I can.
>> 
>> Regards,
>> Your Name
>> 
>> 
>> 
>> 
>> 
>> On Mon, Aug 29, 2016 at 11:55 AM, Jason Lee  wrote:
>>> NANOG Community,
>>> 
>>> I was curious how various players in this industry handle abuse complaints.
>>> I'm drafting a policy for the service provider I'm working for about
>>> handing of complaints registered against customer IP space. In this
>>> example I have a customer who is running an open resolver and have
>>> received a few complaints now regarding it being used as part of a DDoS 
>>> attack.
>>> 
>>> My initial response was to inform the customer and ask them to fix it.
>>> Now that its still ongoing over a month later, I'd like to take action
>>> to remediate the issue myself with ACLs but our customer facing team
>>> is pushing back and without an idea of what the industry best practice
>>> is, management isn't sure which way to go.
>>> 
>>> I'm hoping to get an idea of how others handle these cases so I can
>>> develop our formal policy on this and have management sign off and be
>>> able to take quicker action in the future.
>>> 
>>> Thanks,
>>> 
>>> Jason
>> 
>> 
>> 
>> --
>> William Herrin  her...@dirtside.com  b...@herrin.us Owner, 
>> Dirtside Systems . Web: 
>> 
>> 
>> This electronic mail transmission contains information from Warner Pacific 
>> Insurance Services that may be confidential or privileged. Such information 
>> is solely for the intended recipient, and use by any other party is not 
>> authorized. If you are not the intended recipient, be aware that any 
>> disclosure, copying, distribution or use of this message, its contents or 
>> any attachments is prohibited. Any wrongful interception of this message is 
>> punishable as a Federal Crime. If you have received this message in error, 
>> please notify the sender immediately by telephone (800) 801-2300 or by 
>> electronic mail at postmas...@warnerpacific.com.
> 
> —
> Paul Ferguson
> ICEBRG.io
> Seattle, Washington, USA
> 
> 
> 

Re: EVERYTHING about Booters (and CloudFlare)

[Steve Atkins]

> On Jul 27, 2016, at 9:17 AM, Baldur Norddahl  
> wrote:
> 
> Den 27. jul. 2016 17.12 skrev "Steve Mikulasik" :
>> 
>> Disclaimer: I have a ton of respect for Clouldflare and what they do on
> the internet.
> 
> They just lost all respect from here. Would someone from USA please report
> these guys to the feds? What they are doing is outright criminal.

They can monitor (passively or actively) all access to the sites they host, even
the ones that use SSL, and they often use their close working relationship with
law enforcement to explain why they don't terminate bad actors on their network.

You can probably assume that "the feds" are intimately aware of what they're 
doing.

Cheers,
  Steve

Re: cloudflare hosting a ddos service?

[Steve Atkins]

> On Jul 26, 2016, at 7:58 PM, Justin Paine  wrote:
> 
> Folks,
> 
> "For a long time their abuse@ alias was (literally) routed to /dev/null. I'm 
> not
> sure whether that's still the case or whether they now ignore reports 
> manually."
> 
> @Steve   It (literally) never was. :)

Yes, it was. The smiley doesn't make your statement true.

> The team I manage processes
> reports all day
> long. If you have a report to file certainly do so,
> https://www.cloudflare.com/abuse

I gave up on doing that in late 2014 after reporting thousands of pieces of spam
advertising websites hosted by Cloudflare, with no action taken, no reply 
received,
no ticket created, *nothing*. Not in response to mail sent to abuse@cloudflare,
not in response to backchannel reports, not in response to mentions in person to
staff at conferences. (This was mostly people selling lists of credit card 
numbers
rather than booters, but it's the same sort of issue).

Just to see what had changed, I went back to look at the sites I reported to
Cloudflare in 2014. The couple I spot-checked are still hosted by Cloudflare.

Given that you (Cloudflare, rather than you personally) haven't changed
your policy of never terminating abusive websites you host then continuing to
report them to you seems fairly pointless.

> 
> 
> On the topic of booters:
> 
> Short version -- As someone already mentioned, CloudFlare continues
> not to be a hosting provider.

That's untrue, of course. You terminate the http connection; you're
hosting the website; you're hiding the identity of any other operators
involved; you continue to serve the website even when the backing
server has been terminated. Adding an interstitial for sites hosting
malware is nice and all, but the problematic customers are the ones
that are selling access to those malware compromised machines.

You are taking sole responsibility by your actions, while denying all
responsibility in your public statements.

> 
> Our CEO has broadly covered this topic several times.
> https://blog.cloudflare.com/thoughts-on-abuse/
> 
> Even if we removed our service the website does not go away,it
> doesn't solve the problem if we temporarily stop providing DNS to the
> domain(s). An often overlooked but extremely important note: there are
> some situations where law
> enforcement has required that we *not* terminate service to certain
> websites. In those situations we are of course not allowed to discuss
> specifics.

Cheers,
  Steve

Re: cloudflare hosting a ddos service?

[Steve Atkins]

> On Jul 26, 2016, at 7:15 PM, Mehmet Akcin  wrote:
> 
> Have you tried to contact their Abuse?.

For a long time their abuse@ alias was (literally) routed to /dev/null. I'm not
sure whether that's still the case or whether they now ignore reports manually.

Cheers,
  Steve

> 
> mehmet
> 
> On Tue, Jul 26, 2016 at 6:49 PM, Mike  wrote:
> 
>> Hi,
>> 
>>So vbooter.org's dns and web is hosted by cloudflare?
>> 
>> "Using vBooter you can take down home internet connections, websites and
>> game servers such us Minecraft, XBOX Live, PSN and many more."
>> 
>>dig -t ns vbooter.org
>> 
>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;vbooter.org.INNS
>> 
>> ;; ANSWER SECTION:
>> vbooter.org.21599INNSrick.ns.cloudflare.com.
>> vbooter.org.21599INNSamy.ns.cloudflare.com.
>> 
>> dig -t a www.vbooter.org
>> 
>> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 512
>> ;; QUESTION SECTION:
>> ;www.vbooter.org.INA
>> 
>> ;; ANSWER SECTION:
>> www.vbooter.org.299INCNAMEvbooter.org.
>> vbooter.org.299INA104.28.13.7
>> vbooter.org.299INA104.28.12.7
>> 
>> 
>>Can anyone from cloudflare answer me why this fits with your business
>> model?
>> 
>> Mike-
>> 
>> 

Re: Netflix VPN detection - actual engineer needed

[Steve Atkins]

> On Jun 8, 2016, at 8:13 AM, Baldur Norddahl  wrote:
> 
> 
> 
> On 2016-06-08 07:27, Mark Andrews wrote:
>> In message <20160608070525.06fd5...@echo.ms.redpill-linpro.com>, Tore 
>> Anderson writes:
>>> * Davide Davini 
>>> 
>>> Blocking access to Netflix via the tunnel seems like an obvious
>>> solution to me, for what it's worth.
>> And which set of prefixes is that?  How often do they change? etc.
>> 
> 
> A start would be blocking 2620:108:700f::/64 as discovered by a simple DNS 
> lookup on netflix.com. I am not running a HE tunnel (I got native IPv6) and I 
> am not blocked from accessing Netflix over IPv6 so can't really try it. I am 
> curious however that none of the vocal HE tunnel users here appears to have 
> tried even simple counter measures such as a simple firewall rule to drop 
> traffic to that one /64 prefix.
> 
> It might be that more needs to be blocked, but in that case it will be 
> trivial to find the required prefixes by launching Wireshark and observe the 
> IPv6 traffic generated when accessing netflix.com. Maybe someone could do 
> that and post the results, as it is apparent that many people are in need of 
> a solution.

I don't think that "getting to Netflix over an HE  tunnel" is something that 
people here need a solution to, rather it's "stopping Netflix from discouraging 
IPv6 usage" or perhaps "encouraging Netflix to stop breaking service to IPv6 
users, including their lack of support for IPv4 fallback".

The connection to NANOG isn't that NANOG users want to reach Netflix, it's that 
NANOG users have an interest in the broader health of the IPv6 ecosystem.

Given the number of pieces of off-the-shelf packaged software that are designed 
to allow the end-user, with no technical expertise required, to proxy through 
an HE tunnel so as to avoid Netflix geolocation[1] I don't blame Netflix for 
blocking HE tunnels, but I do blame them for doing so badly.

Cheers,
  Steve

[1] e.g. https://github.com/ab77/netflix-proxy

Re: Netflix VPN detection - actual engineer needed

[Steve Atkins]

> On Jun 6, 2016, at 8:21 AM, Tore Anderson  wrote:
> 
> * Spencer Ryan
> 
>> As an addendum to this and what someone said earlier about the
>> tunnels not being anonymous: From Netflix's perspective they are. Yes
>> HE knows who controls which tunnel, but if Netflix went to HE and
>> said "Tell me what user has x/48" HE would say "No". Thus, making
>> them an effective anonymous VPN service from Netflix's perspective.
> 
> Every ISP would say «No» to that question. In sane juridstictions only
> law enforcement has any chance of getting that answer (hopefully only if
> they have a valid mandate from some kind of court).

HE.net run a perfectly good rwhois server which has my town, state, country
and zip code for my personal IPv6 tunnel, just the same as they have
full contact information for my HE-provided business IPv6 space.

> But Netflix shouldn't have any need to ask in the first place. Their
> customers need to log in to their own personal accounts in order to
> access any content, when they do Netflix can discover their addresses.

The content providers are concerned about who is consuming the
content, not who is paying for it. Those needn't be the same people,
and given how careful people are not to share netflix creds with friends,
often won't be.

Netflix could stomp on credential sharing, but they don't seem to particularly
want to. Blocking a few VPN providers seems a figleaf to keep the content
providers happier while inconveniencing relatively few end users - anyone
who's using a VPN or tunnel anyway can probably change things around
to avoid the blocking with little effort.

Cheers,
  Steve

Re: GeoIP database issues and the real world consequences

[Steve Atkins]

> On Apr 11, 2016, at 10:11 AM, Hugo Slabbert  wrote:
> 
> 
> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase  wrote:
> 
>> TL;DR: GeoIP put unknown IP location mappings to the 'center of the country'
>> but then rounded off the lat long so it points at this farm.
>> 
>> Cant believe law enforcement is using this kind of info to execute searches.
>> Wouldnt that undermine the credibility of any evidence brought up in trials
>> for any geoip locates?
>> 
>> Seems to me locating unknowns somewhere in the middle of a big lake or park 
>> in
>> the center of the country might be a better idea.
> 
> ...how about actually marking an unknown as...oh, I dunno: "unknown"?  Is 
> there no analogue in the GeoIP lookups for a 404?

It's not unknown - it's (according to the DB, anyway, which has a bunch of 
flaws) "in the US somewhere".

The problem with MaxMind (and other geoip databases I've seen that do Lat/Long 
as well as Country / State / Town) is that the data doesn't include 
uncertainty, so it returns "38.0/-97.0" rather than "somewhere in a 3000 mile 
radius circle centered on 38.0/-97.0".

Someone should show them RFC 1876 as an example of better practice.

Cheers,
  Steve

Re: outlook.com outgoing blacklists?

[Steve Atkins]

> 
> Anybody have some recommendations on how I resolve this

The most likely explanation is a configuration error at your end, so the first 
step is to share what the domain is.

Cheers,
  Steve

Re: outlook.com outgoing blacklists?

[Steve Atkins]

> On Sep 9, 2015, at 11:43 AM, Steve Atkins <st...@blighty.com> wrote:
> 
> 
>> 
>> Anybody have some recommendations on how I resolve this
> 
> The most likely explanation is a configuration error at your end, so the 
> first step is to share what the domain is.

Todd shared the domain with me privately.

The DNS configuration (and SMTP and TLS) looks fine, with nothing out of the 
ordinary, to me too.

So the next thing to look at would be the rejection message.

Cheers,
  Steve

Re: Remember Internet-In-A-Box?

[Steve Atkins]

 On Jul 14, 2015, at 4:46 PM, Stephen Satchell l...@satchell.net wrote:
 
 This goes back a number of years.  There was a product that literally was a 
 cardboard box that contained everything one needed to get started on the 
 Internet.  Just add a modem and a computer, and you were on your way.  No 
 fuss, no learning curve.
 
 I'm beginning to think that someone needs to create a similar product, but 
 for IPv6 internet.  The Internet service providers would provide the same 
 sort of kit to get people started.  Just add a CSU/DSU (like a cable modem) 
 and a computer, and you are on your way.
 
 Also, I think we need a *real* book called IPv6 for Dummies (maybe even 
 published by IDG Books) that walks through all the beginner stuff.  There's 
 beginner stuff that I've seen by using a search engine; a dead-tree book, 
 though, may well be better for Joe Average.

If a consumer internet connection works I wouldn't expect the typical user to 
have to know that IPv6 exists, let alone anything about it. If you need to 
manually see anything at that level then hasn't the ISP, OS vendor or app 
developer done something horribly wrong?

IPv6 for dummies for app developers and small ISPs, OTOH ...

Cheers,
  Steve

Re: Purpose of spoofed packets ???

[Steve Atkins]

On Mar 10, 2015, at 4:40 PM, Matthew Huff mh...@ox.com wrote:

 We recently got an abuse report of an IP address in our net range. However, 
 that IP address isn't in use in our networks and the covering network is null 
 routed, so no return traffic is possible. We have external BGP monitoring, so 
 unless something very tricky is going on, we don't have part of our prefix 
 hijacked.
 
 I assume the source address was spoofed, but this leads to my question. Since 
 the person that submitted the report didn't mention a high packet rate (it 
 was on ssh port 22), it doesn't look like some sort of SYN attack, but any OS 
 fingerprinting or doorknob twisting wouldn't be useful from the attacker if 
 the traffic doesn't return to them, so what gives?
 
 BTW, we are in the ARIN region, the report came out of the RIPE region.

Either the reporter doesn't know what they're talking about (common enough) or 
someone is scanning for open ssh ports, hiding their real IP address by burying 
it in a host of faked source addresses. That's a standard option on some of the 
stealthier port scanners, IIRC.

Cheers,
  Steve

Re: AOL Postmaster

[Steve Atkins]

On Feb 25, 2015, at 5:54 PM, Suresh Ramasubramanian ops.li...@gmail.com wrote:

 You think every accountant, realtor, coffee shop etc uses their own domain?

No.

But they should not, and in many cases *cannot*, rely on aol or yahoo addresses.

It would suck for them to have to change all their contact information, 
business cards,
and so on - but a) they chose their email provider unwisely and that's the cost 
of
relying on an inappropriate vendor and b) they don't really need to - inbound 
mail to
those addresses is mostly fine, so they just need to get a second email address
and gradually migrate their outbound usage to that.

Because the root cause of this issue is a long series of security mistakes by 
those
providers, allowing 3rd parties to have access to user's (supposedly private) 
account
information, the issue is specific to those providers, and there's no strong 
argument that
other email providers are likely to make the same business choices.

Cheers,
  Steve

Re: Bounce action notifications - NANOG mailing list changes yahoo.com users

[Steve Atkins]

On Oct 10, 2014, at 8:05 AM, Christopher Morrow morrowc.li...@gmail.com wrote:

 On Fri, Oct 10, 2014 at 10:54 AM, Randy Bush ra...@psg.com wrote:
 a better approach would be to recommend that mailing list participants
 who want to actually participate should utilize a mail service
 appropriate for the purpose.
 
 support

+1

 
 to be fair, this means EITHER one which does not DMARC mark messages
 OR one which disrespects DMARC. Right?

One which does not publish DMARC p=reject.

If any recipient honors published DMARC records then every
participant using a domain that publishes DMARC p=reject will
break things.

If your domain publishes p=reject it should not have any users
that participate in mailing lists.

Cheers,
  Steve

Re: Bounce action notifications - NANOG mailing list changes yahoo.com users

[Steve Atkins]

On Oct 10, 2014, at 9:21 AM, Royce Williams ro...@techsolvency.com wrote:

 On Fri, Oct 10, 2014 at 7:31 AM, Steve Atkins st...@blighty.com wrote:
 If your domain publishes p=reject it should not have any users
 that participate in mailing lists.
 
 Like many, I was pretty unhappy (and busy) with the unilateral changes
 made by Yahoo and AOL.  But this understandable stance may change.
 Neither of these domains is known for being heavily saturated with
 geeks.  If Gmail started using p=reject, that might shake the tree a
 little more.
 
 But other than providing more warning, what would have been a better
 way to start eliminating forged senders?  Everything I've read
 indicates that both Yahoo and AOL did this with eyes wide open.
 
 Assuming that eliminating forged senders is the end goal, maybe
 forcing the issue was the only way to move forward?  What other theory
 about their motivation makes sense?

I'm fairly sure that their motivation wasn't anything like that clearly
thought through - but their motivation doesn't really matter.

Mailing list operators are stuck in the middle, and they have three
reasonable choices. One is to rework their mail systems to selectively
(or unselectively) replace the From: field. That's a lot of work, and
makes the mailing list less usable for all users.

(There's discussion in the DMARC IETF groups about redefining
5322 so as to put what is currently in the Sender: field into the
From: field and creating a new field, that wouldn't be visible to
the user, to contain what is currently in the From: field).

Another is to be very, very careful about not breaking DKIM
signatures on list mail. That's difficult because the
things you have to do or not do change depending on how the
submitted mail is signed (and Yahoo in particular have made
some signing choices that make it particularly hard).

The third option is to reject submissions from domains that publish
p=reject (or, probably, p=quarantine), pushing the customer support
costs onto those who are publishing p=reject records for users
that participate in mailing lists.

Cheers,
  Steve

Re: Belkin Router issues this morning?

[Steve Atkins]

On Oct 7, 2014, at 8:34 AM, Justin Krejci jkre...@usinternet.com wrote:

 https://twitter.com/search?q=%23belkin
 
 Sounds like a bad firmware update most likely.
 Presumably the Belkin routers perform caching DNS for the LAN clients for if 
 the LAN clients use alternate DNS servers (OpenDNS, Google, your ISPs, etc) 
 there are no longer any issues for those devices, as reported by several 
 random people on the Internet.

Over on outages, someone mentioned that heartbeat.belkin.com was unreachable 
from some areas, and that was causing their routers to shut down.

Cheers,
  Steve

Re: More Godaddy DNS and whois server issues?

[Steve Atkins]

On Sep 4, 2014, at 9:22 AM, Mark Keymer m...@viviotech.net wrote:

 Hi,
 
 So this started a little while ago but seems to be getting worse.
 
 What I am seeing is dns servers over at godaddy not replying however I seem 
 to be able to traceroute ok to them. Also I have started to see that the 
 whois.godaddy.com servers also seem to be having issues as well with Whois 
 information is currently unavailable.  Please try again later.
 
 Anyone else also seeing issues this morning? And able to confirm the issue is 
 with godaddy?

I've seen reports of this for a week or so, with the symptoms looking like 
overly aggressive abuse / query rate handling - packets from networks 
containing busy resolvers being blocked.

Grapevine tells me that they don't think they're doing it intentionally (maybe 
they outsourced something and it broke?).

Cheers,
  Steve

Re: Ebay/Paypal blocking HTTP access based on SORBS DUHL / Spamhaus PBL

[Steve Atkins]

On Aug 21, 2014, at 6:23 AM, Tarko Tikan ta...@lanparty.ee wrote:

 hey,
 
 For a while now, we have been getting complains from our broadband customers 
 about not being able to reach ebay.com/paypal.com
 
 We have nailed it down to some small prefixes and they are all listed in 
 SORBS DUHL / Spamhaus PBL and have been listed for ages. These are indeed 
 dynamic IP pools and should not send any email (not that SMTP has anything to 
 do with HTTP).
 
 For some reason, it looks like ebay/paypal is now blocking HTTP access based 
 on these blacklists.

That seems really unlikely. If they were blocking access purely due to it being 
from dynamically assigned ranges, someone else would have noticed.

High fraud rate or other misbehaviour from those ranges seems more likely.

Can you share the data that makes you think it's the former?

 Does anyone have working contact in their NOC or with security people? All 
 emails to public contacts have not been answered to.

Cheers,
  Steve

Re: SORBS contact?

[Steve Atkins]

On Mar 22, 2011, at 12:21 PM, Mike wrote:

 On 03/22/2011 12:14 PM, Paul Graydon wrote:
 On 03/22/2011 09:07 AM, Chris Conn wrote:
 Hello,
 
 Thank you to all that answered, all helpful info. Surprisingly minutes
 after my Nanog post, a couple of my tickets saw action and the /24 was
 finally removed a short while later.
 
 Thanks again,
 
 Chris
 
 Woah... *collapses on the floor in shock* SORBS actually did something?!
 Quick, buy a lottery ticket before your luck changes!
 
 Paul
 (one of many fed up of dealing with SORBS)
 
 
 Yeah +1 to that. What we need an RBL that lists any mail server that USES 
 sorbs for filtering decisions.

Cut GFI a little slack, at least for a few more weeks.

They seem to have made some decent decisions w.r.t. SORBS very recently and 
it's likely that things will be improving, at least as far as SORBS policies 
and support responsiveness are concerned.

They may yet screw it up, but give them a chance to demonstrate otherwise.

Cheers,
 Steve

Re: Request Spamhaus contact

[Steve Atkins]

On Jan 17, 2011, at 4:42 PM, Jeffrey Lyon wrote:

 I fat fingered the netmask, try now.

Mmm hmm.

  platter steve$ telnet 208.64.127.78 80
  Trying 208.64.127.78...
  Connected to 208.64.127.78.
  Escape character is '^]'.
  HEAD / HTTP/1.1
  Host: viagra-shopping.com

  HTTP/1.1 301 Moved Permanently
  Cache-Control: private
  Content-Length: 0
  Location: http://www.viagra-shopping.com/Home.aspx
  Server: Microsoft-IIS/7.0
  X-AspNet-Version: 4.0.30319
  X-Powered-By: ASP.NET
  Date: Tue, 18 Jan 2011 00:57:55 GMT
  Connection: close

If you've given spamhaus the same sort of response you're
showing here I'm not surprised they're not prioritizing dealing
with you.

Cheers,
  Steve


 
 Thanks, Jeff
 
 
 On Mon, Jan 17, 2011 at 7:39 PM, Raymond Dijkxhoorn
 raym...@prolocation.net wrote:
 Hi!
 
 We've acted on every report that we're aware of and instead you want
 to play pharmacy domain scavenger hunt. This domain at 208.64.120.197
 redirects to IP space we already null routed. It's the same customer.
 
 Either you place strange nullroutes or you did not at all.
 
 [root@mi10 tmp]# wget -S www.vertrouwdeapotheek.nl
 --01:37:29--  http://www.vertrouwdeapotheek.nl/
   = `index.html'
 Resolving www.vertrouwdeapotheek.nl... done.
 Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
 HTTP request sent, awaiting response...
  1 HTTP/1.1 301 Moved Permanently
  2 Cache-Control: private
  3 Content-Length: 0
  4 Location: http://www.vertrouwdeapotheek.nl/Home.aspx
  5 Server: Microsoft-IIS/7.0
  6 X-AspNet-Version: 4.0.30319
  7 X-Powered-By: ASP.NET
  8 Date: Tue, 18 Jan 2011 00:37:04 GMT
  9 Connection: close
 Location: http://www.vertrouwdeapotheek.nl/Home.aspx [following]
 --01:37:29--  http://www.vertrouwdeapotheek.nl/Home.aspx
   = `Home.aspx'
 Connecting to www.vertrouwdeapotheek.nl[208.64.120.197]:80... connected.
 HTTP request sent, awaiting response...
 
 Does this look as its nullrouted?
 
 P.S. Someone at Spamhaus PLEASE remove the /21 listing?
 
 I highly doubt. There is much more to clean on your network before i hope
 they would even reconsider.
 
 Bye,
 Raymond.
 
 
 
 
 -- 
 Jeffrey Lyon, Leadership Team
 jeffrey.l...@blacklotus.net | http://www.blacklotus.net
 Black Lotus Communications - AS32421
 First and Leading in DDoS Protection Solutions
 

Re: network name 101100010100110.net

[Steve Atkins]

On Oct 17, 2010, at 7:16 PM, James Hess wrote:

 On Sat, Oct 16, 2010 at 11:46 PM, Day Domes daydo...@gmail.com wrote:
 I have been tasked with coming up with a new name for are transit data
 network.  I am thinking of using 101100010100110.net does anyone see
 any issues with this?
 
 The domain-name starts with a digit, which is not really recommended,  RFC 
 1034,
 due to the fact a valid actual hostname  cannot start with a digit,

A valid actual hostname can start with a digit. Many do.
I'm guessing 3com may have had something to do with
that trend.

RFC 1123 2.1 clarified that a couple of decades ago, so I doubt
you'll find any running software that doesn't agree.

 and, for example,
 some MTAs/MUAs,  that comply with earlier versions of standards still in use,
 will possibly have a problem  sending e-mail to the flat domain, even
 if the actual hostname is
 something legal such as mail.101100010100110.net.
 
 Which goes back to one of the standard-provided definitions of domain
 name syntax used by RFC 821 page 29:

There are several less obsolete RFCs that specify email addresses,
they're all quite specific about what a valid hostname is in an email
sense. 5321 is the latest, I think, section 4.1.2.

Cheers,
  Steve

Re: [policy] When Tech Meets Policy...

[Steve Atkins]

On Aug 15, 2007, at 12:38 PM, Al Iverson wrote:



On 8/15/07, Barry Shein [EMAIL PROTECTED] wrote:

I am not sure tasting is criminal or fraud.


Neither am I, we agree. I meant if there's subsequent criminality or
fraud that should be dealt with separately.


Dumb question, not necessarily looking to call you or anyone out, but
I'm curious: What valid, legitimate, or likely to be used non-criminal
reasons are there for domain tasting?


Working out which domains tend to get a lot of traffic, so that
you can put profitable content on those that tend to have people
stumble across them.

This is definitely not criminal. It's certainly a valid, legitimate
business approach under the current domain registration
model.


Then my next question is, what reasons are there where it'd be
wise/useful/non-criminal to do it on a large scale?


It's only likely profitable to do the above if you can amortize
your fixed costs over a fair number of profitable domains, and
you'll likely need to measure traffic on a large number of
domains to find those.

(My understanding was that most, if not all, of the domain
tasting churn was actually done by registrars, either directly
or using a partner to do the grunt work. That would mean
that the costs were offloaded onto the registry. ICBW.)

Cheers,
  Steve

Re: [policy] When Tech Meets Policy...

[Steve Atkins]

On Aug 13, 2007, at 12:28 PM, Sean Donelan wrote:



On Mon, 13 Aug 2007, Chris L. Morrow wrote:

but today that provision is: If you buy a domain you have 5 days to
'return' it. The reason behind the return could be: oops, I  
typo'd or
hurray, please refund me for the 1M domains I bought 4.99 days  
ago!. The

'protect the consumer' problem is what's enabling tasting.


So combine these ideas with the possibility that someone will claim  
various consumer protection laws apply to these transactions and  
want to cancel the contract within three days.


The whole consumer protection thing is bit of a red herring.



Instead, why don't we have a three day waiting period when the  
domain is
reserved but not active.   Grandma could notice her typo, credit  
card processor's could notice fake card numbers, and so on and  
rescind the registration.


The typo-or-whatever is likely not to be noticed until the domain is  
actually in use, assuming

that such a thing ever actually happens.



After three days the sale is final.  Only then the name is made  
active in the zone files.


Do people really not plan that far ahead, that they need brand new  
domain names to be active (not just reserved) within seconds?


Yes. Legitimately so, too. Sometimes because of mistakes, sometimes  
because someone sees

a need for a new domain name, and is ready to use it the same day.

The problem is not instant registrations. The problem is free  
registrations.


Cheers,
  Steve

Re: too many variables

[Steve Atkins]

On Aug 9, 2007, at 12:09 PM, Leigh Porter wrote:




Yes a very big unless. Multi-core processors are already available  
that would make very large BGP convergence possible. Change the  
algorithm as well and perhaps add some multi-threading to it and  
it's even better.


Anyone have a decent pointer to something that covers the
current state of the art in algorithms and (silicon) router
architecture, and maybe an analysis that shows the reasoning
to get from those to realistic estimates of routing table size limits?

Cheers,
  Steve




--
Leigh Porter


Patrick Giagnocavo wrote:



On Aug 9, 2007, at 12:21 PM, [EMAIL PROTECTED] wrote:


so putting a stake in the ground, BGP will stop working @ around
2,500,000 routes - can't converge...  regardless of IPv4 or  
IPv6.

unless the CPU's change or the convergence algorithm changes.


That is a pretty big unless .

Cordially

Patrick Giagnocavo
[EMAIL PROTECTED]

Re: large organization nameservers sending icmp packets to dns servers.

[Steve Atkins]

On Aug 6, 2007, at 10:21 AM, John Levine wrote:




Sounds like one of the global-scale load balancers - when you do a
(presumably) recursive DNS lookup of one of their hosts, they'll  
ping

the nameserver from several locations and see which one gets an
answer the fastest.


Why would they ping rather than just sending the query to all of the
NS and see which one answers first?  It's an IP round trip either way.

I agree that pinging is harmless, but for this application it seems
pointless, too.


Well... we're talking about recursive resolvers. There's not
really a simple way for a third party to measure the round trip time to
the recursive resolver at the dns level.

It may not respond to external queries at all, and even if it does,
what query would you send that would cause an immediate reply
without any additional processing or network latency at the resolver?

There's lots of tricks you can play to do this, but most of them are
no better than a simple ICMP ping.

Cheers,
  Steve