Security Basics mailing list archives
RE: server security
From: krymson () gmail com
Date: Thu, 28 Jun 2012 15:32:03 GMT
Just want to add that I agree with Dave's reasoning. If I have a fully patched SSH server on port 22 it will get 500 scans a day. If I have a fully patched SSH server on port 25022 it will get 1 scan a day. This changes my risk. If an SSH vuln is discovered, I won't likely be one of the first few popped because my port is strange. Does this make my SSH less vulnerable to an issue? No. But it affects the likelihood of me being successfully attacked. Does it ensure my SSH server won't be hacked? No, but it does change my likelihood in the real world. I agree with those that define security another way, but I don't agree when you dismiss/disregard someone else's value statement. <- snip -> I respectfully disagree with the obscurity does not work and changing the port will not afford any protection comments. Once upon a time in kingdom far far away lived a little worm named Slammer that infected around 75K SQL systems in less than 30 minutes, which in turn caused router to fail under the barrage of packets flying accorss the Internet, but it only servers using port 1434, the default port. I know I have seen a plethora of 3389 automated scans and upon successful connection, attempted password attacks, what would happen if I changed to some other port? Sometimes security through obscurity does work. I am certainly not suggesting it would protect you from an Advanced Persistent Threat, but every little layer of security affords a little protection, deterrence, or delay. Respectfully, Dave Kleiman - http://www.ComputerForensicsLLC.com - http://www.DaveKleiman.com 4371 Northlake Blvd #314 Palm Beach Gardens, FL 33410 561.310.8801 -----Original Message----- From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Ward, Jon Sent: Friday, June 22, 2012 16:09 To: Ron McKown; Rory Browne; Mike Hale Cc: Alex Dolan; Littlefield, Tyler; security-basics (at) securityfocus (dot) com [email concealed] Subject: RE: server security There are only 65,535 ports. No matter what port it's on, anyone of average competence and a copy of nmap (or any other port scanner) will discover and identify your [insert daemon name here] service in seconds. -----Original Message----- From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Ron McKown Sent: Friday, June 22, 2012 1:10 PM To: Rory Browne; Mike Hale Cc: Alex Dolan; Littlefield, Tyler; security-basics (at) securityfocus (dot) com [email concealed] Subject: RE: server security Rory, I think you're absolutely correct. I think that some folks here are putting too much weight on looking at assessing risk and vulnerability from a technical control perspective and not on the overall scenario of people performing network sweeps looking for low hanging fruit.
From strictly a technical perspective of sshd running on a different port, there is no risk difference and the vulnerabilities are identical. From the perspective of folks wanting to hide their sshd port from untargeted network sweeps to avoid becoming a target for manual ones, then moving the sshd port can be very effective.
Two different scenarios, two different answers. Of course, publically hanging sshd on a public interface is never a good idea, but necessary sometimes I suppose. If necessary, disable password auth, don't permit root, and I realize that port knocking is kind of old school, but still works as an additional layer in the defense in depth principle. Ron McKown CISSP -----Original Message----- From: listbounce (at) securityfocus (dot) com [email concealed] [mailto:listbounce (at) securityfocus (dot) com [email concealed]] On Behalf Of Rory Browne Sent: Friday, June 22, 2012 4:03 AM To: Mike Hale Cc: Alex Dolan; Littlefield, Tyler; security-basics (at) securityfocus (dot) com [email concealed] Subject: Re: server security Everything I've ever read about security by obscurity, suggests that obscurity no security at all. While I would buy that it isn't a lot of security, I would have difficulty accepting that the only benefit of moving SSH to a different port is less cluttered log files. I would imagine less cluttered log files, mean less attacks, which would translate into less chance of a successful attacks. While I will accept that the people who say it's no defense at all, probably know a lot more about security than I do, I suspect moving SSH to a different port would render you less susceptible to attacks which scan which collect their list of IPs by scanning for open port 22.
From a defence in depth perspective, I would consider obscurity ( in this case port-moving ), to be quite a thin layer on the onion, but a layer none-the-less. Obscurity through camouflage has been successfully used by various armys ( with the exception of the red-coats ) for centuries, and I find it difficult to understand how it wouldn't apply to computer security.
What am I missing here? Rory On 21 June 2012 17:34, Mike Hale <eyeronic.design (at) gmail (dot) com [email concealed]> wrote:
"Putting it on some other port reduces your risk"
It doesn't really reduce your risk, since you're still as vulnerable
as you were before.
What it does is reduce your log entries. Â That can be worth the added
administrative cost of changing standard ports, but it's not really a
'security' measure.
On Wed, Jun 20, 2012 at 4:44 PM, Alex Dolan <dolan.alex (at) gmail (dot) com [email concealed]> wrote:
One tip I have is to set SSH to a port other than 22, I don't need to
tell anyone how devastating it is if someone did actually get access
to that service. Putting it on some other port reduces your risk
On Thu, Jun 21, 2012 at 1:27 AM, Littlefield, Tyler <tyler (at) tysdomain (dot) com [email concealed]> wrote:
Hello:
I have a couple questions. First, I'll explain what I did:
I set up iptables and removed all unwanted services. Iptables blocks
everything, then only opens what it wants. I also use the addrtype
module to limit broadcast and unspec addresses, etc. I also do some
malformed packet work where I just drop everything that looks
malformed (mainly by the flags).
2) I secured ssh: blocked root logins, set it up so only users in
the sshusers group can connect, and set it only to allow ppk.
3) I installed aid.
4) disabled malformed packets and forwarding/etc in sysctl.
This is a basic web server that runs email, web and a couple other things.
It's only running on a linode512, so I don't have the ability to set
up a ton of stuff; I also think that would make things more of a
mess. What else would be recommended?
Also, I'm looking to add something to the web server; sometimes I
notice that there are a lot of requests from people scanning for
common urls like wordpress/phpbb3/etc, what kind of preventative measures exist for this?
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool;
he that dares not reason is a slave.
--------------------------------------------------------------------
---- Securing Apache Web Server with thawte Digital Certificate In
this guide we examine the importance of Apache-SSL and who needs an
SSL certificate. Â We look at how SSL works, how it benefits your
company and how your customers can tell if a site is secure. You
will find out how to test, purchase, install and use a thawte
Digital Certificate on your Apache web server. Throughout, best
practices for set-up are highlighted to help you ensure efficient
ongoing management of your encryption keys and digital certificates.
http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6b
e442f727d1
--------------------------------------------------------------------
----
------------------------------------------------------------------------ Securing Apache Web Server with thawte Digital Certificate In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates. http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1 ------------------------------------------------------------------------
Current thread:
- Re: server security, (continued)
- Re: server security Tracy Reed (Jun 22)
- RE: server security Dave Kleiman (Jun 22)
- Re: server security Rob (Jun 22)
- Re: server security Ansgar Wiechers (Jun 25)
- RE: server security Dave Kleiman (Jun 22)
- RE: server security Tommy Thomas (Jun 26)
- Re: server security Tracy Reed (Jun 22)
- Re: server security Tracy Reed (Jun 21)
- RE: RE: server security Primrose,Jacqueline (HHSC) (Jun 28)