While I don't have time to get into a in depth discussion on this, I just want to raise awareness with those that read. From time to time I remind some folks about some security issues. It is normally said to anyone to change your ssh port in your first steps, and most will do that if they know how, but if you don't, please ask someone as it is important. The latest ASL package has a nice working firewall that can be enabled from a command line menu (asl-menu) and there is no excuse for not enabling this. But I encourage you to do it in the first steps of your install. You may need to re-run the scripts from the menu as your port usage changes, but it's still a simple thing to do, even if your command line skills are low. The dev team did well on this. It's easy ! The reason I am encouraging you to do this in your first steps, within hours of your install is that I am seeing faster much more craftier hacks that do not do much more than watch as the server goes up and capture ssl data and or passwords, but take no initial actions. Only to come back later and use that data. Really just have their way with it. Whole disk back-ups may not be effective in restoring because the sleeper software may be captured in the backup, so you may just be giving them a easy in the next time. Back-up your important conf files separately, no matter what other method you use. Marking the 'bad guys' by IP with repetitive rejected attempts is starting to fail for me on certain servers unrelated to ASL because they seem to have a unlimited supply of IP's they can use. They don't use the same IP often the same day, but hit the server twice a minute. (many hacked systems just become a launching point to hack others and use your IP). While I have not seen one of these attacks to any of my ASL servers, I know it's coming. I spent the weekend figuring this last one out. So I remind many of you to take action 'without delay' and do those basic things to at least slow the progress of hacks. 1 - change your ssh port 2 - Turn on your firewall and do not enable ports not used. 3 - do not use/enable FTP or the ports for it. SFTP is the only method you should be using. 4 - Back-up your important conf files/scripts separately, no matter what other method you use. That will at least slow/stop many amateurs that are working from a how2 they found on the web. Often, when your system is compromised, it may continue to run as always while they just use it to hack other systems, so, if you can keep a eye on your cpu/bandwidth usage to see when something is not normal is a great help. While doing 'loss prevention', I have been thinking about how to best defend our ASL servers going forward. Do to the nature of our international connections, I am thinking we just need to create and maintain a whitelist of IP's to the 'system IP Tables' as a whole, not asterisk only. It should be easy since the IP list is shared as it is, and we just need to add other outside services IP's to that. But I'm still thinking on it. Perhaps this note will encourage others to think on it as well. These things always get worse, not better. I may write/experiment with this 'whitelist' idea this winter, but be aware, if you are not defending your system, you make it all the easier to hack others as well. Just because your system is running as intended does not mean it has not been compromised. 73, ...mike/kb8jnm
A secure and unique password should be step 1. 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. Still good practice to make a complex password and a different ssh port. On Tue, Sep 4, 2018, 09:15 Mike <mm@midnighteng.com> wrote:
While I don't have time to get into a in depth discussion on this, I just want to raise awareness with those that read.
From time to time I remind some folks about some security issues.
It is normally said to anyone to change your ssh port in your first steps, and most will do that if they know how, but if you don't, please ask someone as it is important.
The latest ASL package has a nice working firewall that can be enabled from a command line menu (asl-menu) and there is no excuse for not enabling this. But I encourage you to do it in the first steps of your install. You may need to re-run the scripts from the menu as your port usage changes, but it's still a simple thing to do, even if your command line skills are low. The dev team did well on this. It's easy !
The reason I am encouraging you to do this in your first steps, within hours of your install is that I am seeing faster much more craftier hacks that do not do much more than watch as the server goes up and capture ssl data and or passwords, but take no initial actions. Only to come back later and use that data. Really just have their way with it. Whole disk back-ups may not be effective in restoring because the sleeper software may be captured in the backup, so you may just be giving them a easy in the next time.
Back-up your important conf files separately, no matter what other method you use.
Marking the 'bad guys' by IP with repetitive rejected attempts is starting to fail for me on certain servers unrelated to ASL because they seem to have a unlimited supply of IP's they can use. They don't use the same IP often the same day, but hit the server twice a minute. (many hacked systems just become a launching point to hack others and use your IP).
While I have not seen one of these attacks to any of my ASL servers, I know it's coming.
I spent the weekend figuring this last one out. So I remind many of you to take action 'without delay' and do those basic things to at least slow the progress of hacks.
1 - change your ssh port 2 - Turn on your firewall and do not enable ports not used. 3 - do not use/enable FTP or the ports for it. SFTP is the only method you should be using. 4 - Back-up your important conf files/scripts separately, no matter what other method you use.
That will at least slow/stop many amateurs that are working from a how2 they found on the web. Often, when your system is compromised, it may continue to run as always while they just use it to hack other systems, so, if you can keep a eye on your cpu/bandwidth usage to see when something is not normal is a great help.
While doing 'loss prevention', I have been thinking about how to best defend our ASL servers going forward. Do to the nature of our international connections, I am thinking we just need to create and maintain a whitelist of IP's to the 'system IP Tables' as a whole, not asterisk only. It should be easy since the IP list is shared as it is, and we just need to add other outside services IP's to that.
But I'm still thinking on it. Perhaps this note will encourage others to think on it as well. These things always get worse, not better. I may write/experiment with this 'whitelist' idea this winter, but be aware, if you are not defending your system, you make it all the easier to hack others as well. Just because your system is running as intended does not mean it has not been compromised.
73, ...mike/kb8jnm _______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" 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.
On 9/4/18 12:38 PM, Bryan St Clair wrote:
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.
NAT is not security. Security is not solved by firewalls, or any one thing. Security is a mindset and an approach to looking at systems and protecting them from nefarious operators. AllStar on the default IAX port appears to be an open PBX, and would be quite useful for terminating VoIP calls, which can make attackers much money. By in large AllStar systems are not interconnected with outbound SIP trunks, and thus are a poor attack vector for this. fail2ban can be used not only for ssh, but IAX and SIP too.
https://lelutin.ca/posts/Blocking_bruteforce_attempts_on_Asterisk_with_fail2...
I find blackhole routing works best for these, and I'll set it to 3600 seconds. There is something to be said for using non-standard ports as this will cut down on the non-standard scanners. This only obscures the issue, it's not true security in and of it self. Add fail2ban with it and it will block much of it. If you're running a bunch of nodes on a single connection, setup a proxy, this will isolate them onto one device. A firewall helps you keep only what you want exposed. It's amazing how fast stuff can be exploited without a firewall on today's internet. I personally had a server I setup and got lazy as it was late at night, "I'll setup the firewall tomorrow". Tomorrow turned into 3 days and the server had memcached on it being used a packet generator. Turned my 10 mbit/s 95th usage into 998 mbit/s 95th percentile. Lesson learned, security is a mindset and starts day one. Perhaps the best thing you can do is not allow root access and use a good password. Using your callsign is not good, using A115tar isn't secure either. Each user should have their own password, and be enabled to use sudo too. 73's -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
I never stated NAT was security. I referenced what most run at a home configuration. Most current routers have a basic firewall that is denying all traffic except established traffic. Not the older generation of routers. As I said and you ended with, a secure password is the best defence the home user could do. This is the most common failure in security, even at the router level. In my 20+ years experience, networks rarely get exposed unless the user let's someone in via a open port or poor passwords. Or even default passwords. Of course, self inflicted infections are another beast. I have setup hundreds of networks, servers including Allstar servers and they have never had a intrusion. I have never used fail2ban in those cases. In company cases other devices are used, but I won't go into that as most are not in this situation for Allstar. They can't get in if your exposed point is not responsive to their connection attempts. Much more can be done in home networks as you increase exposure and history further. On Tue, Sep 4, 2018, 10:00 Bryan Fields <Bryan@bryanfields.net> wrote:
On 9/4/18 12:38 PM, Bryan St Clair wrote:
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.
NAT is not security.
Security is not solved by firewalls, or any one thing. Security is a mindset and an approach to looking at systems and protecting them from nefarious operators.
AllStar on the default IAX port appears to be an open PBX, and would be quite useful for terminating VoIP calls, which can make attackers much money. By in large AllStar systems are not interconnected with outbound SIP trunks, and thus are a poor attack vector for this.
fail2ban can be used not only for ssh, but IAX and SIP too.
https://lelutin.ca/posts/Blocking_bruteforce_attempts_on_Asterisk_with_fail2...
I find blackhole routing works best for these, and I'll set it to 3600 seconds.
There is something to be said for using non-standard ports as this will cut down on the non-standard scanners. This only obscures the issue, it's not true security in and of it self. Add fail2ban with it and it will block much of it.
If you're running a bunch of nodes on a single connection, setup a proxy, this will isolate them onto one device.
A firewall helps you keep only what you want exposed. It's amazing how fast stuff can be exploited without a firewall on today's internet. I personally had a server I setup and got lazy as it was late at night, "I'll setup the firewall tomorrow". Tomorrow turned into 3 days and the server had memcached on it being used a packet generator. Turned my 10 mbit/s 95th usage into 998 mbit/s 95th percentile.
Lesson learned, security is a mindset and starts day one.
Perhaps the best thing you can do is not allow root access and use a good password. Using your callsign is not good, using A115tar isn't secure either. Each user should have their own password, and be enabled to use sudo too.
73's -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net _______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" 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.
At the end of the day just because a device does not respond doesn’t mean an adversary can’t get into it. Even if it’s “secured” behind some type of NAT/Firewall or nat then very plainly the adversary first gets into that device via a variety of potential mechanisms (I cite the recent VPNFilter activity and subsequent script kiddy fallout using the same/similar techniques) Security is certainly a bit of a mindset, and even if you are “security minded” it doesn’t mean that you won’t get owned. Often adversaries are in infrastructure and either never noticed or noticed so late that the majority of the damage has been done (that’s generally how they are discovered after all). Certainly there are many things that you can do in terms of steps to help slow/stop the bad guys. Many of the statements made to date are decent... changing the ssh port will help, of course a basic portscanner will find this change, a complex non dictionary based password is great but an ssh keypair (google it) is even better! If you don’t need to accept incoming connections from external nodes (you only connect out to nodes) then block those incoming ports. Update update update, one of my biggest pet peeves is the fact that many of these systems go without updates. I published a how-to not so long ago that allows you to also update the kernel (security fixes, bug fixes, stability enhancements etc etc etc....). Security, like many things, boils down to a decision point about cost of money and time vs operational considerations. For example you can secure things reasonably well, as discussed here, for relatively low administrative overhead. Alternately you can add things like IDS/IPS and filesystem integrity tools that alert you when something changes, you can add central logging and regularly audit those logs and on and on and on :). So to summarize, a bullet list of minimal things: * Port change (only so effective) * Disallow remote root logon * Use a unique username (with sudo) * Setup and use SSH keys for authentication * Disable password based authentication entirely * Update all the things frequently (this means the ASL system as well as inline devices such as the router/firewall that the internet connection is actually on) * Turn off anything that isn’t required * Firewall off all the things that don’t require inbound connections * Tools like fail2ban are great! More things that can be done... * Central logging of all the things (audited regularly) * Filesystem integrity tool usage (including AV) * IPS/IDS (again regularly audited) I’m tired of typing on this iThing keyboard but I think I get my point across. This is not a comprehensive list by any means, but it’s a good primer I feel. Sent from the iRoad
On Sep 4, 2018, at 11:56, Bryan St Clair <bryan@k6cbr.us> wrote:
I never stated NAT was security. I referenced what most run at a home configuration. Most current routers have a basic firewall that is denying all traffic except established traffic. Not the older generation of routers.
As I said and you ended with, a secure password is the best defence the home user could do. This is the most common failure in security, even at the router level. In my 20+ years experience, networks rarely get exposed unless the user let's someone in via a open port or poor passwords. Or even default passwords. Of course, self inflicted infections are another beast.
I have setup hundreds of networks, servers including Allstar servers and they have never had a intrusion. I have never used fail2ban in those cases. In company cases other devices are used, but I won't go into that as most are not in this situation for Allstar.
They can't get in if your exposed point is not responsive to their connection attempts.
Much more can be done in home networks as you increase exposure and history further.
On Tue, Sep 4, 2018, 10:00 Bryan Fields <Bryan@bryanfields.net> wrote: On 9/4/18 12:38 PM, Bryan St Clair wrote:
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.
NAT is not security.
Security is not solved by firewalls, or any one thing. Security is a mindset and an approach to looking at systems and protecting them from nefarious operators.
AllStar on the default IAX port appears to be an open PBX, and would be quite useful for terminating VoIP calls, which can make attackers much money. By in large AllStar systems are not interconnected with outbound SIP trunks, and thus are a poor attack vector for this.
fail2ban can be used not only for ssh, but IAX and SIP too.
https://lelutin.ca/posts/Blocking_bruteforce_attempts_on_Asterisk_with_fail2...
I find blackhole routing works best for these, and I'll set it to 3600 seconds.
There is something to be said for using non-standard ports as this will cut down on the non-standard scanners. This only obscures the issue, it's not true security in and of it self. Add fail2ban with it and it will block much of it.
If you're running a bunch of nodes on a single connection, setup a proxy, this will isolate them onto one device.
A firewall helps you keep only what you want exposed. It's amazing how fast stuff can be exploited without a firewall on today's internet. I personally had a server I setup and got lazy as it was late at night, "I'll setup the firewall tomorrow". Tomorrow turned into 3 days and the server had memcached on it being used a packet generator. Turned my 10 mbit/s 95th usage into 998 mbit/s 95th percentile.
Lesson learned, security is a mindset and starts day one.
Perhaps the best thing you can do is not allow root access and use a good password. Using your callsign is not good, using A115tar isn't secure either. Each user should have their own password, and be enabled to use sudo too.
73's -- Bryan Fields
727-409-1194 - Voice http://bryanfields.net _______________________________________________ App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" 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.
App_rpt-users mailing list App_rpt-users@lists.allstarlink.org http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" 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.
participants (4)
-
Bryan Fields -
Bryan St Clair -
JJC -
Mike