topic Re: securing active directory communication in Network Security

securing active directory communication

par13 — Mon, 11 Mar 2019 17:30:38 GMT

One is attempting to get a cisco pix 515e. So far,the internal hosts can perform many small tasks, like browsing the internet, etc.

However, these machines are joint to an external active directory. Therefore, between the network behind the firewall an a remote network, the cisco pix 515e must allow this traffic to go back and forth. At the same time, I do not want other internet networks have access to the computers behind the firewall.

What type of acl rule should allow me to acomplish this task?

Can someone experience with this type of firewall share how you configure for windows active directory communication between local and remote networks?

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 02:12:02 GMT

Hi,

Have you considered establishing an IPsec VPN tunnel between both locations and restricting the access through the tunnel?

You should have on the other end, another PIX, router, ASA, concentrator, or any device that can terminate an IPsec site-to-site.

Federico.

Re: securing active directory communication

par13 — Fri, 09 Apr 2010 05:10:14 GMT

Beside using IPSec, can I created a set of object-group network objects? and, then create a set of acl rules for this communication?

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 14:54:59 GMT

Correct.

Federico.

Re: securing active directory communication

par13 — Fri, 09 Apr 2010 18:19:09 GMT

I have been testing a few rules:

access-list extended permit tcp host 172.31.53.36 host 10.8.1.2 eq 3389

access-list outside permit tcp any any eq 3389

But,It does not work!

What am I doing wrong?

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 19:46:52 GMT

TCP 3389 is not for AD communication is for RD access.

If you create an ACL allowing TCP 3389 to an internal server, then that ACL needs to be applied to the correct interface.

Let's say that you want to access an internal server that has the IP 192.168.1.1 and it's NAT IP is 200.200.200.1

You configure the NAT rule:

static (in,out) 200.200.200.1 192.168.1.1

Then you permit (in this case) TCP port 3389 or any other traffic.

access-list OUTSIDE permit tcp any host 200.200.200.1 eq 3389

Then, you apply the ACL to the outside interface in the inbound direction:

access-group OUTSIDE in interface outside

If the communication is through a VPN tunnel, then its different because you will access the server via its private real address (not the NATed).

In this case you will configure the rule (ACL) applied to the inside interface.

Federico.

Re: securing active directory communication

par13 — Fri, 09 Apr 2010 20:01:55 GMT

Federico,

Thanks for your patience, it did work. This NAT process is not very helpful for everything situation.

How can I stop using NAT for one of the internal interfaces?

Going to my original topic, I have an internal network that can't be doing NATing. The external network needs to see the addresses. The addresses are not public, instead private. But, they are routable inside our entire organization environment.

Therefore,, How do I stop NATing in one of the interfaces, and make direct connections between out side and inside.

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 20:07:10 GMT

If the PIX is running an old image, then you need to NAT.

But you can avoid the actual NATing by doing identity NAT.

This means that if your internal network is 192.168.1.0/24, you can create a rule to be able to access the internal network with their real addresses, like this:

static (in,out) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

Obviously, this will not work from the Internet since you have a private sheme.

If you're running a relatively new image, you can turn of NAT with the command: no nat-control

Then, you can communicate between interfaces without the need for NAT.

Federico.

Re: securing active directory communication

par13 — Fri, 09 Apr 2010 20:12:05 GMT

The firewall is running version 6.3(5). Do I upgrade this to a

new version? Second, when I use the command you share on your last message:

static (in,out) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

This will allow the internal network to be visible outside of the firewall, but inside our organization network infrastructure.

Is this a thruth statement?

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 20:16:21 GMT

That is correct (only within your organization where 192.168.1.0/24 is routable)

To disable the need for NAT, you must upgrade.

But you can accomplish what you want with the command:

static (in,out) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

And permitting the traffic with ACL.

Federico.

Re: securing active directory communication

par13 — Fri, 09 Apr 2010 20:38:40 GMT

ok,

I created an object-group network administrative-servers

network-object host X.X.X.X

These are addresses located out side of the firewall.

Then,

I have created a:

static (in,out) 10.8.1.0 10.8.1.0 netmask 255.255.255.0

access-list extended permit ip any object-group administrative-servers

access-list extended permit ip object-group administrative-servers any

Will this allow communication back and forth between the internal network and the administrative-servers group?

Re: securing active directory communication

Federico Coto Fajardo — Fri, 09 Apr 2010 20:45:46 GMT

No.

network-object host X.X.X.X

static (in,out) 10.8.1.0 10.8.1.0 netmask 255.255.255.0

access-list outside permit ip object-group administrative-servers 10.8.1.0 255.255.255.0

access-group outside in interface outside

The above configuration will allow the IPs defined in the object-group to allow the internal 10.8.1.0/24

You can further create object-groups for the ports that you which to allow to be more restrictive.

Federico.

Re: securing active directory communication

par13 — Mon, 12 Apr 2010 20:17:06 GMT

Hello,

Just receive new subnet(s) for the network(s) behind the firewall. the addresses are public addresses.

Therefore, after entering the information for each respective internal interface, now, the internal network stop communicating to the internet.

Because of the network privacy, this time, I will not be able to reveal network addresses. Can you take a look why the internal network will not be able to go out to the internet. Again, these are public addresses, they do not need to be NAT.

PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto shutdown
interface ethernet4 auto shutdown
interface ethernet5 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security4
nameif ethernet3 intf3 security6
nameif ethernet4 intf4 security8
nameif ethernet5 intf5 security10
enable password DAyT8Zy5o1YlaDcM encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
hostname lvfw
domain-name lv.psu.edu
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
object-group network administrative-servers
network-object host X.X.X.X
network-object host X.X.X.X
network-object host X.X.X.X

access-list extended permit ip any any
access-list extended permit icmp any any
access-list extended permit ip any object-group administrative-servers
access-list extended permit ip object-group administrative-servers any
access-list outside permit icmp any any
access-list outside permit tcp any any eq domain
access-list inside permit tcp any any eq www
access-list outside permit udp any any eq domain
access-list outside permit tcp any any eq 3389
access-list outside permit ip object-group administrative-servers A.B.C.D 255.255.255.128
pager lines 24
icmp permit any echo-reply outside
icmp permit any echo-reply inside
mtu outside 1500
mtu inside 1500
mtu intf2 1500
mtu intf3 1500
mtu intf4 1500
mtu intf5 1500
ip address outside C.D.E.F 255.255.255.248
ip address inside H.I.J.M 255.255.255.192
ip address intf2 A.B.C.D 255.255.255.128
no ip address intf3
no ip address intf4
no ip address intf5
ip audit info action alarm
ip audit attack action alarm
no failover
failover timeout 0:00:00
failover poll 15
no failover ip address outside
no failover ip address inside
no failover ip address intf2
no failover ip address intf3
no failover ip address intf4
no failover ip address intf5
pdm history enable
arp timeout 14400
global (outside) 1 interface
static (inside,outside) A.B.C.D A.B.C.D netmask 255.255.255.128 0 0

static (inside,outside) H.I.J.M H.I.J.M netmask 255.255.255.192 0 0
access-group outside in interface outside
route outside 0.0.0.0 0.0.0.0 T.O.P.Q 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http A.B.C.D 255.255.255.128 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80
: end
lvfw#