<div dir="ltr">For SSH access, I think it's a good idea to only allow admin and root users:<div><br><div><div>echo "AllowUsers admin root" >> /etc/ssh/sshd_config</div><div>echo "DenyUsers test httpd apache" >> /etc/ssh/sshd_config</div></div><div><br></div><div>And for crons, only root</div><div><br></div><div>echo "apache" >> /etc/cron.deny</div><div>echo "root" >>  /etc/cron.allow<br></div><div><br></div><div>A little redundant since one or the other would do it. </div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 15, 2016 at 8:48 PM, Michael Stauber <span dir="ltr"><<a href="mailto:mstauber@blueonyx.it" target="_blank">mstauber@blueonyx.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mitchell,<br>
<br>
> If I see this - what should my first (second, third and fourth) move be -<br>
> it's a hacker with the IP listed as China.<br>
<br>
Blow it away. Then start fresh and cmuImport. You might perhaps get some<br>
ideas or advice about how to "clean" the box. But it appears the<br>
intruder has at least unprivileged shell access - if not even privileged<br>
shell access. That means: All bets about the integrity of the box are<br>
off. The only safe and reasonable approach is to restore from the backups.<br>
<br>
As for locking a box down and preventing this: Never administer the box<br>
through insecure means. So no Telnet or non-HTTPS GUI access. Any user<br>
who has a shell must never connect to any service on the box in a<br>
fashion that transmits the login details in the clear. Ideally: Only you<br>
should have shell access to begin with. Even users who don't have a<br>
shell should not connect to any service without using TLS or SSL.<br>
<br>
My recommendation is to only allow GUI access via HTTPS, which can be<br>
configured via the GUI itself.<br>
<br>
SSH: Even if you don't have APF installed you can use the GUI to<br>
reasonably secure it:<br>
<br>
- Generate a SSH key and PEM certificate via the GUI. I recommend a<br>
minimum key length of 4096 bit.<br>
<br>
- Turn off password authentication for SSH<br>
<br>
- Only login via SSH key or PEM certificate.<br>
<br>
If APF is installed: The SSH GUI management page then gets extended by<br>
an APF module and you can lock down SSH access via GeoIP, so that logins<br>
only work from certain countries. Additionally you could add APF rules<br>
to only allow logins from certain IP addresses. Use this to make SSH<br>
inaccessible to everyone but your own static IP addresses that you use<br>
to administer the box.<br>
<br>
FTP, POP3, IMAP: Turn off all non SSL services and only use the SSL/TLS<br>
enabled services.<br>
<br>
Sendmail: Leave both SMTP and SMTPS on. You could make do with just<br>
SMTPS enabled, but in the longer run this will cause some issues with<br>
receiving emails from stupidly configured other servers that you might<br>
want to receive email from.<br>
<br>
If a site uses Webmail or login forms that take account information<br>
(username + password), it should have SSL enabled. If it doesn't warrant<br>
buying a real SSL certificate, then throw a "Let's Encrypt" certificate<br>
at it.<br>
<br>
Dfix2: I recommend using at least Dfix2 in combination with APF. It<br>
detects and blocks a lot of brute force, probing, prodding or prying<br>
attempts.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
With best regards<br>
<br>
Michael Stauber<br>
______________________________<wbr>_________________<br>
Blueonyx mailing list<br>
<a href="mailto:Blueonyx@mail.blueonyx.it">Blueonyx@mail.blueonyx.it</a><br>
<a href="http://mail.blueonyx.it/mailman/listinfo/blueonyx" rel="noreferrer" target="_blank">http://mail.blueonyx.it/<wbr>mailman/listinfo/blueonyx</a><br>
</font></span></blockquote></div><br></div>