Digital Aftershocks: How DDoS Attacks Are Reshaping the Cyber Battleground

The latest NETSCOUT DDoS Threat Intelligence Report (Issue 15: Findings from 1H 2025) paints a stark picture of how distributed denial-of-service (DDoS) attacks have evolved from occasional nuisances to potent instruments of disruption and geopolitical influence. In just the first half of 2025, more than 8 million DDoS attacks were recorded worldwide, with extreme bursts reaching 3.12 Tbps in bandwidth and 1.5 Gpps in packet throughput, underscoring the sheer scale and ferocity of modern attack campaigns. NETSCOUT

A key takeaway from the report is the increasing sophistication and diversity of DDoS threats. Long-standing groups like NoName057(16) continue to launch high-impact campaigns, while emerging actors such as DieNet and Keymous+ leverage DDoS-as-a-service platforms that lower barriers to entry for attackers. These campaigns often coincide with major geopolitical flashpoints and are powered by vast, adaptive botnets that exploit vulnerabilities in IoT devices, servers, and routers.

Beyond sheer volume and complexity, the report highlights how DDoS attacks are now weaponized in conjunction with political and social events, allowing hacktivists and other threat actors to amplify their impact. Attacks average around 18 minutes in duration, but even short bursts can inflict significant disruption on targeted infrastructure and the broader networks that depend on it. The report also shows regional variations in attack intensity and patterns, emphasizing the global and uneven nature of the threat landscape.

Finally, NETSCOUT stresses that the collateral damage from these attacks extends far beyond primary targets. Service providers and enterprises alike feel the ripple effects as traditional defenses struggle to keep pace with AI-enhanced automation, multi-vector strategies, and readily accessible attack services. The report underscores the importance of real-time intelligence, adaptive mitigation tools, and comprehensive visibility into internet traffic to stay ahead of evolving DDoS campaigns.

Stop Packet Hoarding: Why Enabling DHCP Logs Will Save Your Sanity

If you’ve ever fired up a packet capture to troubleshoot a DHCP issue, you know the feeling. Suddenly you’re drowning in thousands of packets, most of which have absolutely nothing to do with your problem. Sure, packet captures are powerful, but using them for basic DHCP troubleshooting is like bringing a chainsaw to cut a slice of pizza. Enabling DHCP logging gives you the highlights instead of the entire director’s cut, and your brain will thank you for it.

DHCP logs tell a clean, simple story: who asked for an address, when they asked, what they got, and why they maybe didn’t get one. You can immediately see failed requests, exhausted scopes, duplicate MAC addresses, or clients that just won’t stop asking nicely. Instead of squinting at hex values and scrolling past ARP chatter, you get human-readable entries that point straight to the problem. It’s the difference between reading a police report and watching every security camera in the city at once.

Another big win is time and storage. Packet captures grow fast and get unwieldy even faster. You capture too little and miss the issue, or capture too much and now you’re archiving a multi-gigabyte file named “dhcp_final_FINAL_v3.pcapng.” DHCP logs, on the other hand, are lightweight and continuous. You can leave them on without worrying about disk space or explaining to management why the firewall suddenly needs more storage than the file server.

That’s not to say packet captures are useless—sometimes you really do need the chainsaw. But for day-to-day DHCP troubleshooting, logs are faster, clearer, and far less likely to make you question your career choices at 2 a.m. Enable DHCP logging first, solve the problem in minutes, and save packet captures for when things get truly weird. Your future self, staring at fewer packets and drinking better coffee, will appreciate it.

here is an example of enabling DHCP
logging on a Ubqiuiti Edgrouter that is acting as a DHCP server.

configure

set service dhcp-server global-parameters 'log-facility local2;'

set system syslog file dhcpd facility local2 level debug

set system syslog file dhcpd archive files 5

set system syslog file dhcpd archive size 5000

commit; save

exit

After applying the changes, you can view the DHCP log with:

 show log file dhcpd

 Here is some sample output - before you freak out, do your dhcp homework

@Georgetown:~$ show log file dhcpd

Dec 11 09:57:58 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

Dec 11 09:57:58 Georgetown dhcpd3: DHCPDISCOVER from e8:ca:c8:57:fb:4c via eth2

Dec 11 09:57:58 Georgetown dhcpd3: DHCPOFFER on 10.44.10.37 to e8:ca:c8:57:fb:4c via eth2

Dec 11 09:58:12 Georgetown dhcpd3: uid lease 10.44.10.173 for client 24:3f:75:dd:af:38 is duplicate on 10.44.10.0

Dec 11 09:58:12 Georgetown dhcpd3: DHCPDISCOVER from 24:3f:75:dd:af:38 via eth2

Dec 11 09:58:12 Georgetown dhcpd3: DHCPOFFER on 10.44.10.36 to 24:3f:75:dd:af:38 via eth2

Dec 11 09:58:42 Georgetown dhcpd3: DHCPDISCOVER from 3c:7a:aa:9a:c3:8f via eth2

Dec 11 09:58:43 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 3c:7a:aa:9a:c3:8f via eth2

Dec 11 09:58:45 Georgetown dhcpd3: DHCPDISCOVER from 84:c8:a0:d3:b8:2e via eth2

Dec 11 09:58:45 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:02:59 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

Dec 11 10:02:59 Georgetown dhcpd3: DHCPDISCOVER from e8:ca:c8:57:fb:4c via eth2

Dec 11 10:02:59 Georgetown dhcpd3: DHCPOFFER on 10.44.10.37 to e8:ca:c8:57:fb:4c via eth2

Dec 11 10:03:13 Georgetown dhcpd3: uid lease 10.44.10.173 for client 24:3f:75:dd:af:38 is duplicate on 10.44.10.0

Dec 11 10:03:13 Georgetown dhcpd3: DHCPDISCOVER from 24:3f:75:dd:af:38 via eth2

Dec 11 10:03:13 Georgetown dhcpd3: DHCPOFFER on 10.44.10.36 to 24:3f:75:dd:af:38 via eth2

Dec 11 10:03:43 Georgetown dhcpd3: DHCPDISCOVER from 3c:7a:aa:9a:c3:8f via eth2

Dec 11 10:03:44 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 3c:7a:aa:9a:c3:8f via eth2

Dec 11 10:03:45 Georgetown dhcpd3: DHCPDISCOVER from 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:03:45 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:08:00 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

---

LinkRunner AT 4000 versus Network Switch Cable Test (Carlo Zakarian)

 

I used to think the network switch was a master detective, capable of solving all my cable mysteries with a single, glowing link light, and remote management cable tests.  We’ve all seen these features on managed switches, select a port, perform a cable test, and watch for the results to be displayed as either pass, fail, split pair, and the length of the cable.

It wasn't until the feature-packed LinkRunner AT 4000 entered the scene that I realized the switch cable test was actually the network equivalent of a Magic 8-Ball, answering every complex problem with a confident “Yes, cable pass!” and not knowing why it passed.

Most technicians assume that if the switch reports “Cable Pass” the cable is having a great day. But if you want to know if that cable is suffering from a hidden split pair or just a minor existential crisis, you call in the Linkrunner AT 4000.

The LinkRunner AT 4000 is a handheld advanced network cable tester, it’s the stern, white-gloved proctor administering the final exam, it has a follow-up list of diagnostic questions, starting with “Did you remember to terminate correctly on both ends of the cable?”  The LRAT 4000 conveniently draws out the pin-to-pin wire mapping on the LCD screen, it can precisely measure cable fault via TDR, indicating cable problems such as split pairs, shorts, opens, mis-wired, and crossovers.  It also can test for port speeds, PoE, network and connectivity issues, and perform a full network map of your environment.  

Follow along with me and watch as I show you the difference between what a basic switch cable test reports versus a LinkRunner AT 4000 advanced precision cable tester.

Carlo Zakarian is a network engineer with over 15yrs experience in the networking implementation, design, and diagnostics field specializing in LAN, WAN, and Wireless.  Owner of NetFocus Technologies, an IT Managed consulting firm based in Chicago, specializes in setting up, configuring, diagnosing software, hardware, and network infrastructure.

 He can be reached via his website at https://www.NetFocusTech.com

---

Packet Sleuthing on the Edge: How tcpdump Saved My DHCP Sanity

When a DHCP issue strikes, it tends to do so with the subtlety of a brick through a window. Devices suddenly stop obtaining addresses, clients complain that “the network is broken,” and the logs seem to be playing hide-and-seek. This situation was a bit different; one client could not get an ip address from wifi, but worked fine on the wired side.  same vlan, same dhcp server.  and yes his wifi works fine everywhere else. Since the router was the dhcp server, I turned to one of the most under-appreciated diagnostic tools hiding inside a Ubiquiti EdgeRouter: tcpdump. While the GUI has plenty of useful stats, nothing beats raw packet visibility when you need to know exactly what’s happening on the wire.

tcpdump is widely used and been documented thoroughly https://www.tcpdump.org/manpages/tcpdump.1.html  

Capturing packets directly on the EdgeRouter has a huge advantage—you’re collecting data at the precise point where traffic passes. No guessing. No relying on secondhand logs. With tcpdump, I could instantly see whether DHCP DISCOVER, OFFER, REQUEST, and ACK packets were actually being exchanged. In my case, that clarity helped me spot that the DISCOVERs were arriving, but the OFFERS weren’t making it back out. Without that level of detail, I would’ve been stuck blaming ghosts or rebooting things out of desperation.

It was a simple process; i simply ssh'd into the router and typed the following command to capture 5MB of dhcp packets and write them to capture_dhcp.cap.

sudo tcpdump -i switch0 -n -vvv port 67 or 68 -C 5 -W 1 -w capture_dhcp_2.pcap

Another perk is how easy it is to filter traffic with tcpdump. Instead of drowning in a sea of packets, I could lock in on port 67/68 traffic or even narrow the view to a single MAC or interface. It’s like having an X-ray machine for your network, where you can zoom right into the failing process without being distracted by everything else. And since captures can be saved and opened in Wireshark later, you get the best of both worlds: lightweight on-device capture with full-blown desktop analysis afterward.

Finally, running tcpdump on an EdgeRouter is fast, simple, and—most importantly—accurate. When troubleshooting something finicky like DHCP, assumptions are the enemy. tcpdump removes the guesswork and replaces it with hard evidence you can act on. In my case, it cut hours of trial-and-error down to minutes and pointed directly at the misconfigured relay causing all the chaos. If you’re working with Ubiquiti gear and not using tcpdump yet, trust me—your future self will thank you.

from the net: 20 Daily Linux Commands System Administrators Use in Production

 As a Linux SysAdmin working in a production environment, your daily routine is all about keeping systems stable, secure, and performing at their best. From troubleshooting issues to monitoring resources and ensuring uptime, you wear many hats, and time is always of the essence.

While Linux offers thousands of commands, not all of them are part of your day-to-day toolbox. However, there’s a core set of powerful, reliable commands that you’ll find yourself using every single day, often multiple times.

In this article, I’ll walk you through the 20 most essential Linux commands every system administrator should master. These aren’t just commands, they’re your go-to tools for monitoring performance, managing logs, controlling services, debugging problems, and much more.

CLICK THE IMAGE FOR THE FULL ARTICLE

---

I have some ideas for some cool challenges and giveaways in the new year which will only be available to email subscribers.