The Ryzen 5 1600 / B350 / under linux (kubuntu with kernel 4.15.0-22) and Nvidia drivers…

Every other day one thinks, it’s cool and nice..
And alas – I notice all cores and threads are stuck at 1374Mhz.. No wonder it stays around 41 degrees C over full load..
It seems something is missing in the performance-junka-mado..

However, “clocking down” to a clock in BIOS to 3775 as a max target seems to get it to boost more often and not lock itself down, it finally jumps to a stable 3768 Mhz on all six cores and threads.
Now, the B350 “chipset” is not what I would call anything special, at all. A bit sad that they did a mid-tier chipset that caught most attention it seems.

There’s more… All the AMD chipsets seems to be, not really that fun for keeping score on temps.. One needs to compile it87 as a module to get the values..

All these points are still valid over several updates, and sadly – since it’s first gen ryzen – it’s not new – but I fail to see the light in the tunnel getting all the things working correctly.

Yes, this is a rant.

I am still happy, since it’s paired with a GTX 1060 6GB ASUS ‘blowerstyle’ GFX. It works for all the things I want. But I do want it do listen to my clock settings.. But I am also guessing the firmware is a bit to blame.

And talking about blame.. WHY THE H*CK can’t Nvidia ensure there is fan profiling in the damned locked drivers straight from the get-go? The damn thing clocks down since it reaches max temp before max performance more or less, with the fans locked at half the speed :S.

Rant over.

However, getting the temps is straightforward – https://github.com/groeck/it87 . Go and Git it.

Jumping around the OS train. /Rant

All aboard!

Next to me, work laptop turned off for the day – runs Windows 10 (*sob sob*).
In front of me, workstation running *buntu 17.10 18.04 LTS.
Below it, MacBook Pro running Mac OS.
Next to it, my “Pi tower” running rasbian-ish distros.
Next to the screen, gaiming rig running windows 10.
BSD stuffs runs virtual from another location in the apartment.
Chromecast here and there, older i5 and i7 machines littering with a plethora of flavours installed.

No wonder I never get anything done at home, I keep fiddling. And if I am not actually fiddling – I am ranting about fiddling.

For the love of something – no wonder that it’s hard to keep track on where I do what – I am all over the place!

The need to know and to tinker always seems greater than the need to sleep or sometimes do something .. Serious.
Like, being social, or go on a date, or take a walk.. Phaw. No time! So much to tinker with!

/rant over.

Twiddling-series.

This year has been quite.. eventful, just as last year.
I am hoping that things will calm down and my head will start working in a more true sense of the word soon.

When this happens (if it happens..), I will start up a small ‘twiddling’ series – targeting the more amusing and fun toys that exists for us interested in, well, fun stuffs.

The baseline will simply be a presentation of the “what”, the “how”, the “why”, and my own small experiences with it, twiddling.

Look at it this way, it’s a getting-started-and-start-getting-your-mods-and-ideas-rolling series.

Traffic Baseline. Apps/OS.

Rant.

Many “NGFW” creations looks into the application-stack “layer 8”. I am however pondering over, since many seems to also identify the underlying OS (for enabling better and easier rule-sets per device category for example) – why not also provide a baseline for that specific OS – what to expect and also identify the normally permitted traffic – and the underlying connectionpoints for those. With this reasoning, one could filter out lots of garbage traffic that otherwise needs to be looked at with all the possible UTM-profiles.

This would be something we all could benefit from, make easier exclusions on per OS-basis etc. If we learn what normal is, we do not have to look at it all the time – only in a fully forensic perspective would it be needed – to fully determine a timeline etc.

WiFi-Honeypot. #KeepCalmAndAnalyze

Step 0 – Create a new and updated infrastructure – migrate your connected devices.
Step 1 – do not update the infrastructure (the ‘broken’ one).
Step 2 – Isolate the infrastructure (meaning – place into a ‘pot’ mode with fake targets all over).
Step 3 – setup recording / detection of all things related to that part of the infrastructure.
Step 4 – monitor actions, step 1-3 and the possible broken part of WPA2 simply is a the entry-point.

Perhaps an exception of providing wireless access to resources would be a possible step 0 – but don’t just turn it off, make sure that the new way of connecting is communicated and understood.

In essence, WPA2-breakdown is like your locked cabinet of entry point for the network just gave away a way in to that specific portion.
It does not have to mean that all things are exposed. It has not broken the protocols that are in use (but they may already have their specific portion broken). You are not completely naked here.

What would be the general idea here? To always keep all things ‘up-to-date’ and isolated in the term of knowing how and where things communicate, separation of duties and communication still holds. Isolation in the world of connections means that you do not allow all things know or reach everything else of your infrastructure, ever.

The best part of this, is that sites/companies/entities can now detect (possibly) what kind of targets they are.
Is the attack general?
Just recon?
Already targeting specific (previously reachable) resources?
Someone trying to use you as a base of attack for another target?

Use this as an oppertunity, instead of doom.

My viewpoint here is – if you already have a wireless network attached to your infrastructure, you should already have isolated and made infrastructural decicions on access. There is no reason to go all in bananas because one of your entry points that already are a physical weakpoint might be now a even more broken entry point.