RE: NAT external/Public IP

["Craig Wright" <Craig.Wright () bdo com au>]

"The server will become more secure by being disconnected. This is not obscurity."

Of course it won't. CIA - The A being ABAILABILITY.

 I am sorry, but the argument - I will DoS myself first - so I am secure is futile and ridiculous.

 For example.

1.            Back in the 80's I had a professor who thought this way. Let's say professor C. from QLD Aust to protect 
the guilty. He would remove the disks from the servers he managed each night and store them in his locked cabinet. 

I was doing a class at the time while also working for the RAAF (air-force). Like many externally based students I was 
not always at the computer lab in tutorial times. The University had remote access (internet in effect - but not called 
that then). 

Professor C would install the disks in the server again in the morning. He thought that this was more secure as well 
and there was a write-up in one of the computer rags at the time. You may guess that some people had problems working 
on their assignments/projects. I know as I was one of them. 

So a limited availability affected the ability of the system to deliver its required services - it was in effect less 
secure.

(And it also happened that one of the internal students broke into the system when it was online anyway).

2.            An Australian Federal Govt. Department. Back about the turn of the millennium, a company I ran had a 
contract with DFAT. From time to time we received information about pending events. On one such occasion, we received 
intelligence that one of the Commonwealth Dept. websites was going to be attacked. The attack was to be a DDoS against 
the web site in order to stop people from using the eCommerce system prior to Christmas and just after and cause 
embarrassment to the government.

The answer the site admin made was that the department shut down the internet connection for 2 weeks. This was internal 
and external access.  I would call this a successful DoS and no packet was ever sent!

To conclude.

Availability is one of the fundamentals of securing a system. Talk of a secure system in the ocean flaw, locked away 
etc is missing the point - it needs to be available to be secure.

Regards,

Dr Craig Wright (GSE-Compliance)




Craig Wright
Manager of Information Systems

Direct : +61 2 9286 5497
Craig.Wright () bdo com au
+61 417 683 914

BDO Kendalls (NSW)
Level 19, 2 Market Street Sydney NSW 2000
GPO BOX 2551 Sydney NSW 2001
Fax +61 2 9993 9497
www.bdo.com.au

Liability limited by a scheme approved under Professional Standards Legislation in respect of matters arising within 
those States and Territories of Australia where such legislation exists.

The information in this email and any attachments is confidential.  If you are not the named addressee you must not 
read, print, copy, distribute, or use in any way this transmission or any information it contains.  If you have 
received this message in error, please notify the sender by return email, destroy all copies and delete it from your 
system. 

Any views expressed in this message are those of the individual sender and not necessarily endorsed by BDO Kendalls.  
You may not rely on this message as advice unless subsequently confirmed by fax or letter signed by a Partner or 
Director of BDO Kendalls.  It is your responsibility to scan this communication and any files attached for computer 
viruses and other defects.  BDO Kendalls does not accept liability for any loss or damage however caused which may 
result from this communication or any files attached.  A full version of the BDO Kendalls disclaimer, and our Privacy 
statement, can be found on the BDO Kendalls website at http://www.bdo.com.au or by emailing administrator () bdo com au.

BDO Kendalls is a national association of separate partnerships and entities.

________________________________


From: listbounce () securityfocus com on behalf of Nick Vaernhoej
Sent: Sat 10/11/2007 6:29 AM
To: security-basics () securityfocus com
Subject: RE: NAT external/Public IP



# 1) I dislike discussions on the value of obscurity, because the
typical two parties in the discussion are often both correct.

Depends on your personal definition of "obscurity". :)


# 2) Correct: obscurity does not affect the security of a device itself.
# An unpatched Windows OS won't become more secure, in and of itself,
because you hid it in a closet with no network. The OS is still
insecure.

The server will become more secure by being disconnected. This is not
obscurity.
Obscuring the server would be to hide it in a closet of the most common
color, then painting the closet a different color.
The server is exactly as secure, but people looking for a regular
colored closet might not find it.


# 3) Correct, the risk to a device is affected in a positive way by
obscuring it.
# The risk to that Windows system is pretty low because it doesn't even
have a network cable attached to it!

Exposure to risk is affected by obscuring it. Not risk itself.
The risk of being compromised will depend on your password length or
similar.


# 4) This can also be illustrated with our age-old example of putting
SSH on an alternate port.
# This won't make the SSH daemon or user passwords any more secure, but
you will see a dramatic reduction in the number of logged brute force
attempts when it is on an odd port.
# This is of value to many security professionals, and should be labeled
a "reduction of risk."
# Sadly, many people still just call this an "increase in security"
which gets quickly mistaken.

The way I see it.
If you choose a 63 character complex password you can leave the port
number alone. However by changing it you will have fewer lines of
logfile to review. The risk of actual compromise did not get affected.
But the exposure to risk stays maxed if the port is standard.


Nick

This electronic transmission is intended for the addressee (s) named above. It contains information that is privileged, 
confidential, or otherwise protected from use and disclosure. If you are not the intended recipient you are hereby 
notified that any review, disclosure, copy, or dissemination of this transmission or the taking of any action in 
reliance on its contents, or other use is strictly prohibited. If you have received this transmission in error, please 
notify the sender that this message was received in error and then delete this message.
Thank you.