This discussion sounds like discussions 20 years go regarding PL on a repeater, it's too hard to solder in a pl board.

Even the basic security books on Unix long before Linux discuss root and security.  Root should never be exposed to the outside world, you also have to do as much to protect it from the inside as many exploits come from someone getting inside user credentials. 

basic security says..
1) don't expose anything you don't absolutely have to
2) keep your software up to date, especially the system.
3) anyone running a server should be trained.

Fail to ban...  "just means attack slowly"
exposing 22 "says please try me"
putting ssh on another port simply "says scan me", scripts do this all the time.
it goes on and on..

I personally use tunnels from my machine to my server, and tunnels are restricted not only by certificates, they are also restricted to IP address's they can come from.  Ports open to critical applications should be run at a minimum in a chroot environment. 
The basic asterisk installation needs more work than just spinning up the disk to get it securely installed.   It is not possible to logon to any one of my servers with a password. 

We even have developers who say if you are behind a fire wall at your house you should be secure..  pure poppycock..

So any system that intentionally exposes root, or you can't easily update the base system is "broken by design"  kinda like Windows stuff (not just my oppinion)

The internet is not a friendly place, it was 30 years ago, but has not been friendly for the last 25+ years ago.. anyone who just plugs in to the internet with an unprotected server is adding to the problem.  Bad server security is worse than the worst repeater curchunker cause the exploit is silent, you don't know it is happening unless YOU know what you are doing, watching logs etc..  you are keeping spammers in business...

Some think they are secure because the only thing their server runs is asterisk, till someone gets root, installs a mail server, and spams the world for years.. or they change ssh.conf and allow ssh out, (which is open by default and should be closed on installation)  so now they are using your server or small Raspberry Pi to attack the rest of the internet using your IP address..  it happens all the time guys..  In fact one of the biggest security exploits going today is getting someone to plug in a Pi from unknown origin into someone's internal network..  read "Penetration Testing with Raspberry Pi" by Muntz & Lakhani.  Bad buys are sending out Pi's by the hundreds to large companies, hoping someone will plug it into the local network to see what it is.. it's then game over for many small companies without knowledgeable sysadmins.

If you don't want to learn basic security, it's your machine, it's your problem, basic security is not hard to learn, but doesn't come from an installation disk any more than understanding ham radio comes from memorizing the test.  Don't ask developers to keep it easy for you just because you don't want learn basic security, if developers do it for you, they are bad developers, shame on them.


My .02 cents... with a constant internet connection since 1978..  Fred



On 10/5/15 10:36 PM, Stacy wrote:
Same difference. :)


On 10/05/2015 07:30 PM, Loren Tedford wrote:
Personally I use Fail2ban 


Loren Tedford (KC9ZHV) 
Email: lorentedford@gmail.com
Main Line:1-631-686-8878 Option 1 for Loren.
Fax Line 1:1-618-551-2755
Fax Line 2:1-631-686-8892 (New Fax line)
Cell: 618-553-0806

On Mon, Oct 5, 2015 at 9:06 PM, Stacy <kg7qin@arrl.net> wrote:
Certificates, two-factor authentication and something like ssh-guard set to block on the first three attempts with a really really long block threshold. 

Stacy
KG7QIN


On 10/05/2015 02:57 PM, Steven Donegan wrote:
Using certificates for ssh is yet another method :-)
 
Steven Donegan
KK6IVC General Class FCC License
Silver State Car #86
www.sscc.us

From: Bryan D. Boyle <bdboyle@bdboyle.com>
To: Steven Donegan <donegan@donegan.org>
Cc: Steve Zingman <szingman@msgstor.com>; "app_rpt-users@ohnosec.org" <app_rpt-users@ohnosec.org>
Sent: Monday, October 5, 2015 2:49 PM
Subject: Re: [App_rpt-users] New Official Allstar Distribution Released (DIAL)

Using a jump box as you describe is one way...not allowing SSH from the outside adds a layer; setting up a secue VDI capability to the jumpbox over a vpn is yet a third way...;). 

my rule: if it's exposed to the net, it's potentially vulnerable.  Just turn on your SIP port and pop some popcorn to see...;)

--
Bryan
Sent from my iPhone 5...No electrons were harmed in the sending of this message.





On Oct 5, 2015, at 17:39, Steven Donegan <donegan@donegan.org> wrote:

Direct root login being disallowed IF there were no other way to get full root privileges (not the case here) was considered best practice. However in almost every case there is a user (on Raspbian user pi) that can simply login, sudo -s and do whatever they want. Yes it puts up a small hurdle but I don't see it as a serious one.

In short, there is almost no setup that will allow you to completely lock out root with the exception of a few well designed appliances. And that means someone is out there doing support to get things resolved. This system is not of that flavor and root is necessary for many things so frankly adding a hurdle or two really doesn't appreciably make the system more secure.

Require a long pass phrase (say 20 mixed characters or so) and this whole thing is moot...

And BTW - putting sshd on port 222 (or anything except 22) is security by obscurity - many tools can find standard protocols on non-standard ports :-) (I know, I wrote one)

The best bet is to not allow ssh at all. If that is not feasible then do the su or sudo thing and/or set up an intermediate system such that you access a non-privileged account on system A, then ssh to system B and system B will ONLY accept ssh from system A. Still can be beaten but it is a bit harder...

And BTW - I have done infosec for about 20 years so I am allowed to have an opinion on this topic :-)
 
Steven Donegan
KK6IVC General Class FCC License
Silver State Car #86
www.sscc.us

From: Steve Zingman <szingman@msgstor.com>
To: "app_rpt-users@ohnosec.org" <app_rpt-users@ohnosec.org>
Sent: Monday, October 5, 2015 2:24 PM
Subject: [App_rpt-users] New Official Allstar Distribution Released (DIAL)
 

Dave,
Let's say I agree with you. And I well may.
On most internet exposed machines, I don't even allow ssh unless I trust your address or require a VPN. 
I agree is common practice to not allow it.
Now the question is why?

As John McLaughlin would say, DISCUSS!

On 10/05/2015 08:40 AM, Steve Zingman wrote:
> root login via SSH is now allowed

> This is a bad idea.  Root should *never* be allowed to login to a system 
> remotely.  It's better to log in as a normal user and then become root 
> via su, sudo, etc.

> - Dave




-- 
"Anything is possible if you don't know what you are talking about."
1st Law of Logic



_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.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@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.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@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.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@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.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.



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. 

_______________________________________________
App_rpt-users mailing list
App_rpt-users@ohnosec.org
http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users

To unsubscribe from this list please visit http://ohnosec.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. 

-- 
Fred Moore
email: fred@fmeco.com
       fred@safes.com
phone:  321-217-8699