I don't know if this was an effect of the shellshock attack which my server was victim to (or another attack that worked) but it basically enabled the hacker to overwrite my SSH config file when the server rebooted.
This new file used wget to load in a file from a website, then another library of hack functions which I guessed he then used to run hacks/DOS from my server. I caught it pretty fast and ideally want to upgrade but because I have cancer and just had a big operation it is too much effort at the moment.
Therefore I did a lot of house keeping, changing passwords, removing shell access, reverting back to DASH, replacing the default shell for root and any other users to another folder with symbolic links, restoring the config file for SSH, removing CGI functionality from config files e.g
ScriptAlias /cgi-bin/ /home/searchmysite/cgi-bin/
#
allow from all
#
Removed AW stats and Webalizer for all virtual min sites.
I already had DenyHosts and Fail2Ban installed.
I also blocked in/outbound traffic to the IPs of the sites he was getting the files from.
However it seems since this change I have lost the visual cron manager from webmin.
When I go to the menu item "Scheduled Cron Jobs", it says, "The command crontab for managing user Cron configurations was not found. Maybe Cron is not installed on this system?"
However I can see in the file system it exists.
When I run crontab -l or crontab -e I get "Permission Denied"
whoami shows "root"
I did think at the time of the hack this was all related and he had used SSH and a Cron job to get his hack running.
What I want to know is how I can get the CronTab manager back.
All the cron jobs are still running such as importing feeds into my websites, running scheduled emails and so on, what I don't know is how to resolve this without a full rebuild.
If I had the time and energy I would do that but I am totally drained and before this hack everything was just running smoothly and my websites which bring me in money were working fine.
They currently are still working fine and I regularly check my logs for IPs that look odd, have strong htacess rules for xss/sql/path travesal/file hacks and ban whole countries from Cloudflare which the site sits behind. So I don't "think" the machine is compromised at the moment even if it is old - could be wrong though!
details of box
Operating system Debian Linux 5.0 Virtualmin version 3.98.gpl GPL WebMin Version: 1.610 Kernel and CPU Linux 2.6.32.9-rscloud on x86_64
So if anyone can help me get my crontab manager back that would be great.
Thanks
1) check if chattr exists, if not, download a new one.
2) type whereis crontab, then chattr -isa /path/to/crontab.(usually /usr/bin/cron) then chmod crontab back to it original settings.
3) navigate to /var/spool/ and
chattr -isa cron
cd cron
chattr -isa crontabs
4) remove cron entry in /etc/cron.weekly
Look in /etc/cron.weekly for any new
Related
I referred many solutions yet no luck. I have a linux automation which runs few gcloud commands with some conditions. I made this script with node js, but it is incredibly slow that I even finish it manually before the scrips completes the run.
Same with the gcloud commands when I connect to a cluster and kubectl commands when i query something.
Please help!!
It could be a DNS config error on WSL side. I hadthe same issue today, here's how I fixed it !
1. Checking the (deadly slow) response time
[tbg#~] time kubectl get deployments
No resources found in default namespace.
real 0m1.212s
user 0m0.151s
sys 0m0.050s
2. Checking the WSL/DNS configuration
[tbg#~] cat /etc/wsl.conf
[network]
generateResolvConf=false
[tbg#~] cat /etc/resolv.conf
nameserver XX.XXX.XXX.X
nameserver YYY.YY.YY.YY
nameserver 1.1.1.1
If you see that, remove these lines to get back to automatic resolv.conf generation and restart WSL (wsl --shutdown)
3. Checking the (fixed !) response time
[tbg#~] time kubectl get deployments
No resources found in default namespace.
real 0m10.530s
user 0m0.087s
sys 0m0.043s
I found out my resolv.conf configuration was causing that latency, by trying to reinstall kubectl with apt, and finding apt really slow too
Right now access to /mnt folders in WSL2 is too slow and by default at launch the entire Windows PATH is added to the Linux $PATH so any Linux binary that scans $PATH will make things unbearably slow.
To disable this feature, edit the /etc/wsl.conf to add the following section:
[interop]
appendWindowsPath = false
Avoid adding Windows Path to Linux $PATH and best for now is adding folders to the $PATH manually.
Terminate the WSL distro (wsl.exe --terminate <distro_name>) to make it immediately effective or wsl.exe --shutdown and start the terminal again.
Refer to the stack link for more information.
I've just set up my first cron-jon to run a stock script every night.
Running it manually works fine.
It's stored in /admin/stock_update.php
The command i'm running is /usr/bin/php -q /admin/stock_update.php
But I'm getting emails saying no input file is specified?
Any ideas?
Cheers
Network services almost never expose actual paths on the server's hard disk drive and even if they could it isn't a behaviour you can rely on. So the fact that your file is located at /admin/stock_update.php in the FTP server doesn't say much about actual location on disk, which is what local command-line utilities expect.
In PHP, you can find path on disk of current file with the __FILE__ magic constant. You can create a test script:
<?php
var_dump(__FILE__);
... upload it to the same FTP location and execute through the web server. If that's not an option because files in your FTP account in not visible from the web you can run the file from cron and check the email.
Do you have CloudLinux kernel installed on that server and CageFS filestyem? If yes try running this:
cagefsctl -w cpaneluser; cagefsctl -m cpaneluser
Then try running the cron again
I am currently writing an admin page for my webserver, to make it easier on myself to create new apache domains from my browser. Everything is pretty much working as I want it to, except for one thing.
To elaborate: I have a cron job on my server running a bash script as root that checks a file containing a list of domain names that I want to be created. If the file contains a domain name, it automatically creates a new virtual host for this domain, edits my hosts file, and restarts the server. This all works perfectly, however what I would like for the script to do, is that it activates the domain that it automatically creates before it restarts the server. I tried doing this using apache 2's a2ensite command, however the script returns an error saying the command is not found.
Is there a way to call this command from a bash script, or is there an alternative to this command that I can call?
Any help would be greatly appreciated.
$ which a2ensite
/usr/sbin/a2ensite
Usually, cron has a quite restrictive $PATH, not including /usr/sbin or /sbin, which are system binaries (for use by root). It's always a good idea to use fully qualified path names. So either call /usr/bin/a2ensite in your script, or define a variable:
A2ENSITE=/usr/sbin/a2ensite
...
${A2ENSITE} new-domain.com
For some tests I'm doing, I'm required to remotely tail the apache access log via ssh. I can successfully do that only when the permissions are accurately set for the log. I've noticed that once a week, a new apache access.log is created and the permissions are reset.
My current work around is editing the permissions on the log once a week:
chmod 644 /var/log/apache2/access.log
I was wondering if there was a more permanent solution such as extending the time that the old log remains or automatically setting permissions when the new log is created.
If it matters, I'm running the server on Ubuntu 11.10
Edit your logrotate.conf file to set the correct owner/permissions for the apache.log file. Something like this:
/var/log/apache2/access.log {
weekly
create 0644 root utmp
rotate 1
}
(Edit: Changed mode from 0744 to 0644. No need to set the execute bit.)
Maybe another application, like logrotate, is altering the logs? (Sounds like it, as it only happens weekly) I don't think Apache itself is responsible for the permissions chance.
A good place to start is check /etc/cron./* to see if any cron jobs are touching the access.log
Good luck!
I had a cronjob set up to run a php script daily, which went well for about a month. Today, I realized it didn't run the script so I opened up the crontab. The crontab is completely empty - what happened?
I don't know too much about cronjobs, but as far as I understand, they do not delete themselves if the server is reset. How can I make sure cronjobs are always running and that it doesnt get deleted?
It is probably under a different user. Check root user sudo crontab -e. Each user has it's own crontab and there's one for the whole system. Note: Through the crontab configuration you can disable per-user crontabs.