We should consider offering a 'Testing Mode" in Virtualmin which makes adoption of Virtualmin easy for the complete newbie - and this newbie will likely not be from US / UK or other developed nation of the world, but from new and hitherto underserved areas. Our friend @Alaaeddine.benabid fits the profile of the next set of Virtualmin users. One must admire him for sticking it out despite all the difficulties that he has had with his server; and such difficulties can be made avoidable for all future users of Virtualmin by offering a testing mode with the following changes and enhancements:
DNS and mail relaying is offered out of the box in test mode
disable other php execution modes - offer just php-fpm in test mode. Other execution modes can be applied only when test mode is disabled.
in php, disable mail(). This can be enabled only when test mode is disabled.
add mail rate limit option for a virtual server in the Edit Virtual Server screen so that it is not overlooked
These changes come immediately to the mind. A few more could be added to the list to make Virtualmin testing mode offer a very secure and spammer-proof sandbox type environment for complete newbies to get started with Virtualmin.
Let a Virtualmin newbie made a conscious decision to switch off testing mode and put his system in production mode to access those features of Virtualmin which could get him into trouble if he deviates from default without understanding what he is doing.
Of these, only disabling features in PHP-FPM might help with the case in question. But, itâd also require disabling exec, shell_exec, and maybe some others, since PHP can send mail many ways. And, it might not help, it depends on how mail is being sent; it doesnât have to be sent via PHP, but thatâs one possibility.
Rate limiting would delay the inevitable, perhaps, but based on past topics, the problem wonât be solved, and so port 25 will end up blocked anyway.
Anyway, I think we should allow more configuration of PHP-FPM, such as disabling some features. Right now, it requires manual configuration, I think.
Dear Mr Joe my problem if it is I want to clarify I do not know how people have total access to send emails are they going through fixed mail and even if I delete all the boxes there is still access with these people and I am sure that it is not among my users or my clients it is almost pirates who can access my server so that they can use it without my permission
and of course the php web site code may contain itâs own function to access the system directly, I have written a version of exec that suits my needs and wonât be disabled unless you know the function name. So they could still get in with disabling all the âknownâ functions. I have tested this out, and with a custom function you can still get in. With code I have written you would have to disable
proc_open
fwrite
fclose
stream_get_contents
proc_close
but there are bound to be other methods to achieve this, maybe a full code review is a better option in this case rather than making stabs in the dark as to how the attacker is gaining access
You should find that out, by looking at logs. I donât know why youâve historically refused to do that. But, itâs the first place to look.
If you donât see it in the mail log (or the journal for the postfix unit), then you need to look in the access and error logs for your websites. You also need to audit what code is being run.
If you canât find it in the logs, you can use wireshark (tshark on the command line) to watch for traffic to port 25 outside of your server.
But, you need to figure out what is happening before you can fix it. Youâre just doing a bunch of random things with no reason to believe theyâll do anything useful.
To be clear, if itâs not your users, then itâs almost certainly some web application youâre running thatâs allowing mail to be sent. It may have other exploit code in place, like a web shell or cron jobs to reinstall their exploits if you happen to stumble on some of the files.
I donât like this rather jingoistic assumption there are many people in those excluded dominions that would consider themselves far better/equal/developed.
Sure there are ânewbiesâ and different classification of newbie (I was one once - new to Webmin/Virtualmin for sure, but not to system admin (now 40+ yeas) and over 10 years retired)
I would be far more worried about putting these excluded foreigners off using & learning Webmin/Virtualmin.
We will be suggesting an exam or test next? Issuing some certificate of competence perhaps?
I remember when I first installed Virtualmin (coming from Plesk a long time ago)⊠and how I wished for videos that would walk me thru things. I guess Iâm at fault, after all this time and Iâve not made any videos. But this testing mode sounds interesting.
I do apologise. You are right, of course - a newbie to Virtualmin might not be a newbie to systems adminstration. I come from a nation with a large population and a part of my work involves getting underserved geographies online - not only here but also in places like Sub-Saharan Africa. It is in this context that I say that the next crop of Virtualmin and Cloudmin users will come from these areas.
Mr thank you for your efforts but the problem is that it is that I am bad but I am here to understand with the help of people on the forum and understand and thank you another time
There is a log viewer for Virtualmin domains websites (both access and error logs) in the Logs and Reports menu for each domain.
There are multiple ways to view the mail log, and it depends on your OS and version as to which one you need to use. You may have a /var/log/mail.log or you may have a /var/log/maillog or you may need to look at journalctl -u postfix. With the journal you can specify a date. With the log files, you may need to unzip rotated out older logs.
There is a log viewer in Webmin that will allow you to view either log files (System Logs) or journalctl output (System Log Viewer), but for precise control of journalctl, you need to use the command line tool. Iâm not going to tell you how to use journalctl, because it is well-documented.