| reply to Daniel
Re: Security and Obscurity: Changing Daemon Ports You're right Daniel. It is more secure, because it will be more work for the bots and their coders. I tend to look at my security at a relative level, relative to other users like me. When everyone moves their ports, by moving mine I will be no more secure than anyone else, but everyone would be a little more secure against bots with 0 day exploits. |
|
|
|
 DanielPremium,MVM
join:2000-06-26
San Francisco, CA | said by mikenolan7:You're right Daniel. It is more secure, because it will be more work for the bots and their coders. Exactly. It simply makes it harder to attack you, which is a very good thing for your security.
--
dmiessler.com -- grep understanding knowledge |
|
 jig
join:2001-01-05
Hacienda Heights, CA | reply to Daniel
don't forget, forcing an exploit to scan more ports is more secure in two ways.
1) - more work for the exploit, more time, more computer resources (which might be easier for an exploited user to notice and suspend).
2) - the more a particular computer scans out, the more likely it will be picked up by logs, by antiprobe, and by any other type of learning algorithm in between the exploiter and exploitee... most if not all legitimate internet traffic uses well defined port access and strategies. a blanket scan will be picked up by other anti-malware apps, not just the daemon authentication.
also, at some point (maybe above a certain number of users), when you change away from non-standard ports, the security comparison to make is not between standard port and non-standard port, but running the service at all and not running the service. putting it another way, the amount of disruption in getting it to function securely for 1000 users is closer to just turning off the service than having to rebuild the server if/when it gets owned, even taking collateral damage into consideration.
really, the idea here is that it's a wonderful way to keep your personal server up in a perfect internet storm, but it's not a way to run a professional server.
oh, and someone posted a graphic earlier that looked like the ssh server settings for some type of network device: be warned! routers and such are infamous for having very poor security implementations for non-standard service ports. if they work robustly at all, they can and do leave open other services unintentionally and break other specific security "optimizations" for the particular service.
--
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam. |
|
 BeesTeaNetwork JanitorPremium,VIP
join:2003-03-08
00000 | said by jig:also, at some point (maybe above a certain number of users), when you change away from non-standard ports, the security comparison to make is not between standard port and non-standard port, but running the service at all and not running the service. putting it another way, the amount of disruption in getting it to function securely for 1000 users is closer to just turning off the service than having to rebuild the server if/when it gets owned, even taking collateral damage into consideration. Exactly.
At some point you could consider the risk reduction of replacing ssh with something custom written. Solves the ssh zero-day risk, after all. But in the end that gets deemed unreasonable. As does changing ports for a service used by more than a handful of people in my opinion.
In the case of a professional deployment, servicing multiple people, intended to last, standards are something that need to be adhered to. Trying to guess what kind of ad-hoc tomfoolery is going on on a network would be a fiasco. Taking advantage of technologies that let you harden your services while still keeping them here they should be, not nearly as much.
--
Overpower, overcome. |
|
 javaManThe Dude abides.Premium,MVM
join:2002-07-15
San Luis Obispo, CA
4 edits | said by BeesTea:. . . In the case of a professional deployment, servicing multiple people, intended to last, standards are something that need to be adhered to. Trying to guess what kind of ad-hoc tomfoolery is going on on a network would be a fiasco. Taking advantage of technologies that let you harden your services while still keeping them here they should be, not nearly as much. And it is not an unreasonable question to ask what becomes of standards when the advocacy is to abandon them for the sake of what can also reasonably questioned as real security. As I said, I'm not opposed to the idea of limiting risk through obscurity, but should it ever be considered a standard industry practice, as I can only assume it is being advocated, what then are the larger ramifications?
--
Woe unto them that call evil good, and good evil; that put darkness for light, and light for darkness. . . Isa. 5:20 |
|
Damon85Premium
join:2004-12-25
Louisville, KY | reply to BeesTea
said by BeesTea:In the case of a professional deployment, servicing multiple people, intended to last, standards are something that need to be adhered to. Trying to guess what kind of ad-hoc tomfoolery is going on on a network would be a fiasco. Taking advantage of technologies that let you harden your services while still keeping them here they should be, not nearly as much. In the case of a professional deployment, your setup should be well-documented irrespective of how complex it is. Standards are for open, public networks -- not closed private ones.
I think the idea of a service running on a different port turning into a fiasco is a bit of an overstatement -- I'd think a hardened system is more likely to create fiasco situations with in-built connection throttling, access control and restrictions, etc. A changed port number is a one-time fix, assuming the port number doesn't change regularly (which maybe it should), and it'd be rather painless and straight-forward in comparison to both implement and document.
On the matter of determination, if someone is determined to get into your system, they'll try at it no matter how many defenses you put in place, so the argument that this does nothing to deter them is moot -- they are not to be deterred. This fends off passing scans and automated attacks, which affect everyone more or less equally. |
|
BeesTeaNetwork JanitorPremium,VIP
join:2003-03-08
00000 | reply to javaMan
said by javaMan:As I said, I'm not opposed to the idea of limiting risk through obscurity, but should it ever be considered a standard industry practice, as I can only assume it is being advocated, what then are the larger ramifications? I assume they would be huge. Imagine trying to maintain continuity between networks where services run on arbitrary ports. I think it would be a mess.
I'll take standards and other ways to secure my services. I suspect the guy who comes along after me will be thankful I did.
--
Overpower, overcome. |
|
javaManThe Dude abides.Premium,MVM
join:2002-07-15
San Luis Obispo, CA | reply to Damon85
said by Damon85:said by BeesTea:In the case of a professional deployment, servicing multiple people, intended to last, standards are something that need to be adhered to. Trying to guess what kind of ad-hoc tomfoolery is going on on a network would be a fiasco. Taking advantage of technologies that let you harden your services while still keeping them here they should be, not nearly as much. . . .Standards are for open, public networks -- not closed private ones. . . . . . I'm not sure that is what is being advocated though. If so, then I would completely agree and the use of non-standard ports is not an unreasonable precaution to take.
--
Woe unto them that call evil good, and good evil; that put darkness for light, and light for darkness. . . Isa. 5:20 |
|
BeesTeaNetwork JanitorPremium,VIP
join:2003-03-08
00000 | reply to Damon85
said by Damon85:In the case of a professional deployment, your setup should be well-documented irrespective of how complex it is. Standards are for open, public networks -- not closed private ones. Reread the thread. The word "public" is specifically used. Throughout the thread, and at least once in all caps by the OP.
--
Overpower, overcome. |
|
Damon85Premium
join:2004-12-25
Louisville, KY | My intent is what's considered publicly accessible for all (e.g. a public web site) and a privileged service intended for some that can be accessed from anywhere -- like SSH, technically public, but not with the same intent. In the case of a web site, the standard port 80 must be used. The distinction is that the clients are outside of your control. In a professional environment with SSH, it's likely that the clients are completely within your control from the aspect of having a port set.
Like I said in an earlier post, it's not black and white -- there's gray area between public and private. |
|
BeesTeaNetwork JanitorPremium,VIP
join:2003-03-08
00000 | said by Damon85:Like I said in an earlier post, it's not black and white -- there's gray area between public and private. Indeed. And like I said earlier. It's not deniable that this reduces the risk in some fashion (as do a lot of things, including turning off the service or replacing it with something else), however it's not something I'd do/recommend/or seen done with any scale.
--
Overpower, overcome. |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA
2 edits | reply to Daniel
So it sounds like the best push-back here is the difficulty of communicating and implementing the port change to a large user-base. I'm skeptical of this being a large enough problem to offset the security gain this offers in terms of zero-day exploit protection.
Do we really have a problem with large, unsophisticated user-bases that use SSH for shell access? Or, to put it another way, is it that difficult to replace these users' config files for their clients? We're talking about adding a -p $port to their CLI configs -- and many GUI clients can be auto-configured in this way as well.
I'm not saying this isn't a problem; I'm saying I need to be convinced it is. I just don't see it. To me it's a tradeoff between security gained vs. administrative hassle/user annoyance. And if we're avoiding zero-day attacks in dramatic fashion it's going to have to be some pretty damn serious weight on the other side to counter it.
Show me why you guys think it's going to be so difficult to update clients. And more importantly, show me that that level of difficulty isn't worth it given what we agree we're gaining.
--
dmiessler.com -- grep understanding knowledge |
|
BeesTeaNetwork JanitorPremium,VIP
join:2003-03-08
00000 | said by Daniel:Do we really have a problem with large, unsophisticated user-bases that use SSH for shell access? Who's "We" ? You're asking for details on a hypothetical situation so that you can be convinced? That's a huge stretch.
What's your actual goal if it's not to solicit opinions? Are you trying to convince someone that it's a good idea?? If so, it's been said probably 20 times in the thread that on a metrics-based security model, you've lowered your risk.
If not, then for the sake (i guess) of furthering the argument, sure, I guess I can play.
We have droves of users who have no idea what they're doing. User-base of 2 million who need shell access across 5 continents and they're all using different operating systems, and versions of ssh client software. All with their own ISPs and we've got no VPN.
Your turn.
--
Overpower, overcome. |
|
 yockTFTCPremium
join:2000-11-21
Miamisburg, OH
kudos:3 | reply to Daniel
I think the pushback is due to the level of effort required to make such a change effective relative to the potential for difficulty. Is it enough to change the port once and let it go forever? If not, are you really going to push ssh config files or PuTTY profiles to someone's home PC just so you can periodically change the ssh port?
We should also compare this against the relative vulnerability of OpenSSH. Here are all of Secunia's "Highly Critical" advisories for OpenSSH 3.x and 4.x since 2003:
»secunia.com/advisories/22173/
»secunia.com/advisories/9825/
»secunia.com/advisories/9743/
There are three, all of which are patched, none of which are directly vulnerable to privilege escalation.
SecurityFocus doesn't have as robust a search engine, but they list a total of 27 vulnerabilities since 2001.
I think you'll agree with me that these numbers are extraordinarily low, and though that's no reason to be lax in our policies it does indicate that there are often better ways to focus our energy when securing our systems.
I guess what I'm saying is, find me past zero-day OpenSSH vulns that this would have helped defend against. |
|
DanielPremium,MVM
join:2000-06-26
San Francisco, CA | said by yock:I guess what I'm saying is, find me past zero-day OpenSSH vulns that this would have helped defend against. Sure, that's a good argument. I just think the amount of effort vs. the benefit is in the benefit's favor -- in most cases I can visualize. Not all -- I totally accept that. Hell, in cases where you have to use password auth (yuck) it's even worth it just to lower the log noise.
--
dmiessler.com -- grep understanding knowledge |
|
 SnowymIRC unix.ro UnderNetPremium
join:2003-04-05
Kailua, HI
kudos:5
 ·RoadRunner Cable
 ·Clearwire Wireless
| reply to BeesTea
said by BeesTea:said by javaMan:As I said, I'm not opposed to the idea of limiting risk through obscurity, but should it ever be considered a standard industry practice, as I can only assume it is being advocated, what then are the larger ramifications? I assume they would be huge. Imagine trying to maintain continuity between networks where services run on arbitrary ports. I think it would be a mess. I'll take standards and other ways to secure my services. I suspect the guy who comes along after me will be thankful I did. Not being a network admin myself, you guys have brought up some issues that I wouldn't have considered.
Being an outsider this is my take so far on the default port issue.
The real value depends on the network size. The maximum value will realized by the smallest network & on a sliding scale this value will decrease as the network size grows until it reaches a point where port changing becomes more of a liability than a benefit. That makes sense to me, but why is that so?
My own outsiders view of this that it's not so much the size of the network that matters as does the amount of resources a company is willing to put into it's network administration. That sliding scale of benefits really reflects whether a network can be reasonably administered with the resources allotted to it.
e.g., a network with 1000 machines could realize a benefit from port changing while another network of 100 machines wouldn't. The only difference being the amount of resources (think $) each company is willing to pay for it's network administration. I'm sure at some point the fixed cost of administering a network of non default ports will be greater than the cost of rebuilding but that's about cost benefits, not security benefits.
Here's where I'll repeat that I have no practical experience administrating a network |
|
