Planning to grow....static IP/VPN..etc etc

Planning to grow....static IP/VPN..etc etc

Post by Susan Bradley, CPA/CITP - aka E-bit » Tue, 30 Jan 2001 16:51:10



Currently have a dynamic IP package from Pacbell combined with the
Linksys router for PPPoE.  Works for now but obviously can't do a lot of
the fun stuff without [I feel] sacrificing security [we are an
accounting firm with tax data, social security numbers....etc...].
Planning to purchase SBS2K and install after April 15.  Want to plan for
future expansion into VPN, OWA and the rest.  Obviously will need to
upgrade to static IP.  Question:  what's the best firewall/router for
providing security for a small office?

Susan B.

 
 
 

Planning to grow....static IP/VPN..etc etc

Post by Larry Struckmeye » Tue, 30 Jan 2001 21:34:02


Hi Susan:

Does this appliance have to fit into your aforementioned
$20,000 budget, and what do you have left? :)

Larry Struckmeyer


Quote:

> Currently have a dynamic IP package from Pacbell combined with the
> Linksys router for PPPoE.  Works for now but obviously can't do a lot of
> the fun stuff without [I feel] sacrificing security [we are an
> accounting firm with tax data, social security numbers....etc...].
> Planning to purchase SBS2K and install after April 15.  Want to plan for
> future expansion into VPN, OWA and the rest.  Obviously will need to
> upgrade to static IP.  Question:  what's the best firewall/router for
> providing security for a small office?

> Susan B.


 
 
 

Planning to grow....static IP/VPN..etc etc

Post by Jeff Middleton [SBS-MVP » Wed, 31 Jan 2001 00:00:40


IMHO, you need to finalize your plan for what you want to do in order to
decide how to do it.

The perfect security mechanism is like a room without doors. It's rather
difficult to take anything out in that situation. Therefore, the firewall
theory has as much to do with what you plan to allow as openings and
activities as it does the "sturdy design" and such. In addition, if you have
a dynamic situation, you will be more interested in an easily configurable
firewall, or else having a configuration that doesn't require adjustment to
the firewall to allow for the changes.

Take the VPN issue, for instance. The strongest security for a VPN is a
fixed IP on both ends, strong passwords, and IPsec tunnel.  If you have a
pair of sites to interconnect, this is the way to go. The static IP on both
ends means that the VPN server (on each end if you like) can be configured
to allow a VPN connection only from a specific IP. This adds a very
difficult to break item in the security list.  A VPN that allows only a
password is clearly by contrast not as secure. If you allow a VPN, what can
be done from that point.....is going to be the next question. Suppose
someone establishes an unauthorized VPN to your server....what can the now
do from there?

Likewise, if you allow for OWA access, what information would you allow from
there? Part of the problem in making your LAN extensible into the web is to
review not only how your intended uses should work, but how the unintended
uses COULD work against you.  We all know how common it is for people to
choose pathetically poor passwords. Are you going to allow a user to have
their birthday as a password to a VPN that terminates on the PDC with any
originating location they like?  This introduces the idea of isolating the
resources of the LAN to provide layers of security that are not so much
about making a single item harder to break, but rather to require the
failure of two or more security concepts to occur before you have a really
significant exposure.

Firewalls are designed to start by reducing the number of things possible to
a manageable list of what you want to allow.  POP3, SMTP, FTP and VPN. Okay,
fine that's what I intend to allow.  Now, if the most external device is
going to allow a VPN, do I want that VPN tunnel to have the "portal" inside
the LAN, or outside the LAN itself.  If you can't secure the far end of the
VPN tunnel originating the connection, you likely want to not bring the VPN
directly into the nursery without another security layer. In other words,
VPN is designed to protect the security of data passing through the public
corridor of the web, but nobody said the users necessarily shouldn't be
check out for identity in an exterior "lobby"...inside the building, but not
yet inside the trusted area of the LAN. This implies that you establish an
area of control outside your LAN, but not in the web public space either.
You could use your web router to terminate the VPN at the doorstep of your
network, but not inside the LAN itself:

(web)-----(VPN Host/Firewall/NAT router)------your
doorstep---(Proxy/SBS)-----LAN

The idea above is that the VPN comes not to the SBS, but terminates at the
firewall. From that point, the user must now pass through a different
security checkpoint at the Proxy Firewall, perhaps even with a different
password scheme than is used for establishing the VPN tunnel.

Also, if you plan to VPN from other locations, you need to decide what the
point of that VPN is to be. If it's just to check email, then OWA is a fine
answer, and this assumes that you will have the Exchange available to make
connections from outside the LAN via the web. If you plan to work offsite,
you may well need to have a Terminal Server to make this VPN based work
effective. That probably implies more than one server.

If you plan to have your Exchange on the SBS (obviously), you will likely
find very few pure Exchange gurus who would recommend allowing a lot of
complicated access from the web to the Exchange server as both a PDC and
fileserver...this is just not normally a great practice from security
standpoint if you have a "heightened" security concern, such as you express
with your client financial information. Therefore, you would normally be
discouraged by such gurus from placing these jewels on a system directly
connected to the web.

The implication of security with web connected systems is that you get the
best security from isolating the valuables from the web connected systems,
placing the valuable inside a protected interior system, and use the web
connection to reach gateway servers that can be accessed by the web, but
that are not actually storing sensitive data on them. What I'm describing is
typical of a larger scale operation than what an SBS normally represents,
because it implies a multiserver approach. I've created a diagram a bit
lower down that illustrates this point.

I point this out because when you start to talk about security beyond the
basics, you start to get answers that imply basic design principals that SBS
itself violates. This has as much as anything to do with a diminishing
returns on low-probability risk factors and precautions.  You would find
that you end up spending more and more to gain very little incremental
security gain. Yet, your security challenges are multiplied if you don't
have but a simple [web--firewall--crown jewels] design.

You have to realize that security in this context means everything from a
blunt force Denial of Service attach the blocks access to and from the web,
possibly halts the device being attacked....and extends into a ferret attack
where someone actually uses your own tools for OWA or Terminal Services as
their vehicle into the LAN and a plan of theft.  You have to recognize that
anything you leave as an option to your users are your most severe risks. A
user controlled password is as good as leaving a key under the mat, or at
least you should assume this. If this is all it takes to leave the doors
open to the vault, consider the vault unlocked.

The most likely computer to be hacked is the one directly on the web, not in
the LAN. Therefore an approach that uses a standalone hardware firewall
either on a web connected router or similar devices is the first step. From
this router, in addition to running a firewall, you would want to run NAT.
This creates the first security zone that is not directly accessible from
the web. From the NAT isolated subnet, you create a server or server group
with external connections that provide a dual-homed design, similar to the
logic of the SBS web connection with Proxy. This ensures that there is not a
direct route into the LAN.  Assuming then that these servers run only Proxy,
IIS, or Exchange, but do not have locally attached valuable data on their
drives.  In this manner, even if someone where to hack into this point, the
have no data to access.  Using Proxy, IIS, and Exchange, you are able to
limit the types of activities that can be attempted on these external
interfaces.

IIS and Proxy both allow for extending connectivity from the web into the
LAN. Reverse Proxy, as well as building a Terminal Services interface into
an IIS page would allow for "outside" users to be authenticated and then
granted access into resources inside the LAN.  You would normally have the
PDC and the data inside and beyond this perimeter. The PDC is a valuable
resource for a hacker because it has some extremely useful account
information. In addition, someone who wishes to make you miserable can
simply launch a Denial of Service attack that prevents your web connected
devices and servers from functioning correctly, barring a firewall designed
to halt that attach at the web connected router.

The result of this arrangement would look a bit like this:

       (web)                                        Public IPs
           |
[public IP interface]
[NAT IP interface]
           |                                              NAT IPs in public
side
           |
   ----------------------------
   |                                        |
IIS/Proxy Server       Exchange Server
   |                                        |
   ----------------------------                Your private LAN
                     /    |   \
                    /     |     \
              PDC    |       File Server
                          |
                    Your LAN clients

There are many variants on this to pursue. You could use put the Exchange
Server on the PDC as well as the File Service and use reverse Proxy to bring
the Exchange connections in, and you would be down to a two server
arrangement. You could conceivably run Terminal Services on the IIS/Proxy
Server, but I doubt any security expert would allow that!  You could put a
Terminal Server inside the LAN, and use reverse Proxy to bring those
sessions to the TS.  This last idea would result in this:

       (web)                                        Public IPs
           |
[public IP interface]
[NAT IP interface]
           |                                              NAT IPs in public
side
           |
           |
IIS/Proxy Server
           |
           --------------                Your private LAN
                     /    |   \
                    /     |     \
    Terminal Svr   |       PDC/File Server/Exchange
                          |
                    Your LAN clients

About the only difference between this previous diagram and an SBS LAN is
that defacto you have all this stuff on one box, therefore the NAT
router/firewall is your stiffest defense, followed by the Proxy/ISA
firewall.

Assuming that you plan to use SBS 2K for this plan, you have much improved
tools in ISA to master, as well as neat tools for VPN and RRAS. If you need
a Terminal Server in your solution, you will either need to decide if you
want the TS and the SBS both double-homed on the LAN and the NAT subnet of
the web connection:

       (web)                      
...

read more »

 
 
 

Planning to grow....static IP/VPN..etc etc

Post by Dan La » Wed, 31 Jan 2001 01:08:53


You may want to invest in a security certificate for your SBS which is
relatively cheap from www.thawte.com.  This would add 128 bit encryption to
your OWA, however, as Jeff mentioned, it still doesn't protect against
simple passwords.



Quote:> Currently have a dynamic IP package from Pacbell combined with the
> Linksys router for PPPoE.  Works for now but obviously can't do a lot of
> the fun stuff without [I feel] sacrificing security [we are an
> accounting firm with tax data, social security numbers....etc...].
> Planning to purchase SBS2K and install after April 15.  Want to plan for
> future expansion into VPN, OWA and the rest.  Obviously will need to
> upgrade to static IP.  Question:  what's the best firewall/router for
> providing security for a small office?

> Susan B.

 
 
 

Planning to grow....static IP/VPN..etc etc

Post by Susan Bradley, CPA/CITP aka E-BIT » Wed, 31 Jan 2001 00:00:44


Wow! Thanks for the advice and thoughts.....got a paypal account so I can send
you your fee?  :<)
Susan B.
"Jeff Middleton [SBS-MVP]" wrote:
> IMHO, you need to finalize your plan for what you want to do in order to
> decide how to do it.

> The perfect security mechanism is like a room without doors. It's rather
> difficult to take anything out in that situation. Therefore, the firewall
> theory has as much to do with what you plan to allow as openings and
> activities as it does the "sturdy design" and such. In addition, if you have
> a dynamic situation, you will be more interested in an easily configurable
> firewall, or else having a configuration that doesn't require adjustment to
> the firewall to allow for the changes.

> Take the VPN issue, for instance. The strongest security for a VPN is a
> fixed IP on both ends, strong passwords, and IPsec tunnel.  If you have a
> pair of sites to interconnect, this is the way to go. The static IP on both
> ends means that the VPN server (on each end if you like) can be configured
> to allow a VPN connection only from a specific IP. This adds a very
> difficult to break item in the security list.  A VPN that allows only a
> password is clearly by contrast not as secure. If you allow a VPN, what can
> be done from that point.....is going to be the next question. Suppose
> someone establishes an unauthorized VPN to your server....what can the now
> do from there?

> Likewise, if you allow for OWA access, what information would you allow from
> there? Part of the problem in making your LAN extensible into the web is to
> review not only how your intended uses should work, but how the unintended
> uses COULD work against you.  We all know how common it is for people to
> choose pathetically poor passwords. Are you going to allow a user to have
> their birthday as a password to a VPN that terminates on the PDC with any
> originating location they like?  This introduces the idea of isolating the
> resources of the LAN to provide layers of security that are not so much
> about making a single item harder to break, but rather to require the
> failure of two or more security concepts to occur before you have a really
> significant exposure.

> Firewalls are designed to start by reducing the number of things possible to
> a manageable list of what you want to allow.  POP3, SMTP, FTP and VPN. Okay,
> fine that's what I intend to allow.  Now, if the most external device is
> going to allow a VPN, do I want that VPN tunnel to have the "portal" inside
> the LAN, or outside the LAN itself.  If you can't secure the far end of the
> VPN tunnel originating the connection, you likely want to not bring the VPN
> directly into the nursery without another security layer. In other words,
> VPN is designed to protect the security of data passing through the public
> corridor of the web, but nobody said the users necessarily shouldn't be
> check out for identity in an exterior "lobby"...inside the building, but not
> yet inside the trusted area of the LAN. This implies that you establish an
> area of control outside your LAN, but not in the web public space either.
> You could use your web router to terminate the VPN at the doorstep of your
> network, but not inside the LAN itself:

> (web)-----(VPN Host/Firewall/NAT router)------your
> doorstep---(Proxy/SBS)-----LAN

> The idea above is that the VPN comes not to the SBS, but terminates at the
> firewall. From that point, the user must now pass through a different
> security checkpoint at the Proxy Firewall, perhaps even with a different
> password scheme than is used for establishing the VPN tunnel.

> Also, if you plan to VPN from other locations, you need to decide what the
> point of that VPN is to be. If it's just to check email, then OWA is a fine
> answer, and this assumes that you will have the Exchange available to make
> connections from outside the LAN via the web. If you plan to work offsite,
> you may well need to have a Terminal Server to make this VPN based work
> effective. That probably implies more than one server.

> If you plan to have your Exchange on the SBS (obviously), you will likely
> find very few pure Exchange gurus who would recommend allowing a lot of
> complicated access from the web to the Exchange server as both a PDC and
> fileserver...this is just not normally a great practice from security
> standpoint if you have a "heightened" security concern, such as you express
> with your client financial information. Therefore, you would normally be
> discouraged by such gurus from placing these jewels on a system directly
> connected to the web.

> The implication of security with web connected systems is that you get the
> best security from isolating the valuables from the web connected systems,
> placing the valuable inside a protected interior system, and use the web
> connection to reach gateway servers that can be accessed by the web, but
> that are not actually storing sensitive data on them. What I'm describing is
> typical of a larger scale operation than what an SBS normally represents,
> because it implies a multiserver approach. I've created a diagram a bit
> lower down that illustrates this point.

> I point this out because when you start to talk about security beyond the
> basics, you start to get answers that imply basic design principals that SBS
> itself violates. This has as much as anything to do with a diminishing
> returns on low-probability risk factors and precautions.  You would find
> that you end up spending more and more to gain very little incremental
> security gain. Yet, your security challenges are multiplied if you don't
> have but a simple [web--firewall--crown jewels] design.

> You have to realize that security in this context means everything from a
> blunt force Denial of Service attach the blocks access to and from the web,
> possibly halts the device being attacked....and extends into a ferret attack
> where someone actually uses your own tools for OWA or Terminal Services as
> their vehicle into the LAN and a plan of theft.  You have to recognize that
> anything you leave as an option to your users are your most severe risks. A
> user controlled password is as good as leaving a key under the mat, or at
> least you should assume this. If this is all it takes to leave the doors
> open to the vault, consider the vault unlocked.

> The most likely computer to be hacked is the one directly on the web, not in
> the LAN. Therefore an approach that uses a standalone hardware firewall
> either on a web connected router or similar devices is the first step. From
> this router, in addition to running a firewall, you would want to run NAT.
> This creates the first security zone that is not directly accessible from
> the web. From the NAT isolated subnet, you create a server or server group
> with external connections that provide a dual-homed design, similar to the
> logic of the SBS web connection with Proxy. This ensures that there is not a
> direct route into the LAN.  Assuming then that these servers run only Proxy,
> IIS, or Exchange, but do not have locally attached valuable data on their
> drives.  In this manner, even if someone where to hack into this point, the
> have no data to access.  Using Proxy, IIS, and Exchange, you are able to
> limit the types of activities that can be attempted on these external
> interfaces.

> IIS and Proxy both allow for extending connectivity from the web into the
> LAN. Reverse Proxy, as well as building a Terminal Services interface into
> an IIS page would allow for "outside" users to be authenticated and then
> granted access into resources inside the LAN.  You would normally have the
> PDC and the data inside and beyond this perimeter. The PDC is a valuable
> resource for a hacker because it has some extremely useful account
> information. In addition, someone who wishes to make you miserable can
> simply launch a Denial of Service attack that prevents your web connected
> devices and servers from functioning correctly, barring a firewall designed
> to halt that attach at the web connected router.

> The result of this arrangement would look a bit like this:

>        (web)                                        Public IPs
>            |
> [public IP interface]
> [NAT IP interface]
>            |                                              NAT IPs in public
> side
>            |
>    ----------------------------
>    |                                        |
> IIS/Proxy Server       Exchange Server
>    |                                        |
>    ----------------------------                Your private LAN
>                      /    |   \
>                     /     |     \
>               PDC    |       File Server
>                           |
>                     Your LAN clients

> There are many variants on this to pursue. You could use put the Exchange
> Server on the PDC as well as the File Service and use reverse Proxy to bring
> the Exchange connections in, and you would be down to a two server
> arrangement. You could conceivably run Terminal Services on the IIS/Proxy
> Server, but I doubt any security expert would allow that!  You could put a
> Terminal Server inside the LAN, and use reverse Proxy to bring those
> sessions to the TS.  This last idea would result in this:

>        (web)                                        Public IPs
>            |
> [public IP interface]
> [NAT IP interface]
>            |                                              NAT IPs in public
> side
>            |
>            |
> IIS/Proxy Server
>            |
>            --------------                Your private LAN
>                      /    |   \
>                     /     |     \
>     Terminal Svr   |       PDC/File Server/Exchange
>                           |
>                     Your LAN clients

> About the only difference between this previous diagram and an SBS LAN is
> that defacto you have all this

...

read more »

 
 
 

Planning to grow....static IP/VPN..etc etc

Post by Jeff Middleton [SBS-MVP » Wed, 31 Jan 2001 03:54:51


FYI, you may want to look at these two links. There are many others, but
these two have some interesting stuff about what you are interested in, in a
combination of brief points as well as more detailed technical stuff.

http://www.microsoft.com/isaserver/techinfo/FAQ.htm
http://www.microsoft.com/isaserver/techinfo/overviewWP.htm

In addition, I would encourage you and anyone looking at SBS2K to
bookmark/favorites this following link. You will need it.

http://www.microsoft.com/windows2000/library/technologies/default.asp



Quote:> Wow! Thanks for the advice and thoughts.....got a paypal account so I can
send
> you your fee?  :<)
> Susan B.

 
 
 

1. converting /etc/passwd and /etc/shadow passwords to /etc/smbpasswd

Hi,

We have a samba 2.0.6 server running with some W98 clients.
We want our users to authentificate themselves at the server.
the unix password sync works O.K.
My problem is, that right now we have an empty /etc/smbpasswd and an
/etc/shadow
with something like a hundred individual passwords, that we want to
keep.
Is there a tool that converts /etc/passwd and the shadow file to an
smbpasswd file?

thnx
Grant

--
Grant Wallace
http://www.tfh-berlin.de/~wallace

2. Advice on choice of hardware firewall product required

3. File permissions, etc, etc

4. cheap, used, e1 channel bank?

5. Converting NT users and groups to /etc/passwd and /etc/group

6. Changing ICMP Priority?

7. ./configure --with-smbwrapper etc etc

8. XP file locking etc etc...

9. CLSID extension, MIME header vulnerability etc etc

10. Event 2021 "Unable to allocate work item" etc etc

11. Samba roadmap, release plans, etc...

12. ISP changed static IP to dynamic IP, vpn issues