[App_rpt-users] Server Security

Thu Sep 6 13:56:22 UTC 2018

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 at 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 at 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_fail2ban/
>> 
>> 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 at 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 at 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20180906/be4a3347/attachment.html>