<div dir="auto">A secure and unique password should be step 1.<div dir="auto"><br></div><div dir="auto">For most who don't accept incoming connections on their home network, (meaning no opened ports on the router -- Using NAT) you are very secure.</div><div dir="auto"><br></div><div dir="auto">Still good practice to make a complex password and a different ssh port.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 4, 2018, 09:15 Mike <<a href="mailto:mm@midnighteng.com">mm@midnighteng.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While I don't have time to get into a in depth discussion on this,<br>
I just want to raise awareness with those that read.<br>
<br>
 From time to time I remind some folks about some security issues.<br>
<br>
It is normally said to anyone to change your ssh port in your first <br>
steps, and most will do that if they know how, but if you don't, please <br>
ask someone as it is important.<br>
<br>
The latest ASL package has a nice working firewall that can be enabled <br>
from a command line menu (asl-menu) and there is no excuse for not <br>
enabling this. But I encourage you to do it in the first steps of your <br>
install. You may need to re-run the scripts from the menu as your port <br>
usage changes, but it's still a simple thing to do, even if your command <br>
line skills are low. The dev team did well on this. It's easy !<br>
<br>
The reason I am encouraging you to do this in your first steps, within <br>
hours of your install is that I am seeing faster much more craftier <br>
hacks that do not do much more than watch as the server goes up and <br>
capture ssl data and or passwords, but take no initial actions.<br>
Only to come back later and use that data. Really just have their way <br>
with it.<br>
Whole disk back-ups may not be effective in restoring because the <br>
sleeper software may be captured in the backup, so you may just be <br>
giving them a easy in the next time.<br>
<br>
Back-up your important conf files separately, no matter what other <br>
method you use.<br>
<br>
Marking the 'bad guys' by IP with repetitive rejected attempts is <br>
starting to fail for me on certain servers unrelated to ASL because they <br>
seem to have a unlimited supply of IP's they can use. They don't use the <br>
same IP often the same day, but hit the server twice a minute.<br>
(many hacked systems just become a launching point to hack others and <br>
use your IP).<br>
<br>
While I have not seen one of these attacks to any of my ASL servers, I <br>
know it's coming.<br>
<br>
I spent the weekend figuring this last one out.<br>
So I remind many of you to take action 'without delay' and do those <br>
basic things to at least slow the progress of hacks.<br>
<br>
1 - change your ssh port<br>
2 - Turn on your firewall and do not enable ports not used.<br>
3 - do not use/enable FTP or the ports for it. SFTP is the only method <br>
you should be using.<br>
4 - Back-up your important conf files/scripts separately, no matter what <br>
other method you use.<br>
<br>
That will at least slow/stop many amateurs that are working from a how2 <br>
they found on the web. Often, when your system is compromised, it may <br>
continue to run as always while they just use it to hack other systems, <br>
so, if you can keep a eye on your cpu/bandwidth usage to see when <br>
something is not normal is a great help.<br>
<br>
While doing 'loss prevention', I have been thinking about how to best <br>
defend our ASL servers going forward. Do to the nature of our <br>
international connections, I am thinking we just need to create and <br>
maintain a whitelist of IP's to the 'system IP Tables' as a whole, not <br>
asterisk only. It should be easy since the IP list is shared as it is, <br>
and we just need to add other outside services IP's to that.<br>
<br>
But I'm still thinking on it. Perhaps this note will encourage others to <br>
think on it as well. These things always get worse, not better.<br>
I may write/experiment with this 'whitelist' idea this winter, but be <br>
aware, if you are not defending your system, you make it all the easier <br>
to hack others as well. Just because your system is running as intended <br>
does not mean it has not been compromised.<br>
<br>
73,<br>
...mike/kb8jnm<br>
_______________________________________________<br>
App_rpt-users mailing list<br>
<a href="mailto:App_rpt-users@lists.allstarlink.org" target="_blank" rel="noreferrer">App_rpt-users@lists.allstarlink.org</a><br>
<a href="http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users" rel="noreferrer noreferrer" target="_blank">http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users</a><br>
<br>
To unsubscribe from this list please visit <a href="http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users" rel="noreferrer noreferrer" target="_blank">http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users</a> and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button"<br>
You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem. <br>
</blockquote></div>