archi42

Network: Aruba 1930 24x GbE /w PoE and 4x SFP+ in the basement; Mikrotik CSS610 8x GbE and 2x SFP+ in the home office. Linked with 10GbE fiber, and a ton of VLANs.

Server: Dell Precision Rack 7910 with a single E5-2690v4 (14C/28T), 64GB DDR4 ECC (4x16GB), 4x 3.5" HDDs (a hack) with 30TB net storage in RAID1 and 2x small SSDs (OS on RAID1, and temporary data/caches without RAID). I put in the 2x GbE + 2x SFP+ NIC. It's connected with 10GbE and 1GbE.

My old system was nice, but upgrading meant I had to get an expensive CPU; luckily the Dell fell in my hands. With this one, I could double the core count cheaply (it's a 2S system and the CPU is really cheap) and iirc have 192 or 256GB memory per socket (with the cheap 16GB modules).

The above hardware plus all the PoE stuff (5x UniFi AP, a switch behind the TV, DECT-VoIP Gateway), DSL modem and a few ESP draw 110W. The server itself is in the 80W ballpark (that's 15€/month worth of electricity). This could be reduced with more modern or less powerful hardware. What I did was replace my old, big array of 12 disks with four much bigger disks. Since OS and cashes are on SSD, the disks can spin down a lot. I only insert one PSU, since the second one adds 17W idle power draw.

Compared to other home servers that can be pushed much lower it's still okay, since it replaces a bunch of services I'd have to pay for & allows much faster transfers to my workstation (for backups etc) than the 32MBit/s DSL. The old server was running out of cores... The only external service I still spend money on is mail.

Server runs baremetal Arch Linux (it's not cattle), and two VMs (qemu): OpnSense and Home Assistant. Samba serves files from the raid to the network. Services are partially native, some in podman. There are: cockpit, mealy, foundry, step-ca, scanserv, vaultwarden, mosquito, zigbee2mqtt, pihole, tasmoadmin, uptime kuma, UniFi manager, samba, lancache, heimdall, plex. Plus two custom services. It also interfaces with the PV using RS485. A 20m USB cable connects it to the zigbee stick on the second floor. I'm looking forward to adding influxdb/graphana for long term monitoring of our heat pump and BEV power consumptions.

The OpnSense does DHCP, wireguard and local DNS.

First step was to setup cockpit, since I like it to configure IPs and access the VMs. Then OpnSense for inter-VLAN routing and firewall, and to the outside world.

Since I wanted to encrypt the traffic even locally, that was the second step: I have a step-ca that serves certs using ACME. My nginx acts as a reverse proxy for most services and gets certs from the step-ca. The CA is limited to the .lan so it can't be used to intercept other traffic. Also, DHCP puts hosts on .dhcp.lan, so random hosts can't just try to pick any domain name inside the network and get certs for that.

With that done, I looked at services I use or that sounded useful, and spun them up.

The foolproof way is to not send codes as a 2FA (be it mail, SMS or whatever). There is always a risk that the user fails to verify where they're putting that code. Instead use something that verifies the domain without relying on the user, e.g. U2F or passkeys.

In that case the user needs to be fooled to sent the physical device or passkey-app-backup to the attacker. This is much more suspicious and needs a much worse fool than someone entering a code after they already entered their user+password.

If you know that the user uses the same browser to open links sent via mail as they use for their login: For the 2FA step, set a cookie with some unique value on your login domain and sent the user a mail with a link. Opening the link only finishes the login and starts a valid session if that unique cookie is present. This makes it harder for an attacker, since they need to inject that cookie into the victims browser, which means they need to find an XSS-style exploit. Of course you then want to reduce the attack surface by putting the login function on a subdomain of its own.

And obviously this fails if the user is about to login e.g. on their personal computer and then tries to verify the session on their company phone. This can be good or bad, depending on the scenario.

TBF, I wish some companies would use even that basic code-by-whatever 2FA. I've seen cases which have like 5 different domains, all with various logins that customers and employees use. Want to phish them? Just register another domain that looks similar enough to the others and sent some mails. But then there are still services limiting the password length to something like 16, so I think we will still have plenty of work...

Nope. No separate AC and DC conductors for CCS2. From wikipedia [1], the DC cable has: PE, CP & PP (comms), fat DC+ and fat DC-. That's it. In the AC portion of CCS2 there are connectors for Neutral and up to three lines (for three phase charging), but these are not present for a DC cable.

I have to admit I haven't used Tesla plugs, but there is already a slight difference between the cable from a 50kW charger and a 350kW charger.

[1] https://en.wikipedia.org/wiki/Combined_Charging_System

"But they're ISO certified!" /s

Strictly speaking audit is the wrong word for what I did (I'm not a certified auditor). I don't want to say too much in case I break some confidentiality agreement. Though I'm curious how that will be argued away, or if they get the manufacturer to get their shit together and build a new firmware...

> everyone should update ssh

Uh, if it was that easy. I recently(!) audited a brand new system for deployment in what most nations consider critical infrastructure. They had just updated to the newest firmware supplied by a well-known and established manufacturer in that industry (not some garbage by a small company). That ran a dropbear ssh server version from 2016 with multiple CVEs, including an unauthenticated RCE. So essentially it's a root shell for anyone that can talk IP to that device.

I predict I will start seeing this terrapin in my Nessus reports soon, and stop seeing it when I enter pension.

You're sure you're not hearing some harmonic? IIRC THD at lower frequency increases drastically. Or wind noise of the subs (they're moving lots of air)?

You can check with a measurement mic what's audible (& make sure to take measurements at multiple points in space due to the low wave length).

To decrease the lower frequency of the audio interface, you probably have to modify the output DC decoupling capacitors (those act as a high pass; bigger C = lower f).

Hah, next step: Add a simple PLC the players can program to try to control it (or modbus to hook up an actual PLC) ;-)

It's a long read (and pretty good at that), and I only just now saw your remark... There is not a single phrase that really sums it up: The report covers a lot of time and many facets, making it hard to pick "that one phrase". Maybe simply pick another part of the title?

The Mirai Confessions: Three Young Hackers [...] Tell Their Story

(yes, not really neutral, but it drops the monster-bait)

The Zoe is EOL and IIRC replaced by the Clio E-Tech. Also, Renault is french?

(Not to talk badly about the specific car or the move to BEV in general - I applaud that and am at the same time disappointed how our [German] manufacturers ignored the shift)

It's not possible for every workload, and sometimes the necessary effort makes it infeasible. Getting a Xeon might be the cheaper option then ;-)

Edit: Though I'd still recommend heeding menaerus excellent sibling answer. Maybe not for this project, but it is great knowledge to have in your domain and I'd expect it to be relevant for the future.

You can try to make your code aware of the situation and distribute the tasks accordingly. IIRC that's what people do on NUMA systems.

Because the framing is wrong and click bait... As anyone with many cores can tell you: Those are used.

The issue us more subtle: "[the minimum granularity] is supposed to allow tasks to run for a minimum amount of [3ms] when the system is overloaded".

That's supposed to scale with number of cores, but the scaling us limited to 8 cores. However, imho that's not even necessarily a bad thing. It's a trade off between responsiveness and throughput in overload situations. You don't want slices to become too tiny/large...

I did some work on a toolchain used in automotive (and other industries) to proof^W prove certain software properties related to safety. This is already a massive effort, expensive to build & maintain - but after all a small cog in the whole machine. (Using Rust over subset-of-C would deprecate maybe half of that work; at most I'd guess). The hypothetical team would take a decade or two to replicate just that cog.

Yes, having the whole machinery available as FOSS would be awesome and I'd like to live & work in a world in which this is the norm (Hello, Star Trek?). But all this requires very talented people, many of whom studied and racked up student debt, want something to eat and a place to stay. We first need another paradigm shift to make this kind niche open work sustainable.

Oh, and if you ever find yourself in a car with critical components not checked with that kind of toolchain: I strongly recommended getting out of there asap ;-) For all the excellent people building that software, there will always be some who'd be better writing mobile apps instead (or anything else that cannot kill people).

(btw: You asked me about the setpoints of the 12k 3P Deye inverters a while ago: Seems to work nice for me with my basic "just the inverter + PV + battery" setup. Though some people report trouble when using AC coupling with another inverter; in that case the Deye seems to swing more around the setpoint).

The compiler takes care of this kind of optimization via static analysis. And who said x86? You're right, but what about Power9 register windows vs the three-and-a-half brain cells of x86?

I'm not in the mood of discussing this or convincing you otherwise. If you made up your mind to use int over intWhatever_t then so be it. We're not working on the same project and I suppose you're not building anything that might kill me.

You have to check sizeof(int) somewhere. Why not do that in a header? To make sure you're using the checked int, define a new type, eg "int4" in that header, too, and use that. Congratulations, you'll fulfill this MISRA rule :)

Or just use int32_t and let the compiler fail if your Toolchain does not have that. Then just write an appropriate header to add it (with the correct checks) ;)

I agree, and there is tooling to do this kind of thing with C/C++. If this was embedded into the language, you'll quickly learn that static checking has its limits; dynamic checking introduces a new class of failure mode into your embedded, safety critical (as in kills or destroys) system, which might also not be what you want. It's a conundrum :(

The second statement contradicts the first - int16_t is too specific and hides errors, but an arbitrary range is not?

Cross-platform code - Is your int still 16 bits on your new CPU? Of course you know* your variable is always between 0 and 15, but the MISRA checker might not**.

Today we have int16_t et al., so this is much less of an issue.

*) IME "know" is often merely a "believe".

**) Not sure that even if you have a MISRA checker that has a suitable inference, it is allowed to discard alarms on this kind of violation. I wrote MISRA test cases for something for a suitable powerful checker/analyzer, but I can't remember this detail anymore.

That's illegal then. But the pihole won't do the trick, you need to remove the mandated certs from your browsers certstore. If these certs are used for legitimate places (e.g. EU or state websites, and I'll bet they will) you then will get a certificate error.

Of course there is still HSTS, but that's not supported by all tech using TLS.

1. If an attacker got your credentials, they'll probably also have the server URL. Reasoning: They probably infected your machine with infostealer malware and keylogged the password. Or are you using the exact same credentials someplace else?

2. If they can figure out your domain name, they can check crt.sh for "mysecrectvaultwarden.domain.tld". If that only reveals wildcard certs and they're really interested in you or your company, they could try bruteforcing the DNS name.

3. If they breach the vaultwarden server and in case you're using the web UI, they can try to inject some JS to steal the credentials.

What I do to mitigate this: 1. Vaultwarden only reachable via VPN (e.g. wireguard on OpnSense) 2. Custom CA on all devices (e.g. step-ca with name constraints and local ACME [careful to put DHCP clients on a subdomain!]) 3. DNS for my LAN+VPN is not public. This massively reduces the external attack surface, compared to having a bunch of services available behind traefik.

The local hardware stores' own brands offer a wide range of cheap, torx-compatible screws. I think this started not too long ago (but can't say for sure, probably 2019 when the latest torx patent expired?), and they still offer screws with the normal cross shape. Both are of the same, decent quality.

I only buy the torx/star variants, since they're just superior.

But how does that sell ad space on my consumer attention spot market? And then they can't see the product they're about to buy! /s

We have a restaurant that only took cash for a long time. Because I usually pay everything with card, I have a card-only wallet and rarely any significant amount of cash on me. There is no ATM in the vicinity (it's in a small suburb).

The second time we didn't go there while passing that place, I dropped them a friendly mail. I must have been not the only one, because now they accept cards.

Sometimes talking to people helps. Though with a franchise there might be no-one on site with the power to "just fix" things. Regarding the gas station: Maybe charge at home instead? :P

A screen+camera would actually enable insanely good insulation, compared to glass. A 4cm/1.6" PUR sheet weights next to nothing and has a thermal transmittance (aka u-value) of 0.4 W/(m²K). That's about twice as good as modern, triple glazed windows.

"Thanks for self-reporting this. We are handling sensitive information in accordance with the European GDPR. Due to not having a suitable data processing agreement in place, you are in risk of violating national law in multiple countries.

Please contact us asap to sort this out and we can notify any affected customers and report this incident to the relevant authorities."

IANAL, but maybe if it's enough if your collegues might have uploaded a list of customer email addresses, some of which might reside in a EU country.

I'm surprised they're not keeping 2G GSM/GPRS for legacy applications. E.g. considering the life time of cars, for an eCall-like[1] solution having a network that'll be available for a few decades would make sense; or user-replacable modules.

For smart meters I had to prepare a network cable into our new main fuse box; but IIUC we won't be getting one of these, for now it's just a requirement.

[1] https://en.wikipedia.org/wiki/ECall

s/even the super wealthy/especially the super wealthy/

The wealth of the wealthy depend a lot on the infrastructure build from tax money. E.g. they don't build nation-scale road networks, but would make much less profit if these were absent.

"Energy consumption per capita is 2.2 toe, with electricity accounting for 4300 kWh (2021). These figures are around 25% below the EU averages."

https://www.enerdata.net/estore/energy-market/croatia/

With an average household size of 3.2 that's realistic.

Though imho it's a bit much. Pre-heatpump, our two person house drew less, even though I charge a PHEV. Maybe the figure includes industrial use?

Ah, thanks, that's what I had in mind :) So while the original advise holds, commercial users are locked out of three weeks of payments of they're frozen for random bs.

And curl has --limit-rate and supports more protocols. But so what? If they are happy using FileZilla and it helps them getting stuff done, why berate them? It's not even like they're abusing a tool in an entirely unintended way, quite the opposite.

I'm saying this as a shell-user.

I think for a normal customer that's true. IIRC it's mostly commerical users who don't always seem to have immediate access to funds?