@LLamaPie Well keep an eye on it, my concern is that there is a bug in php that allowed this to happen some how. Its in the http path and not the nfs path. Hopefully you will scan and or keep an eye on the cpu usage. When you detect a change surely review the apache logs both error and access as well as login logs to abnormal activity.
Moderators
-
RE: Massive CPU usage from a service
-
RE: An Error detected, fails capture
@adam1972 that is the debug shell, you can try the efsck command in debug mode then use the command ‘fog’ to step through the capture process
-
RE: Active Directory join error 2732
@mentaluproar sadly, due to the windows updates previously mentioned, which are actually fully enforced in the 2024-08 updates, a domain admin account is pretty much required to join the domain in an automated fashion. Microsoft gives some guidance on creating policies to allow a least privileged account but I haven’t been able to get that to work with fog. Granted, as long as your aren’t granting access to the fog gui to non privileged users, saving those creds in fog is safe and secured.
-
RE: Kyocera TASkalfa 5040ci - won't staple or punch
@lstassen is the driver the one you expect from the inf when it is installed via fog?
When manually installing are you running an install package?
Is there maybe a device settings tab where you need to tell the driver that the printer has the feature. You can use the fog printer settings file to save and deploy such settings. I haven’t used that feature in quite some time but I helped make it and this type of configuration was why it was added. -
RE: Massive CPU usage from a service
@Tom-Elliott The key is that its post the security update for FOG.
The question I have is:
- How did that file/malware get onto the server
- Why did it pick that specific path to hide in.
- When was the server compromised. The date on the files in that directory may give us a clue.
- Could it happen again? We don’t know because we don’t know how it was installed.
It almost seems intentional and deliberate to pick that specific path. I don’t think apache normally has write access to that path.
@OP is your fog server exposed directly to the internet?
-
RE: Massive CPU usage from a service
/var/www/html/fog/management/.sys
Is not something that FOG creates. ref: https://github.com/FOGProject/fogproject/tree/stable/packages/web/management
.sys file / directory name means the directory is hidden unless you use the command
ls -la /var/www/html/fog/management
also.systmd
is a hidden file made to representsystemd
application.I did find this article: https://sarperavci.com/ironshade-writeup-tryhackme/
So the question is how was this server compromised and if we don’t know it will probably happen again. What version of FOG did you have installed?
-
RE: Unable to Capture Using Single Disk - Resizable
@shatchett0 So it is working now on the new install?
-
RE: Windows on ARM
@MarkG OK let us know because there is some info that you can collect on these devices to help the developers validate the code.
-
RE: Having main server automatically task storage node for imaging based off client IP/SUBNET
@JamiesonCA092 ok it shows you have some debugging skills, so I’ll add a few new tools into your toolbox.
- on the fos linux (target computer) when you schedule a task and tick the debug checkbox, when you pxe boot the target computer you will be dropped to the fos linux command prompt.
- You can start the imaging process in single step mode by simply keying in
fog
at the command prompt. - The script will run until it hits a
debugPause;
command in the script. You can add that command in your custom script with echo statements to understand how your script is running. Pressing the enter key will cause the script to run again until the next debugPause command. - At the fos linux command prompt if you get the ip address of the fos linux (target computer) with
ip a s
and then give root a password with thepasswd
command (make it simple like hello, it will be reset at the next reboot). Once you have those 2 bits of into you can use putty or ssh from a second computer to the fos linux computer for debugging. Using this method you don’t have to sit in front of the target computer plus you can copy and paste using the putty/ssh session. - If you need to stop the
fog
script during hit ctrl-c to skip out of the script. At this point you can verify the environment, check the available variables, etc. When you are done looking around, then you can enterfog
again to begin the imaging process once again. No reboot needed. - In the fog script the kernel parameters sent to fos linux are converted to bash script variables in the functs.sh script between lines 9 and 13 https://github.com/FOGProject/fos/blob/0efdd68f1783a06f3214607fc313db50747fbc43/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L9
I’m pretty sure Wayne is right that the varialbles in the postinit script are local and will be erased when the script terminates. But I would test to be sure.
One last hack I can think of is that you can hack the fog.mount script https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.mount Put the logic to decide the target’s IP address into that script. The concept of dynamically patching the fog.mount script can be found in this tutorial (which addressing the fog.man.reg script) https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg but the concept and actions are the same.
-
RE: Track activity for unregistered hosts
@DBCountMan In the post init or post install scripts the
$mac
variable contains the mac address of the target computerTo get the ip address this script will work
myip=`ip route get 8.8.8.8 | awk 'NR==1 {print $NF}' | cut -d "." -f1-2`;
Getting the user id of who did it will be a bit harder since they never log into the web ui. The user ID and password they key in during the deploy image stays in ipxe and is not sent onto FOS Linux. I’d like to say that the username field can be trapped from iPXE and then pass that variable as a kernel parameter onto fos linux. Once that is done then the $username variable should exist in your fog scripts. Getting that info into the fog database is another challenge. In the post install script the /ntfs directory is mapped over to the fog servers /images/dev where you could append an echo statement into a text file.
Understand I’m taking in programming pseudo code. But I see an path here and it should work.