@Oksana The issue started with keeping Hyper-V around... so many better options to be able to leverage StarWinds vSAN with.

So this is what I've been able to sort out; PrivateLink allows a VPC to privately access a specific service (like an API, NLB, or AWS-managed service such as S3 or Secrets Manager) via a VPC interface endpoint. It operates at Layer 7 (Application) of the OSI model, so there’s no need to worry about CIDR overlap between the consumer and provider VPCs. Traffic is routed entirely over AWS’s internal network infrastructure and never traverses the public Internet. The consumer only interacts with the service endpoint (DNS → ENI) and does not have visibility into the provider’s backend network. PrivateLink is suitable only when both the service and the consumer are within AWS and is not intended for on-premise connectivity.

It's not a VPN in the traditional sense, but it is a VPN between VPCs (essentially), which only works within AWS.

I'm having this discussion now, and I'm failing to see how a coworker thinks that AWS PrivateLink is anything but a VPN, specifically for AWS VPCs.

He expressly said "VPN != VPCe (which is the AWS name for PrivateLink)"

Can someone explain this to me in crayola?

@scottalanmiller said in What Are You Doing Right Now:

@DustinB3403 That a whole version back. No current release that I'm aware of.

Yeah there has been nothing newer released that I've seen.

@scottalanmiller said in What Are You Doing Right Now:

@DustinB3403 said in What Are You Doing Right Now:

@scottalanmiller said in What Are You Doing Right Now:

@DustinB3403 said in What Are You Doing Right Now:

@travisdh1 said in What Are You Doing Right Now:

I had a fun night last night adding storage to a server. When I went to move VM storage location, found a checkpoint (Hyper-V, ugh) from 2018.... Took a long while to coalesce.

This morning everything had finally coalesced and moved to the new storage array. Only took ~10 hours.

You're using Hyper-V? How's that been going and what management tools are you using?

I had some lunatic INSTALL it in the last two months! W.T.F.

Was it installed properly, IE with the Hyper-V iso and not via a Windows Server Role installation?

Does that still exist?

Yeah, granted its 2019.... but it's still there https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019

@scottalanmiller said in What Are You Doing Right Now:

@DustinB3403 said in What Are You Doing Right Now:

@travisdh1 said in What Are You Doing Right Now:

I had a fun night last night adding storage to a server. When I went to move VM storage location, found a checkpoint (Hyper-V, ugh) from 2018.... Took a long while to coalesce.

This morning everything had finally coalesced and moved to the new storage array. Only took ~10 hours.

You're using Hyper-V? How's that been going and what management tools are you using?

I had some lunatic INSTALL it in the last two months! W.T.F.

Was it installed properly, IE with the Hyper-V iso and not via a Windows Server Role installation?

@travisdh1 said in What Are You Doing Right Now:

I had a fun night last night adding storage to a server. When I went to move VM storage location, found a checkpoint (Hyper-V, ugh) from 2018.... Took a long while to coalesce.

This morning everything had finally coalesced and moved to the new storage array. Only took ~10 hours.

You're using Hyper-V? How's that been going and what management tools are you using?

I recently got Backseat Drivers, game is hysterical.

Need a group of people to play it though, but it's good fun.

Abiotic Factor is another game I've been playing for a bit that is under constant dev, really cool game.

Blocking apps that were approved by users with the "Sign in With Google" that are just trash apps, like Fireflies.

@travisdh1 I've been pretty disappointed in Firefox personally, ha.

@CloudKnight interesting read.

Yeah using Hyper-V when there has been zero improvement of the environment in nearly a decade would be horrifying to hear about, much less to be actively considering.

I could see, finding solutions to migrate away from it, but actively deciding to deploy to it... When Microsoft is actively depreciating work on both Windows Server, and Hyper-V.... not ever in a hundred years...

@scottalanmiller said in List Windows Printers from PowerShell Command Line CLI:

If you need to remote into a Windows machine and get a list of printers without interrupting the user, this powershell command is quick and easy...

Get-Printer | Format-Table

Make it easier Get-Printer | FT

Reviewing the output of sslscan, it seems we have some depreciated ciphers that need to get pulled.

Waiting for a meeting to start with a client.

@Oksana Who has been using Hyper-V. . .

XCP-ng, Proxmox, or straight KVM.

Hardening a few linux servers from some Medium threats, all High threats have already been remediated.

Also getting over a cold.

For obvious reasons RHEL is annoying, like needing to sign into their paywall to find this information. If you're ever needing to harden a RHEL based OS, specifically to disable SHA1 and CBC you can use the below and reboot the server.

These vulnerabilities are outlined below and the remedy is listed at the bottom. Mind any typo's I've copied the description out of a PDF and there may be some copy/paste artifacts or typos.

Medium (CVSS: 5.3)
 NVT: Weak Key Exchange (KEX) Algorithm(s) Supported (SSH)
 Product detection result
 cpe:/a:ietf:secure_shell_protocol
 Detected by SSH Protocol Algorithms Supported (OID: 1.3.6.1.4.1.25623.1.0.105565
 →)
 Summary
 The remote SSH server is con gured to allow / support weak key exchange (KEX) algorithm(s).
 Quality of Detection (QoD): 80%
 Vulnerability Detection Result
 The remote SSH server supports the following weak KEX algorithm(s):
 KEX algorithm
 | Reason-----------------------------------------------
diffie-hellman-group-exchange-sha1 | Using SHA-1
 Impact
 An attacker can quickly break individual connections.
 Solution:
 Solution type: Mitigation
 Disable the reported weak KEX algorithm(s)- 1024-bit MODP group / prime KEX algorithms:
 Alternatively use elliptic-curve Di e-Hellmann in general, e.g. Curve 25519.
 Vulnerability Insight- 1024-bit MODP group / prime KEX algorithms:
 Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman
 key exchange. Practitioners believed this was safe as long as new key exchange messages were
 generated for every connection. However, the first step in the number field sieve-the most efficient
 algorithm for breaking a Diffie-Hellman connection-is dependent only on this prime.
 A nation-state can break a 1024-bit prime.

 Vulnerability Detection Method

 Checks the supported KEX algorithms of the remote SSH server.
 Currently weak KEX algorithms are defined as the following:- non-elliptic-curve Di e-Hellmann (DH) KEX algorithms with 1024-bit MODP group / prime- ephemerally generated key exchange groups uses SHA-1- using RSA 1024-bit modulus key
 
 Details: Weak Key Exchange (KEX) Algorithm(s) Supported (SSH)
 OID:1.3.6.1.4.1.25623.1.0.150713
 Version used: 2024-06-14T05:05:48Z
 Product Detection Result
 Product: cpe:/a:ietf:secure_shell_protocol
 Method: SSH Protocol Algorithms Supported
 OID: 1.3.6.1.4.1.25623.1.0.105565)
 References
 url: https://weakdh.org/sysadmin.html
 url: https://www.rfc-editor.org/rfc/rfc9142
 url: https://www.rfc-editor.org/rfc/rfc9142#name-summary-guidance-for-implem
 url: https://www.rfc-editor.org/rfc/rfc6194
 url: https://www.rfc-editor.org/rfc/rfc4253#section-6.5

And CBC

Medium (CVSS: 4.3)
 NVT: Weak Encryption Algorithm(s) Supported (SSH)
 Product detection result
 cpe:/a:ietf:secure_shell_protocol
 Detected by SSH Protocol Algorithms Supported (OID: 1.3.6.1.4.1.25623.1.0.105565
 →)
 Summary
 The remote SSH server is con gured to allow / support weak encryption algorithm(s).
 Quality of Detection (QoD): 80%
 Vulnerability Detection Result
 The remote SSH server supports the following weak client-to-server encryption al
 →gorithm(s):
 aes128-cbc
 aes256-cbc
 The remote SSH server supports the following weak server-to-client encryption al
 →gorithm(s):
 aes128-cbc
 aes256-cbc
 Solution:
 Solution type: Mitigation
 Disable the reported weak encryption algorithm(s).
 . . . continues on next page ...
2 RESULTS PER HOST
 6
 . . . continued from previous page ...
 Vulnerability Insight- The 'arcfour' cipher is the Arcfour stream cipher with 128-bit keys. The Arcfour cipher is
 believed to be compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems
 with weak keys, and should not be used anymore.- The 'none' algorithm specifies that no encryption is to be done. Note that this method provides
 no confidentiality protection, and it is NOT RECOMMENDED to use it.- A vulnerability exists in SSH messages that employ CBC mode that may allow an attacker to
 recover plaintext from a block of ciphertext.
 Vulnerability Detection Method
 Checks the supported encryption algorithms (client-to-server and server-to-client) of the remote
 SSH server.
 Currently weak encryption algorithms are de ned as the following:- Arcfour (RC4) cipher based algorithms- 'none' algorithm- CBC mode cipher based algorithms
 Details: Weak Encryption Algorithm(s) Supported (SSH)
 OID:1.3.6.1.4.1.25623.1.0.105611
 Version used: 2024-06-14T05:05:48Z
 Product Detection Result
 Product: cpe:/a:ietf:secure_shell_protocol
 Method: SSH Protocol Algorithms Supported
 OID: 1.3.6.1.4.1.25623.1.0.105565)
 References
 url: https://www.rfc-editor.org/rfc/rfc8758
 url: https://www.kb.cert.org/vuls/id/958563
 url: https://www.rfc-editor.org/rfc/rfc4253#section-6.3

Simply running sudo update-crypto-policies --set DEFAULT:NO-SHA1:NO-CBC and rebooting the system in question removes these vulnerabilities.

@travisdh1 said in What Are You Doing Right Now:

Going over a bunch of Scotts (now old) videos and documentation on SANs to do a brief overview with our sales team. They might be oldish now, but still the best refence material around.

Yeah I find myself having to go over these from time to time as well, because finding the energy to explain it myself in such a succinct manner is too difficult.

@Obsolesce said in Decrypting a LUKS encrypted drive at boot:

@DustinB3403 Oh is it the boot/os drive of a VM?

No it wouldn't be the boot partition, but a secondary array (R1).

@EddieJennings said in Decrypting a LUKS encrypted drive at boot:

I know it's not your ideal, but have you tried to use /etc/crypttab and store the key in a file somewhere that's owned by root and has 400 permissions, just to see if that method can do the automatic unlocking of the encrypted device?

If you're making said file that /etc/crypttab will use remember to do echo -n 'whatever' > yourfile, instead of just echo, else you'll bang your head against the wall not understanding why the stored password isn't working. Ask me how I know.

I haven't tried it.

@dbeato said in Decrypting a LUKS encrypted drive at boot:

Did this work for you? https://www.malachisoord.com/2023/11/04/decrypt-additiona-luks-encrypted-volumes-on-boot/

I've never seen it, will review.