My DDoS attack: the rest of the story

From: Aldemaro Campos <aldemaro@hostzone.com.br> 
Sent: Monday, November 11, 2024 2:27 PM
To: Greg Scott <GregScott@infrasupport.com>
Subject: RE: Tonight, somebody using A2 Telecom Eireli and Hostzone Tecnologia in Brazil is launching a SYN flood DDOS attack against me. Please make it stop.

Greg,

Unfortunately there is no way to track down the source of these attacks.

The whole concept behind these kind of attacks is that the malicious actor will craft a special packet spoofing the source address, so the packets are "untraceable", as the header of the packet is fabricated.

In this attack where your server was used for reflection we received over 100Gbps of malicious traffic during a 10 hour window. Unfortunately, there is not much we can do to protect ourselves other than mitigating these attacks using specialized software and hardware.

You, as an intermediary victim, can, however, check your webserver software to fix the vulnerability that allows an attacker to use it during the attack. If you are not already using it, now is the time to use services like CloudFlare to protect your site from new attacks like this in the future.

Best regards,

Aldemaro Campos
+55 11 94181-4750
aldemaro@hostzone.com.br

A common DDoS enemy

Those Brazilian internet service providers were DDoS victims, not perpetrators. Some clown out there used me, and others like me, as drones to attack Brazil. And then it got worse.

Another DDoS attack came in on Thursday, Nov. 14. I did a whois lookup on the IP Address range – another Brazilian ISP – and emailed their abuse contacts. I also emailed the abuse contacts for my internet service provider (ISP), Century Link/Lumen.

And then on Friday, Nov. 15, the hammer dropped with yet another DDoS attack shortly before midnight. This time, as I did my whois lookup, my internet service completely died. I logged a service call with the CenturyLink 24X7 support service.

I host my email server, my dgregscott.com website, my Infrasupport.com website, my Bullseyebreach.com website, and a few other services in virtual machines inside hypervisors in my basement.

CenturyLink brought my internet connection back alive shortly after I logged my service call. But I didn’t realize until early Saturday morning, Nov. 16, that CenturyLink only brought my internet connection partially back alive. I could reach out, but nobody from the outside could reach me. My email server and websites were dead to the world.

DDoS Bungling phase 1

I called Century Link again Saturday morning and explained the problem. Century Link dispatched somebody to deliver a new internet router to me. The problem didn’t feel like a bad router, but hey, when somebody offers a brand-new router, the right answer is yes.

The technician arrived a couple hours later and set it up while I multi-tasked with technical support and family issues. Somewhere in here, my Century Link telephone support call dropped.

I set the router up with its block of static IP Addresses, just like I’ve done dozens of times before over more than 20 years of dealing with Century Link DSL and now fiber service. No change in behavior. I could reach outside, nobody could reach inside.

DDoS Bungling phase 2

I called CenturyLink back and explained my problem from scratch all over again. But nobody understood m problem or what a DDoS attack was. After explaining several times that nobody could reach my websites that I host here, at my home, the support rep insisted my internet connection was fine, and if I couldn’t reach my website, I should contact my web developer. I asked for a supervisor, and after waiting on hold several minutes, we went round and round and round dozens of times like a broken record. We spent around six hours on the phone, but I could not find the right words to make anyone from this group understand my problem. Believe me, I tried. I tried so hard I almost made the supervisor cry.

And then it got worse. The supervisor told me they have no weekend escalation channel. There was nobody else to call. Nobody would work the problem. My internet connection was fine. If I wanted more help, I could wait until Monday when everyone was back at work again. And have a nice afternoon.

I drove to the CenturyLink central office on the other side of my fiber connection and pounded on the door. It’s only a couple miles away. I did this a few years ago when nobody would fix a DSL outage. But this time, the parking lot was empty and nobody answered the door.

My only recourse – cool my heels until Monday and hope somebody worked the problem.

Outrageous is not a strong enough word. How can an entire group that does internet support for a living not know the difference between me reaching out to the internet and the internet reaching in to services I host here? And what good is 24×7 support when it offers zero support?

Taking charge (or trying to)

I did some homework and learned that Kate Johnson recently took the helm as Century Link CEO. I knew this email would probably disappear into a black hole, but I sent it anyway. Even when the odds of a successful outcome are slim, taking no action reduces the odds to zero.

From: Greg Scott 
Sent: Saturday, November 16, 2024 1:53 PM
To: 'fast.conection@yahoo.com.br' <fast.conection@yahoo.com.br>; 'domains@centurylink.com' <domains@centurylink.com>; 'domainabuse@cscglobal.com' <domainabuse@cscglobal.com>; 'engenhariaeletrica.odecio@hotmail.com' <engenhariaeletrica.odecio@hotmail.com>; 'security@lvnetwork.com.br' <security@lvnetwork.com.br>; 'mail-abuse@cert.br' <mail-abuse@cert.br>; 'cert@cert.br' <cert@cert.br>; 'kate.johnson@lumen.com' <kate.johnson@lumen.com>
Cc: 'Aldemaro Campos' <aldemaro@hostzone.com.br>
Subject: RE: 2024-1116 We are again victims of another reflection SYN flood DDOS attack. Century Link case number 799787450

I am probably wasting my time trying to email CenturyLink automation, but in case a live person sees this, I need to express my **extreme** disappointment with CenturyLink support on this incident. Somebody attacked me again last night as part of a larger DDOS SYN flood reflection attack against various ISPs in Brazil. The attack against me ended when my internet service went completely down. Internet service came back a few minutes later, but pings to my upstream router at IP address 207.109.2.10 took between 2000 and 6000 milliseconds. These pings should take around 15 milliseconds. My internet service dropped again, and when it came back up, nobody from the outside could access anything I’m hosting inside. I set up my three websites and email server many years ago behind my firewall and they all worked fine until the incident last night. Now, something upstream from me blocks access to these services. 

I spent all morning and into the afternoon US Central time trying to persuade Century Link support to fix whatever it was that you broke after the attack last night – see the email string below for details. I failed. The support team and supervisor said over and over and over and over again that Century Link has no ability to block access to websites and everything is fine. But everything is not fine. After the attack last night, you blocked access to everything I am hosting here, and apparently I have no means to persuade you to restore whatever you broke, because I am unable to find anyone who will acknowledge you broke it. 

I suspect the culprit is in your equipment at the next hop upstream from me, at IP Address 207.109.2.10.

I’ve been a Century Link customer since the US West days and I’ve paid for business class service and a block of static IP Addresses for 19 years. I was the first person in Eagan, Minnesota to sign up for Century Link (now Lumen) fiber back in 2018. But this incident will make me re-evaluate my choices going forward. How does an ISP not offer service beyond basic connectivity over a weekend – and especially service to fix something it broke overnight on a Friday night? A simple packet trace would show you where the problem lies, but I am unable to find anyone inside Century Link willing or able to even do that. Do you treat all of your customers with this same disdain?

If you respond via email, I won’t see it until you unblock what you blocked. You can call me if you want. My cell phone number is +1-xxx-xxx-xxxx. Or you can email my work email at xxxxxx@xxxxxx.com. 

-	Greg

Greg Scott
gregscott@infrasupport.com
https://www.dgregscott.com
Direct 1-xxx-xxx-xxxx

Real superheroes are ordinary people who step up.

An IT professional’s job is like stocking toilet paper. Nobody cares until there’s an outage.
-	“Virus Bomb” epigraph from 2018.

Check out “Bullseye Breach,” “Virus Bomb,” and “Trafficking U,” available from booksellers everywhere.

From: Greg Scott 
Sent: Saturday, November 16, 2024 11:42 AM
To: 'fast.conection@yahoo.com.br' <fast.conection@yahoo.com.br>; 'domains@centurylink.com' <domains@centurylink.com>; 'domainabuse@cscglobal.com' <domainabuse@cscglobal.com>; 'engenhariaeletrica.odecio@hotmail.com' <engenhariaeletrica.odecio@hotmail.com>; 'security@lvnetwork.com.br' <security@lvnetwork.com.br>; 'mail-abuse@cert.br' <mail-abuse@cert.br>; 'cert@cert.br' <cert@cert.br>
Cc: 'Aldemaro Campos' <aldemaro@hostzone.com.br>
Subject: RE: 2024-1116 We are again victims of another reflection SYN flood DDOS attack

I also should have mentioned – if you respond to this via email, until Century Link fixes whatever it did to block access to my email server and web servers, I won’t see it. Because email flows out, but new email does not flow in. When I do traceroutes from outside, the traceroutes die at my Century Link router at 216.160.2.158.

I logged a support case on this last night and I’ve been on the phone all morning with Century Link. The case number is 799787450. Naturally, the support team tells me everything is fine and nobody changed anything. But somebody changed something because somebody changed my Century Link router configuration last night and I learned this morning that Century Link has the ability to push config changes into these on-premise routers. 

Blocking your customer and then telling your customer that everything is fine is a bad way to fight DDOS attacks and a horrible way to preserve customer goodwill. Please fix this.

Greg Scott 
gregscott@infrasupport.com
https://www.dgregscott.com
Direct 1-xxx-xxx-xxxx

Real superheroes are ordinary people who step up.

An IT professional’s job is like stocking toilet paper. Nobody cares until there’s an outage.
-	“Virus Bomb” epigraph from 2018.

Check out “Bullseye Breach,” “Virus Bomb,” and “Trafficking U,” available from booksellers everywhere.

From: Greg Scott 
Sent: Saturday, November 16, 2024 11:14 AM
To: 'fast.conection@yahoo.com.br' <fast.conection@yahoo.com.br>; 'domains@centurylink.com' <domains@centurylink.com>; 'domainabuse@cscglobal.com' <domainabuse@cscglobal.com>; 'engenhariaeletrica.odecio@hotmail.com' <engenhariaeletrica.odecio@hotmail.com>; 'security@lvnetwork.com.br' <security@lvnetwork.com.br>; 'mail-abuse@cert.br' <mail-abuse@cert.br>; 'cert@cert.br' <cert@cert.br>
Cc: 'Aldemaro Campos' <aldemaro@hostzone.com.br>
Subject: RE: 2024-1116 We are again victims of another reflection SYN flood DDOS attack

Guys, after I emailed this last night, Century Link apparently rebooted my default gateway router at IP Address 207.109.2.10. Now nobody can access anything I host inside here, including my email server and three websites. While I am willing to help battle DDOS attacks, I am not willing to become a double-victim from my own ISP. 

Email stopped flowing into here right after the Century Link reboot. And now, nobody can access my website at https://www.dgregscott.com.

C’mon guys, I’m paying you every month for internet service. Please stop blocking access into the sites I host here.

-	Greg

Greg Scott
gregscott@infrasupport.com
https://www.dgregscott.com
Direct 1-xxx-xxx-xxxx

Real superheroes are ordinary people who step up.

An IT professional’s job is like stocking toilet paper. Nobody cares until there’s an outage.
-	“Virus Bomb” epigraph from 2018.

Check out “Bullseye Breach,” “Virus Bomb,” and “Trafficking U,” available from booksellers everywhere.

From: Greg Scott 
Sent: Saturday, November 16, 2024 2:04 AM
To: 'fast.conection@yahoo.com.br' <fast.conection@yahoo.com.br>; 'domains@centurylink.com' <domains@centurylink.com>; 'domainabuse@cscglobal.com' <domainabuse@cscglobal.com>; 'engenhariaeletrica.odecio@hotmail.com' <engenhariaeletrica.odecio@hotmail.com>; 'security@lvnetwork.com.br' <security@lvnetwork.com.br>; 'mail-abuse@cert.br' <mail-abuse@cert.br>; 'cert@cert.br' <cert@cert.br>
Cc: 'Aldemaro Campos' <aldemaro@hostzone.com.br>
Subject: 2024-1116 We are again victims of another reflection SYN flood DDOS attack

Hi all – Another day, another reflection SYN flood DDOS attack. But this time, as I was working on another whois lookup, my internet connection dropped shortly before midnight US Central time. I logged a service call with CenturyLink, case number 799787450, and the internet came back alive while we talked. Sort of. As I compose this email, volume into my premise is very low. However, something ugly is going on inside CenturyLink/Lumen outside my visibility, because round trip ping times to anywhere range between 3000-6000 milliseconds.

Here is a tcpdump snippet from the original attack before I did my whois lookup to find the victim ISP.

23:46:50.936344 IP 192.140.11.159.3964 > 216.160.2.132.443: Flags [S], seq 2881900917, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.936956 IP 216.160.2.132.443 > 192.140.11.118.29440: Flags [S.], seq 1309069755, ack 2273740602, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.937009 IP 216.160.2.132.443 > 192.140.9.228.35502: Flags [S.], seq 1299723605, ack 1641541864, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.937111 IP 216.160.2.132.443 > 192.140.11.159.3964: Flags [S.], seq 2588337982, ack 2881900918, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.937563 IP 216.160.2.132.443 > 192.140.8.218.52287: Flags [S.], seq 4078877877, ack 1459070738, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.938612 IP 192.140.10.235.61294 > 216.160.2.132.443: Flags [S], seq 713778827, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.938887 IP 216.160.2.132.443 > 192.140.10.235.61294: Flags [S.], seq 2313248930, ack 713778828, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.942560 IP 216.160.2.132.443 > 192.140.8.177.28919: Flags [S.], seq 1157694261, ack 499318878, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.943645 IP 216.160.2.132.443 > 192.140.11.180.25760: Flags [S.], seq 4086532664, ack 2775941784, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.943657 IP 216.160.2.132.443 > 192.140.9.18.42283: Flags [S.], seq 2220883336, ack 2240592923, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
23:46:50.947660 IP 216.160.2.132.443 > 192.140.8.192.22893: Flags [S.], seq 573816928, ack 2440641754, win

My internet connection completely died before I was able to stop my reflection to Brazil.

As I compose this email two hours after the initial attack, here is a sample of pings to the nearest CenturyLink router to me. Note the ugly milliseconds.

64 bytes from 205.171.3.65: icmp_seq=1292 ttl=60 time=5191 ms
64 bytes from 205.171.3.65: icmp_seq=1293 ttl=60 time=4975 ms
64 bytes from 205.171.3.65: icmp_seq=1295 ttl=60 time=4029 ms
64 bytes from 205.171.3.65: icmp_seq=1297 ttl=60 time=2984 ms
64 bytes from 205.171.3.65: icmp_seq=1298 ttl=60 time=2971 ms
64 bytes from 205.171.3.65: icmp_seq=1299 ttl=60 time=3817 ms
64 bytes from 205.171.3.65: icmp_seq=1300 ttl=60 time=3840 ms
64 bytes from 205.171.3.65: icmp_seq=1301 ttl=60 time=3769 ms
64 bytes from 205.171.3.65: icmp_seq=1303 ttl=60 time=2902 ms

I hope we can work together to nail whoever is doing this. 

-	Greg

Greg Scott
gregscott@infrasupport.com
https://www.dgregscott.com
Direct 1-xxx-xxx-xxxx

Real superheroes are ordinary people who step up.

An IT professional’s job is like stocking toilet paper. Nobody cares until there’s an outage.
-	“Virus Bomb” epigraph from 2018.

Check out “Bullseye Breach,” “Virus Bomb,” and “Trafficking U,” available from booksellers everywhere.

From: Greg Scott 
Sent: Thursday, November 14, 2024 11:14 PM
To: 'fast.conection@yahoo.com.br' <fast.conection@yahoo.com.br>; 'domainabuse@centurylink.com' <domainabuse@centurylink.com>; 'domains@centurylink.com' <domains@centurylink.com>; 'domainabuse@cscglobal.com' <domainabuse@cscglobal.com>
Cc: 'Aldemaro Campos' <aldemaro@hostzone.com.br>
Subject: We are victims of a reflection SYN flood DDOS attack

Hi – For the past few weeks, somebody is using me as part of a SYN flood DDOS reflection attack against various ISPs in Brazil. The attacker sends millions of SYN packets on TCP port 443 to my email server with forged source IP Addresses belonging to a Brazil ISP, which makes my email server send SYN+ACK replies to Brazil. Brazil “thinks” I am attacking them and I “think” Brazil is attacking me. But the truth is, we have a common enemy. And apparently, this attacker hits Brazil hard by reflecting from web servers across the internet.

When I notice an attack, I block it at my firewall, which stops the reflection from me. But a few days later, it starts up again from another batch of forged source IP Addresses.

Here is a snippet from a tcpdump trace with tonight’s attack. Notice my email server is not responding because I blocked it at my firewall.

19:58:52.303462 IP 45.162.136.215.13483 > 216.160.2.132.443: Flags [S], seq 1767330160, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.306353 IP 45.162.139.196.32089 > 216.160.2.132.443: Flags [S], seq 887314029, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.309468 IP 45.162.136.134.18111 > 216.160.2.132.443: Flags [S], seq 2647279578, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.312395 IP 45.162.136.52.36622 > 216.160.2.132.443: Flags [S], seq 2621653501, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.322777 IP 45.162.138.119.45417 > 216.160.2.132.443: Flags [S], seq 2231383705, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.322780 IP 45.162.138.42.20975 > 216.160.2.132.443: Flags [S], seq 2951667198, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
19:58:52.325613 IP 45.162.138.10.31199 > 216.160.2.132.443: Flags [S], seq 2365642877, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Here is a sample of the volume flying through here during an attack.

[root@infra2020-fw firewall-scripts]# date
Thu Nov 14 07:59:17 PM CST 2024
[root@infra2020-fw firewall-scripts]# iptables -L -v -n | grep 45.162
60290 3135K DROP       0    --  enp2s0 *       45.162.136.0/22      0.0.0.0/0
[root@infra2020-fw firewall-scripts]#
[root@infra2020-fw firewall-scripts]# date
Thu Nov 14 07:59:27 PM CST 2024
[root@infra2020-fw firewall-scripts]# iptables -L -v -n | grep 45.162
62101 3229K DROP       0    --  enp2s0 *       45.162.136.0/22      0.0.0.0/0

I understand this clown floods Brazil with hundreds of gbps with these attacks, by forcing web servers across the internet to reflect against them.

My ISP is Lumen/CenturyLink. I know it’s not easy finding an attacker who tampers with TCP headers, but maybe we can get close to this one. Would it be possible for Century Link to set up a logging mechanism to flag anything entering Century Link with a high volume going to IP Address 216.160.2.132 on TCP port 443? By finding where this flood enters Century Link on its way to me, maybe we can get closer to the real source.

The attacks happen every few days and generally last 30-60 minutes.

Let’s cooperate and nail this clown.

-	Greg

Greg Scott
gregscott@infrasupport.com
https://www.dgregscott.com
Direct 1-xxx-xxx-xxxx

Real superheroes are ordinary people who step up.

An IT professional’s job is like stocking toilet paper. Nobody cares until there’s an outage.
-	“Virus Bomb” epigraph from 2018.

Check out “Bullseye Breach,” “Virus Bomb,” and “Trafficking U,” available from booksellers everywhere.

Searching

Waiting passively for two days for somebody to even begin working the problem was beyond unacceptable. Surely somebody, somewhere inside the CenturyLink 24X7 support department must be available on call. So I searched for phone numbers and found this PDF with names and phone numbers all the way up to vice-president. I made a few calls and found somebody in Arizona, who led to a manager in Boise, who called me Sunday and finally acknowledged my problem. This manager told me that in 22 years at US West > Qwest > CenturyLink > Lumen, they had never seen a problem like mine.

Welcome to the Twilight Zone.

This manager had jury duty Monday, but promised to escalate my case and asked me to call into the technical support number again first thing Monday morning.

Partial Recovery

I called shortly after 7 AM Monday morning US Central time, or shortly after 9 PM in the Philippines. I must have made an impression over the weekend because they remembered me. When the support rep said that I need to contact my web hosting company, I told her to just stop and connect me with a supervisor. A supervisor came on the line after a while and asked me for my domain name. I told her I operate a few domain names. I suppose dgregscott.com is as good as any. She put me on hold and came back a few minutes later and explained that they have no record in their web hosting department of my domain name.

I told her she was talking to the wrong group. I host my websites here. At my home. CenturyLink is my ISP, so my website lives inside CenturyLink. But it lives here, at my home, not inside any CenturyLink hosting service.

And that was when Dale called and took over the case. I don’t have permission to use Dale’s real name.

Dale and I spent the rest of Monday morning and into Monday afternoon working the problem. Dale ordered another new router, and I put my spare router into production. Everything came back alive Monday afternoon. Pent-up email poured in.

Problem solved? Not Quite.

This time, the world could get inside, but I could not go outside. I dug deeper and found I could not translate DNS names from here. I pinged the CenturyLink DNS servers several times and noticed the first few pings always seemed to time out before finally answering. But when pings answered, the round trip milliseconds looked reasonable. I tinkered with using the Google public DNS server at 8.8.8.8 while Dale left to handle another emergency. I was unsuccessful with Google, but then round trip ping times to the CenturyLink DNS servers jumped to 4000+ milliseconds. My DDoS attacker was back. I could translate names again, just slowly.

Dale called back later and the DDoS flood stopped while we talked. Everything worked. But nobody could explain why everything worked again, or why inbound requests for the prior 60+ hours had died at my CenturyLink router.

Root cause analysis. Sort-of.

So, on Wednesday, Nov. 20, I looked into why. I need to label the CenturyLink routers to keep them straight.

• Router 0 – my original. Replaced on Saturday morning, Nov. 16 and returned to CenturyLink.
• Router 1 – the replacement router, delivered Saturday, Nov. 16. Never allowed inbound traffic.
• Router 2 – my spare, bought from eBay several months ago. Went into production Monday afternoon, Nov. 18.
• Router 3 – Dale ordered this one; arrived the afternoon of Wednesday, Nov. 20.

Before sunrise Wednesday morning, I put Router 1 back in place. As expected, it behaved badly by not allowing new traffic from the outside. I put Router 2 back, the one that had worked since Monday, but now it also behaved badly. And, just like that, I was dead to the world again.

Dale and I fought the problem all day Wednesday. Nothing worked, not even Router 3 after it arrived. Dale was out of options. He told me CenturyLink no longer offers service with static IP Addresses and that I was one of only a few customers set up this way. Maybe those routers have a quality problem with static IP Addresses. The only viable solution left was to turn that router into a transparent bridge and use my firewall to handle the PPPoE authentication. This is not supported, but other customers make it work.

Solution

I figured out how to do it Wednesday night. Here are the Linux NetworkManager commands to set up a PPPoE connection named ppp0 with username, “myusername” and password, “mypassword” on the parent physical interface named enp2s0. It needs to be a DHCP client.

nmcli connection add type pppoe con-name ppp0 ifname ppp0 pppoe.parent enp2s0 username myusername password mypassword 802-3-ethernet.mtu 1492
nmcli conn mod ppp0 ipv4.method auto
nmcli conn up ppp0

Here is a script to report whether the PPPoE connection is up or down, courtesy ChatGPT.

#!/bin/sh

# Define the PPPoE interface name
INTERFACE="ppp0"

# Check the status of the interface using nmcli
STATUS=$(nmcli device status | grep "$INTERFACE" | awk '{print $3}')

# Evaluate the status
if [ "$STATUS" == "connected" ]; then
    echo "PPPoE connection $INTERFACE is UP."
else
    echo "PPPoE connection $INTERFACE is DOWN or not managed by NetworkManager."
fi

I moved my email server to a different public IP Address and haven’t seen an attack in almost two weeks. I just checked my firewall log, and I only see the usual probes. Maybe my DDoS attacker may have moved on. Apparently, the small-scale hosting I do here is a lost art. Sooner or later, I’ll probably end up hosting my stuff in a cloud service someplace.

CenturyLink also needs to upgrade its support. Everyone who works in an internet service provider support group should know the difference between hosting a website and accessing somebody else’s website.