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;
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.
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;e13b6be442
f727d1
------------------------------------------------------------------------
[ reply ]