home | blog | Teh Internet | guest blog |rants | political | projects | Gwen and Liam | Citadel patched | Tools | Scouts

- Careful Chrome users, this search box might be "Not secure"

28 September 2018, 19:31 UTCAnybody seeing a pattern here? - SYN flood spoofing

So far, I have had the following IP's become what I assume is the brunt end of a spoofed SYN flood attack: <- observed from a server where I could not block - lasted almost 4 hours!

Not sure what the connection is, but if someone knows, feel free to let me know.
Not sure what to make of it yet.

Update Oct 1 2018
The spoofing continues.
Seems to now include some Cloudflare, Google User Content, and random other targets.
The rotating behavior is new as well.
Much of the hate seems directed at: - with other hosts in rotation (off and then on again short burst attacks). - seems to be in second place for the disdain.
others... (the burst ones that seem only to be attacked from 1 to 5 minutes at a shot over a 20 to 40 minute interval)


14 September 2018, 16:48 UTCUbuntu 18.04.1 - Libvirt/KVM/Qemu setup with Wok/Kimchi

Here is what I did to get things working...
Big thanks to github user aluvare for his patch work here:
As always, links to needed bits included here in case the sources go away.

Install Ubuntu 18.04.1 x64 server on a computer with a processor that has AMD-V or Intel VT-x extensions (and can be enabled via the bios).

Add packages (see
apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virt-manager

Modify the networking to use as a bridge interface (assuming you want bridge networking to your local lan):
bridge version changed in network config:

Grab the debs:
ginger-base.noarch.deb - not needed if you won't be controlling the host from the interface.

Patch the kimchi-2.5.0-0.noarch.deb to get a patched version to work with the replaced Python PIL with Python Imaging (thanks again aluvare!)
- see

Sprinkle in installs for dependent packages:
- see

Hopefully get a wonderful interface at:
- might need services to be restarted...

And here are the files:


23 August 2018, 21:04 UTCOk, now disable SMT / Hyper-threading? This is getting old.

At least that seems to be what Theo de Raadt says
Link to list here:
and of course, if that should break, cut and paste as always:

List:       openbsd-tech
Subject:    Disable SMT/Hyperthreading in all Intel BIOSes
From:       Theo de Raadt <deraadt () openbsd ! org>
Date:       2018-08-23 18:35:22
Message-ID: 87827.1535049322 () cvs ! openbsd ! org

Two recently disclosed hardware bugs affected Intel cpus:

	 - TLBleed

	 - T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this
	         bug, more aspects are surely on the way)

Solving these bugs requires new cpu microcode, a coding workaround,
*AND* the disabling of SMT / Hyperthreading.

SMT is fundamentally broken because it shares resources between the two
cpu instances and those shared resources lack security differentiators.
Some of these side channel attacks aren't trivial, but we can expect
most of them to eventually work and leak kernel or cross-VM memory in
common usage circumstances, even such as javascript directly in a

There will be more hardware bugs and artifacts disclosed.  Due to the
way SMT interacts with speculative execution on Intel cpus, I expect SMT
to exacerbate most of the future problems.

A few months back, I urged people to disable hyperthreading on all
Intel cpus.  I need to repeat that:


Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it
is enabled, and will update the cpu microcode if possible.

But what about 6.2 and 6.3?

The situation is very complex, continually evolving, and is taking too
much manpower away from other tasks.  Furthermore, Intel isn't telling
us what is coming next, and are doing a terrible job by not publically
documenting what operating systems must do to resolve the problems.  We
are having to do research by reading other operating systems.  There is
no time left to backport the changes -- we will not be issuing a
complete set of errata and syspatches against 6.2 and 6.3 because it is
turning into a distraction.

Rather than working on every required patch for 6.2/6.3, we will
re-focus manpower and make sure 6.4 contains the best solutions

So please try take responsibility for your own machines: Disable SMT in
the BIOS menu, and upgrade your BIOS if you can.

I'm going to spend my money at a more trustworthy vendor in the future.


20 August 2018, 20:53 UTCUh, yeah, good one Microsoft: Auto updating AD Sync, and wow....

Directory_Synchronization The program stopped because an alternate diskette was not inserted.

Stop! Don't copy that floppy!


6 August 2018, 20:02 UTCGet ready for the SegmentSmack and FragmentSmack TCP vulnerabilities.

Follow along here:
More here:
Very brief bit from -

Linux kernel versions 4.9+ can be forced to make very expensive calls to tcp_collapse_ofo_queue()
and tcp_prune_ofo_queue() for every incoming packet which can lead to a denial of service.
An attacker can induce a denial of service condition by sending specially modified packets within
ongoing TCP sessions. Maintaining the denial of service condition requires continuous two-way
TCP sessions to a reachable open port. Thus, the attacks cannot be performed using spoofed IP addresses.


31 July 2018, 22:19 UTCO Superman - Laurie Anderson

Cause when love is gone, there's always justice. 
And when justice is gone, there's always force. 
And when force is gone, there's always Mom. Hi Mom!


26 July 2018, 16:41 UTCBroken, but just wait! - High CPU usage issue in Azure AD Connect Health for Sync - update - 8/16/18
We will update this article when the new version of the Azure AD Connect is available. It is the middle of August, no article update, but updates for the AD Connect are available....
So, don't apply updates, and just wait... - at lest for the lesser AD Connect customers...
Short version for when they redact the best part of the article: (or make it a 404)

You experience slow performance and high CPU usage (reaches to 100%) issue in a machine that runs Azure Active Directory (Azure AD) Connect Health for Sync monitoring agent. In task manger, you notice that the process MIcrosoft.Online.Reporting.MonitoringAgent.Startup uses the high CPU usage.

The issue is not limited to specific Azure AD Connect Health versions and operating system versions. 

This issue occurs because June 2018 update of NET framework 4.7.2 is installed in the machine, and Azure AD Connect Health for Sync monitoring agent does not fully support this update.

The following .NET framework update would cause the high CPU issue of monitoring agent:

.Net framework update

OS version


Windows Server 2008


Windows Server 2008 R2


Windows Server 2012


Windows Server 2012 R2







For Connect Health for AD DS and AD FS:

To resolve this issue, install the Azure AD Connect Health Agent, version that is released on July 2018.
It can be downloaded from Connect Health public documentation.

For Azure AD Connect:

A new version of the Azure AD Connect will be released soon. It will contain a fix for this high CPU usage issue.
We will update this article when the new version of the Azure AD Connect is available.

Last Updated: Jul 25, 2018


11 July 2018, 16:50 UTCBeginning of the end

So, this is how it ends.
Just now forgot how to expunge messages in Alpine
after using it for quite a few years.
P.S. it is Shift + x


6 July 2018, 5:24 UTCDuff's device

Cool beans!


21 June 2018, 20:33 UTCosquery - extensions

Need to take a read only peek at "stuff" on running systems?
osquery - considered useful. Exensions can make it more so.
Abstracting away differences in firewalls, try things out (test a theory).
They even have a Python extension:


16 June 2018, 4:54 UTCTariffs, what can we make of them.
11 June 2018, 4:50 UTCDigital vs analog world
5 June 2018, 15:50 UTCMore Backups... WindowsImageBackup to a share.
4 June 2018, 18:31 UTCNow that Github is on the dark side, here is how to back up your new Gitlab instance :-)
31 May 2018, 19:37 UTCCheck your SSL at the door, and keep your POODLE inside.
30 May 2018, 5:09 UTCDon't give up!
8 May 2018, 15:08 UTCVery Magic! VIM needs hand holding for some sed replacments:
4 May 2018, 4:56 UTCYea! Amateur Radio gets a mention in a scientific paper!
2 May 2018, 3:53 UTCbell labs, xerox parc, (mitre?)
18 April 2018, 19:57 UTCTrusov Ilya Igorevych
29 March 2018, 21:11 UTCDrupalgeddon2
5 March 2018, 17:40 UTCMicrosoft - you don't correctly run MTA's either.
29 January 2018, 14:32 UTCThe most current Microsoft advice on configuration documentation:
25 January 2018, 17:10 UTCApple calls it (mostly) quits on the Server App...
20 January 2018, 4:00 UTCI wonder...
3 January 2018, 21:32 UTCNobody ever got fired for going with Intel/AMD/ARM (ha). - (Meltdown / Spectre) - update now including Foreshadow (SGX / Skylake and later processors only)
13 December 2017, 15:55 UTCNOC, NOC?
5 December 2017, 15:13 UTCAndroid 8.1 Oreo
15 November 2017, 18:23 UTCTimedRotatingFileHandler - don't be stupid.
14 November 2017, 5:46 UTCSystemd (resolv.conf and dnsmasq)

All older entries

[atom feed]