Network Security Question

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Hi all,

I just wonder if anyone could help me here. (this is an internal network split in two between firewall a AD server each side no details given on forrest or domain setup just asked to comment)

Basically you have two networks one either side and my
idea was to create a secure tunnel between the two. I
was told that was incorrect, but at the back of my
mind I thought no not when you have two AD servers...
one either side that would need to replicate to each
other. The primary reason I thought would be that you
would end up opening too many ports, ie all the ports need for AD rep plus a massive of amount of high end ports. So two end points
would be better (I was told this would stop IDS's but
the traffic would be encrypted only between the two
points, so the inside traffic could still be sniffed),
then only the IPSec ports would need to be open at
each firewall. Quote from MS site:

Getting replication to function properly in
environments where a directory forest is distributed
among internal, perimeter networks and external
networks can be challenging. There are three possible
approaches:

Open the firewall wide to permit RPC's native dynamic
behaviour.

Limit RPC's use of TCP ports and open the firewall
just a little bit.

Encapsulate domain controller (DC-to-DC) traffic
inside IP Security Protocol (IPSec) and open the
firewall for that.

So as stated above, the dynamic nature of AD is the
problem (I suppose you could do a registry change to
make AD replication choose the same port every time
and not the wide dynamic native behaviour)

If it was also two separate companies collaborating
i.e. one either side and replication was not needed
between the two then you would still look to a secure
tunnel like IPSec and look towards reducing things
down with a trust relationship. i.e. depending on the
resources to be shared we could use a selective
one-way trust and then secure it with the correct NTFS
permissions also.


IPSec provides a way to easily encapsulate and carry
RPC traffic over a firewall. Besides simplifying the
transport of RPC, IPSec also increases security
between the DCs because of IPSec's mutual
authentication feature: by using either Kerberos or
machine certificates, the DCs will "know" whom they
are communicating with before any actual information
exchange occurs.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Who told you that you shouldn't use a tunnel?

 

Oh I attended a job interview and was asked to comment on a network diagram. Had silly things like port 139 open to the outside world so said that should be closed. All ports out were open said those rules should be tighter or at very least using stateful. Had Ras server I said should be controlled with a AAA Radius type control. SMTP should have a rule only accepting port 25 from ISP SMTP feed etc

But I had the two networks that appeared to be the same company joined or they must have been collabrating connected over a IPSec tunnel.... On the diagram it had ports like 3389 RDP, 445 open, showing a file share which I guess could be a problem if not secured with correct NTFS or no sharing was needed. Anyway I saw the two AD servers and then thought no I keep the firewall ports tight between the two networks and secure thing correctly via NTFS or selective trusts, ie if someone only needed resources on one server then only give trust to that server.....

Anyway I'm just keen to learn what I did wrong, as now I'm not so sure I am wrong?

 

If locking down ports and creating tunnels was the "wrong answer" to that company... perhaps you dodged a bullet by not being hired there!!!

 

There are only two 'real' solutions to this problem - the first would be to purchase a leased line solution from a telco (IPVPN, MPLS or straight site to site) - which would be hideously expensive. The other is to do what your answer to the question was - implement a site to site VPN. Quite why the company you were interviewing for told you that you were 'wrong' is beyond me. I have worked for more than twenty different companies for varying lengths of time (from one week consults to two year full time jobs). Every single one of them has had site to site VPNs (except three that were large enough to use leased MPLS).

Simply - you're right, and they're wrong.

 

Mmmmm the only thing I can think is that because it's an internal LAN (not clear as had a lightning strike which usually indicates a wan link from memory) that by running a tunnel you're letting all traffic traverse the connection. (Think that's what he said) but again if you're going to open that many ports then your attack surface has grown anyway with the amount of ports you would have to open (TCP 135-139,RPC dynamic 1024-65535, 445, 389, 3268, 88, 53 & then 1512 plus 42 if using wins. Added to these the relevant udp ports also. Also I wouldn't fancy making a reg change like that on my AD servers (less than ideal) plus you would'nt get the added benefits of encryption and mutual authentication that you're talking to the correct party. As stated before even if two separate companies I'd use trust's and NTFS permissions. I mean if you're collaborating you have to have some connection and level of trust? So if the data is encrypted and locked down with permissions, access is denied and sniffing and even man in the middle/session Hijacking type threats are reduced when compared to just opening the right ports.

Any more comments greatly appreciated, otherwise thanks chaps

 

I've had another thought about why I'm partly wrong. The one side of the network had an e-commerce server. So I'd caused the other network to have a physical connection. (even though logically it would still be locked with the trust and NTFS controls or IPSec negotiations) So in this situation I was partly wrong, again I stand by the IPSec tunnel, but I should of sectioned the sensitive server away. A Even better solution would have been to isolated the server, physically and logically if possible from the normal production network. Perhaps using a separate workgroup or domain behind its own security measures?