I completely agree with Gage. The way I see it, security through
obscurity is perfectly valid as long as the control remains
obscured. I think the "anyone can just scan your ports" is
somewhat specious in that most (if not something like 99% or so
(unqualified opinion of course)) traffic is simply noise and scans
for standard ports. This is particularly true when it matters
most: during a worm outbreak or a newly published vulnerability.
Attackers simply don't have the time nor the inclination to go
through and perform slow and loud scans when they can quickly move
on to the next target. If 90% of the targets have services on the
default ports, then it makes far more sense to just go after the
easily targets.
Perfect case-in-point is the recent RDP unpleasantness. Non-
standard port deployments were automatically removed from the
target scans for 3389. I don't see how any can argue against the
security value of such a configuration.
t
Timothy "Thor" Mullen
www.hammerofgod.com
Thor's Microsoft Security Bible
-----Original Message-----
From: full-disclosure-bounces () lists grok org uk [mailto:full-
disclosure-bounces () lists grok org uk] On Behalf Of Gage Bystrom
Sent: Thursday, June 21, 2012 9:25 AM
To: full-disclosure () lists grok org uk
Subject: Re: [Full-disclosure] server security
Well thats a bit of an iffy one. I'd say it IS a security measure,
albeit one that is solely effective if and only if compounded with
other measures.
It's unlikely, but you never know, you just might miss out on a
nasty worm all because you werent running on a default port one
day.
On Thu, Jun 21, 2012 at 8:52 AM, Rob <synja () synfulvisions com>
wrote:
We need to make a distinction between security and obscurity
here. The only time changing ports actually hardens a service in
any way is when the port requires elevated rights to bind,
changing to 1025 for example removes the root requirement. Any
actual or theoretical vulnerabilities still exist. If somebody is
looking at your server, they'll find the port without much
trouble. Alternate ports can remove junk traffic from logs, so
there is a benefit, if not entirely a security one.
Rob
Sent on the Sprint® Now Network from my BlackBerry®
-----Original Message-----
From: Alex Dolan <dolan.alex () gmail com>
Sender: listbounce () securityfocus com
Date: Thu, 21 Jun 2012 07:44:57
To: Littlefield, Tyler<tyler () tysdomain com>
Cc: <security-basics () securityfocus com>
Subject: Re: server security
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 () tysdomain com> 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;e13b6
be
442f727d1
----------------------------------------------------------------
-----
---
-----------------------------------------------------------------
-----
-- 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;e13b6
be4
42f727d1
-----------------------------------------------------------------
-----
--
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
