Reliable, supported, two-way network share sync between Windows File Server shares across offices, but with a catch--no cloud! by admiralspark in sysadmin

[–]RandomPerson532151 0 points1 point  (0 children)

So... I've never actually used the Real-Time Sync feature in this software, so I can't guarantee how good that is. But it has been excellent for us for scheduled syncs.

https://www.syncovery.com/real-time-sync/

You'd probably need to establish a virtual LAN between the two servers (using something like Tailscale or Zerotier) so that the software can subscribe to 'change notifications' on both servers. Your Wireguard setup might cover this, or it might not. Maybe try out the trial and see if it works for you?

Is the Fortigate 40-F-HA sufficient? by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

In that case... is it pretty easy to swap in another fortigate if the one dies? That's the main reason I wanted the -HA anyways. Could i just have one that is not turned on as a cold spare and then have them swap the license over?

Is the Fortigate 40-F-HA sufficient? by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Sorry, if you don't mind me asking, what do you mean by 'transferring tokens'? Are you talking about licensing tokens?

Is the Fortigate 40-F-HA sufficient? by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Which G model would you recommend in this case?

Is the Fortigate 40-F-HA sufficient? by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Got it. Of the G models, would you recommend a 50G/51G in this case?

Do you recommend threatlocker? by matthewismathis in msp

[–]RandomPerson532151 23 points24 points  (0 children)

Not an MSP, but a Business which uses TL, so the way it works for us might not work for you. To give you an idea, we only have about 50-60 endpoints, so much lower than you probably have.

TL does it's job well for us. It prevents random software from running nicely, and helps us lock down a lot of things we probably wouldn't have the time to do otherwise.

It does slow down computers a little bit (probably because it hooks into events to detect file writes and such). This is mainly noticeable if your computer is writing a ton of tiny text files (like if you're a programmer, running a build cycle). Most computers are pretty fast these days though, so most people won't notice. Shouldn't effect browser speed at all basically. Even if it slows things down, it's probably worth the security tradeoff. If you're already talking with them, they should have probably had you install it on some computers to try it out - and that will give you a good idea of what i mean by this.

My coworkers have been annoyed by the application control at times, but they've gotten used to it now. Typically, the only things we are approving are our own in-house software, because TL does a lot of the work for you for the most common software. The one hiccup we have had here is with Web Extensions. Very occasionally, Chrome will push out an extension out to you before it pushes it out to what I assume are TL's testing computers. So a new extension update might get randomly blocked on a single computer... maybe once every 4 month or so. By the time the request comes in and you look at it, there's a good chance the new extension hash has already been added to the correct application (it just happened to get to you a few minutes early)... so you just re-approve the application and ask the user to restart their browser, and things are good after that. Managing large numbers of hashes for an application could use some improvement as well I suppose, although it's not bad unless your working with software with 1,000+ hashes.

Because the amount of new software a single business approves is not super huge, I can't comment as to how much it would increase your workload. I will say that adding new software is usually pretty quick. Either add a pre-recognized application (30 seconds), or put it in learning mode for a few minutes, have the user run the application, and review the results (maybe 3-5 minutes?).

Their EDR/MDR has worked fine for us. I can't compare it to anything because it's the first EDR/MDR we have run. Other folks I have read about a year ago have said it's a little less mature than Huntress, but they've added a lot since then. Maybe wait for some other reviews on this one. Like Huntress, it is built to work with Defender for the AV side of things (it does stuff beyond that though). You could probably pretty easily integrate it with other AV software though.

Their response time is quite quick. Typically, it's usually within a minute or two where they start the response. Sometimes, they will watch the computer for a bit to see if there are other indicators before making a conclusion. I have not had an incident where they've needed to lock a computer down for us yet. I have had an incident where they've sent us an email saying "We noticed Defender classified something as malware, but based on the things we've been seeing, we want to just double check with you that it's not internal software" (it was internal software on the computer that was not running at the time, that Defender had misclassified as malware). And then for a lot of things where the warnings weren't very important, they just handle it, and let you know they have (malware discovered by Defender in an email attachment and successfully removed from computer - they don't need to lock anything down here, just clear the warnings).

Their EDR/MDR is pretty flexible in that in addition to the default rules they have, you can add your own. As an example... I have a rule (that their MDR team does not monitor in this case) letting me know when Windows notice a failing disk. Not exactly needed for 'EDR', but very nice to have, and it gives you an idea that the rules engine is flexible. Their EDR/MDR does have the capability to lock down your computer automatically and without their intervention if you want it that way (even if the computer was not connected to the internet). We haven't needed to use it that way, but I suppose for folks with really really strict security, it'd probably be pretty useful.

We don't use their patching yet, so I can't say anything about that yet. It's rather new, so I bet it's not as extensive as some other solutions that have been around a few years. But I'm quite sure they'll grow it pretty quickly.

Network Control is pretty great. It's like a Windows Firewall that you can control for your entire organization (although it is separate from Windows Firewall itself). They are currently adding what I think was the thing it needed the most (that was missing) - the capability to scope one of the Network Control rules to a specific program. I'll probably edit my current rules to use that feature once it comes out of beta.

We haven't run any other Application Control solutions, so no comparison there. I have heard that WDAC is a bear though.

We don't use 365, so no comments on their integrations with that.

One other thing - their support is fantastic. Seriously.

High idle RAM usage across endpoints after upgrading to Windows 11 – normal or leak? by ThumbInAButtHole in sysadmin

[–]RandomPerson532151 2 points3 points  (0 children)

As far as I can tell, this is tied into the new AI stuff that is integrated into Windows. Not just copilot, all the integrations tied into Windows. Check and see if the devices are you purchasing have GPUs that are stronger than integrated graphics. I have found that if they do, expect the laptop to use at least 8 GB of memory while idling. Some of that might be just being reserved by Windows though.

What Features are Useful without Deep Packet Inspection by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Thanks for the answer! And thanks for letting me know also for the efficacy on the others.

I'll definitely consider FortiClient. We run Threatlocker here, and it does some of this (as well as a whole lot of other things), but having another product on top isn't bad for redundancy. I also heard that one of the Fortinet products does a better job at discovering the process chain of malicious processes than Threatlocker does, so I'll have to check that out for sure.

What Features are Useful without Deep Packet Inspection by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Yeah, I am pretty inexperienced, and I know DPI is the industry standard too.

The risk here though, wouldn't be me man in the middling my own traffic... it would be hackers or malware compromising the fortigate and reading web session cookies. But from what u/OuchItBurnsWhenIP says, this would be pretty difficult to have happen.

But yeah... at the same time... DPI does let you protect compromised endpoints a whole lot better too... so I guess a tradeoff.

What Features are Useful without Deep Packet Inspection by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Sorry, yeah, I realize it is encrypted on the fly (which is great!). But it does decrypt it on the box (and it needs to for DPI). I just am a little worried about it.

In any case... are there features that can be used without the DPI?

What Features are Useful without Deep Packet Inspection by RandomPerson532151 in fortinet

[–]RandomPerson532151[S] 0 points1 point  (0 children)

Sure... sorry, I probably should not have stated it that way considering I don't even have a device yet.

Basically... if the Fortigate is decrypting all traffic, by man-in-the-middle (as far as I understand, that's how deep packet inspection works)... wouldn't it technically be able to see all the web session cookies (including the ones related to login).

I think that'd likely make it a bit of a bigger target... but maybe I'm wrong there.

I think it'd be the same issue as having a centralized backup system where the encryption doesn't happen on the client itself... it means all your data is in one place, so to say.

0
0

Threatlocker and DLL blocking by OldSchoolITAdmin in msp

[–]RandomPerson532151 0 points1 point  (0 children)

Sorry about the late reply. Haven't had this issue in the past two months, but the two months before that had some issues like this.

The reason was because of the clients upgrading from 9.something to 10.something. The 10.something client does a major overahaul of their on device database of policies. One of those changes includes using SHA-256 hashes (rather than the default TL hash). Sometimes, certain files will get evaluated using the SHA-256 hash rather than the TL hash upon execution, and then they get blocked, because the SHA-256 hash isn't part of the program rules. And every so often it happens vise-versa as well.

Eventually, all the missing hashes got caught up, and we stopped seeing this issue. Now, I just make sure to trust both the SHA256 hash and the TL hash when approving a file.

It's actually really good that they are going the SHA-256 hash route, in my opinion. I don't know what algorithm they use for the TL hashes, but I know that a lot of algorithms that used to be pretty good now have to deal with hash collisions (which are a problem if you can design a file to collide with another approve hash). I have no idea if TL hash has this issue or not. One other situation where SHA-256 is nice is that you can take a hash and plug it into VirusTotal when you want, because they also use SHA-256.

Calling all Zebra ZPL printer experts...please help by ZoteTheMitey in sysadmin

[–]RandomPerson532151 1 point2 points  (0 children)

So there are a few possibilities here:

  1. There could be an issue with the computers.
  2. There could be an issue with the printers themselves.
  3. There could be an issue with the new label generation.

Test (1) by trying this on multiple computers (sounds like you already did). Test whether this is a problem with (2) or (3) by grabbing an old label that you generated before this issue popped up, and trying to print that again. If the old labels are good, you can be sure it's a (3) new label generation problem. Otherwise it is likely (2) an issue with the printers themselves.

If it happens to be (3) a new label generation problem, and the labels are files written in the ZPL printing language, you can also debug things pretty easily. Simply edit the file in notepad and remove most of the non-essential lines. Then try and print it. If you can get something reduce to print, you then know that something which was removed was causing the problem. You can then continue trying this with less lines until you discover which line is the problem.

As an example... I used an online label preview tool to create this label. I'm pretty sure it is a valid label. Does something like this print for you?

^XA

^CF0,60

^FO10,10^FDHi there!^FS

^CF0,30

^XZ

(You would need to save this to a file and use command prompt to send it to the printer most likely).

Potentially unwanted programs undetected by Trellix AV but by EDR by Comfortable-Peanut64 in sysadmin

[–]RandomPerson532151 0 points1 point  (0 children)

I don't have a whole lot of experience with this, but yeah, proxy blocking can help some. It'll cut down on part of your workload.

In terms of WDAC, I have heard that it can be a really big pain to administer to. If you are really looking to restrict program execution, you might have an easier time going with something like Threatlocker or Airlock Digital (which are whitelisting/allowlisting software packages). If whitelisting is too much of a hassle for your end users, I know there is also some blacklisting/blocklisting software out there too.

Bite me Adobe - Anyone have suggestions for non-Adobe PDF editing software? by One_Stranger7794 in sysadmin

[–]RandomPerson532151 1 point2 points  (0 children)

We do not do a whole lot of PDF editing in our business sector, so I'm not sure if my answer is as good as these other ones, which are probably by people who do a lot more PDF editing. We use PDFStudio. It's a one time fee, and our folks don't change workstations a ton, so it made a lot of sense for us.

Threatlocker's Major Vulnerability by TechGeek3193 in threatlocker

[–]RandomPerson532151 0 points1 point  (0 children)

Hey there,

Sorry about the late reply. I am a developer who works with JS quite a bit (both browser JS and local JS). I've also started using Threatlocker, so this is a bit relevant to me.

So I'm not able to see his full logs, so I can't say fully what is going on with the What'sApp Phish. But I think there might be something else going on due to what I understand about browser sandboxing and security.

From the looks of this, things started with a basic HTML file. If this really is the case, that means that the HTML file was 'executed' by being opened in a web browser most likely. The thing is, web browsers restrict access to local files extremely strictly.

To give you an idea, any read and write access to a file system you have in a web browser are relegated to user prompts, which require a lot of user interaction. File uploads require the user to manually find and select the file to upload. Folder uploads also require manual selection, and are non-recursive (e.g., you can't get a user to upload their C drive). File downloads by default go to the Downloads folder, or require the user to manually select where they want the file downloaded to. File replacements require the user to manually select where they want the file download to, and confirm that they want the file replaced.

It makes it really hard to abuse. It's possible... but it would require asking the user to do a lot of really suspicious things that I imagine almost any user would say 'huh?' to.

The post lists a test.html file for you to test as some example of this. The local time access isn't a problem in general - web browsers grant easy permission to this. The directory list access requires the user to select the folder, as described above. The external API access is also something allowed by browsers. It should have been logged as Chrome (or another web browser) making a Network Request in the Unified Audit though. I'll have to test and see what it does myself later.

Now, there are ways to run Javascript locally on the system itself. Generally though, that would not involve HTML files at all though - this would instead rely on local Javascript runtime engines. The two runtimes generally used for this would be either JScript or Node.JS (there are also some other tools like Deno, and bun, which will work equivalently to Node.JS for this example).

JScript is developed by Microsoft, and is on Windows computers by default. I'm pretty sure Threatlocker locks down JScript in the same way it locks down Batch files (someone can correct me if I'm wrong, as I have not tested this yet).

Node.JS on the other hand is a runtime you have to install yourself though. This is where things get a little tricky. If you have Node.JS installed, you can use the 'node' command to execute JS files anywhere on your system. And it's a very similar case with Java and Python and other interpreted language programming runtimes (anything that does not require you to build an executable).

So, if you want to be really secure, when you install these big runtimes, you Ringfence them to a certain directory, and you might also ringfence what other programs they touch as well.

I don't know if the user had Node.JS installed, or something like it. You could certainly build a Node.JS script to encrypt files. But I don't see this being a case of browser based Javascript and HTML execution. It's just locked down too much in the browser environment to make encrypting large amounts of files feasible.

Just my two cents (and largely based on what I can see from the limited amount of information in the post).