• 0 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle
  • From my reading this is misleading at best and likely wrong. I don’t work with CrowdStrike Falcon but have installed and maintained very similar EDR tools in enterprise environments and the channel updates referenced are the modern version of definition updates for a classic AV engine. Being up to date is the entire point and so typically there are only global options to either grab those updates from the vendor or host them internally on a central server but you wouldn’t want to slow roll or stage those updates since that fundamentally reduces the protection from zero days and novel attacks that the product is specifically there to detect and stop. These are not engine updates in that they don’t change the code that is running, they give the code new information about what an attack will look like to allow it to detect malicious activity as soon as CrowdStrike knows what the IoCs look like.

    In this case it appears that one of these updates pointed to a bad memory location which caused the engine to crash the OS, but it wasn’t a code update that did it (like a software patch). That should have been caught in QA checks prior to the channel update being pushed out, but it’s in CrowdStrikes interest to push these updates to all of their customers PCs as quickly as they can to allow detection of novel attacks.






  • Asking broadly like this is akin to asking for a guide on how to cook, it’s generally too broad for there to be a single guide. You first need to figure out what your goals are (you state one already, you’d like it to be externally accessible), determine what services you want to host, and then start looking at how to do so.

    The advice I’d give is to start with a solid base, you’ll need something to self host on and it really shouldn’t be the PC you use for other things. Get it setup to run a virtualization OS such as proxmox and use that as your starting point. Then do a lot of reading. I spend probably three to four times as much time reading about the service I’m planning to deploy compared to actually doing the work to deploy it. Lastly, plan. You should have a solid plan in the beginning of how you want your service to work (what will be external vice internal only, how will you setup the networking stack to do that, are you going to have a domain, and will you use subdomains or folders to divide services, what does your IP space look like, will you host your own firewall to make the networking more controlled or fight with your ISPs router, do you want to use docker, kubernetes, or maybe full VMs for each service, do you want/need a UI to manage things from or are you comfortable with CLI, etc). These answers will lead you to guides for various services as well as service specific forums where help is more focused.







  • This is pretty much it, Plex offers far more client apps that are full featured and they make it super easy to setup and use both as an admin and a user. Especially for things like OTA TV where they provide the guide data once it’s setup (which is why it’s a paid option). I’d move to JellyFin in a heartbeat if they’d support OTA and DVR playback on AppleTV.


  • In most companies I’ve worked for, T1 is there to put in tickets from calls, and handle the simplest of tasks (password resets, account lockouts, “have you tried turning it off and on again” tasks). Anything beyond that is generally sent to T2 (usually the desktop team who then force other teams to accept tickets as needed) and T3 for anything that more systemic or needs deeper troubleshooting and system knowledge.

    In many places it’s a combination of piss poor pay creating little motivation and high turnover (and thus lack of training) and management prioritizing the wrong metrics (generally looking for short call times and short call queues). If you want to try and improve things I’d suggest learning about the KPIs that team is expected to meet, and then ask management why they chose those metrics. Generally I’ve found prioritizing first call resolution over call times to be a huge improvement to motivation of the team and user satisfaction scores (we all like solving problems and users tend to be way nicer when you fix the issue vice kick the can).

    I would say, at least to your point about them not having access to systems, that’s it’s very common for T1 to have pretty limited admin access to systems. Partly to protect against inexperience, but also as a social engineering protection. If they need to ask for access to pass a ticket for elevated rights, it gets another set of eyes on the call to ensure it’s all kosher.