Snapin script interrupted by Hostname Changer before completion (I think)
-
@Jbob That would mean, i could securly put my arguments here:
and in the script I connect my share like
net use \\share\folder /user:%1 %2That would be a great feature!
-
@michael_f That’s the idea. and if this can be removed from the fog logs as @jbob said, it’d be pretty legit.
-
@Wayne-Workman Thank you for clarifying this for me!
-
@Wayne-Workman and @Jbob I fully agree that you should never use plain text passwords, very bad idea! Like I was saying the randomize password script I was thinking about was to work around limitations within FOG at the time, including now for that matter. If the password changed at times the attack window would be minimized. If someone did get the password it would expire during the next change and no longer be good. This also would eliminate the human error of “random” passwords, all random passwords by humans are bad, and mostly predictable over time.
@Jbob That would be great and make it much more secure, if we could hide the snapin details in the log we could negate plaintext passwords all together. But they can still be intercepted using @Wayne-Workman’s example of scanning tasks with MAC’s as the information is still transmitted and read by the client.
The other thought I had in regards to the client being able to support this type of thing is if we could have the option to map a network share through the snapin management. Have a check box for “map network share and use that location”. Then have a configurable share location in the database. The client would map the share, launch the snap in, perform the task, and disconnect when finished.
As for simplicity the hiding details would be easier and less prone to bugs. But a configurable default share with a check box would be a quicker way of reusing a share for multiple snapins over time.
The problem is anything is hack able given the determination of the attacker. The question is how much effort do they need to put in and how much convince do you give up? Not trying to be negative about it, but it is what keeps us in jobs. I enjoy the discussion and glad that we can discuss the ideas/issues/solutions we have to make FOG a better and more secure system.
-
@ITSolutions said in Snapin script interrupted by Hostname Changer before completion (I think):
But they can still be intercepted using @Wayne-Workman’s example of scanning tasks with MAC’s as the information is still transmitted and read by the client.
Ah, didn’t even think about that, even when I was looking at the plain-text snapin arguments in a web browser using the below GET method. But I’m positive a determined hacker would have thought about it. I’m not in the business of trying to hack FOG, the things I said below were just passing thoughts, no real effort was put in.
I think what I was looking at though was for Legacy Client compatibility. The New FOG Client gets it’s snapin info via encrypted communication as @jbob said earlier.
So… I guess we need a way to disable legacy client support should someone want that, and again @jbob is two steps ahead and already mentioned it.
-
@Wayne-Workman I am not in the business to hack FOG either. But as I work in healthcare and we are a small shop one of my many hats is security, with PHI concerns I think about all possible attack surfaces. We have regular audits of our security and have to justify any thing that is of questionable nature. Right now I am working on closing up a few other areas, and I have been thinking of ways to harden software deployment through snapins. Currently we have a separate vlan for FOG and only deploy snapins at time of imaging, then remove the log and use the client just for user tracking and rebooting basically. I will push small single file snapins, if I need to, but nothing that needs to connect to a share due to not having a good way to do so. I love FOG and it works great, just like to include my thoughts on things to help further FOG and keep it as secure as possible along the way.
FOG 2.0 will be a huge advancement again I am sure. Just like 1.3 is truly leaps and bounds better than .3x was. I thought .3x was great, but the issues were definitely addressed. With all software there is always compromises to maintain backwards compatibility for longer than any @Developers would really want to do. In my opinion 1.3 is not just a decimal increment to 1.2, it is much closer to a 2.0 version. But with the true 2.0 they can finally drop support for the legacy client, partimage, and it sounds like move away from PHP. It will definitely be a more robust and modern system.
