Cisco switch (3750G) extended ACLs?

paradigm

paradigm

paradigm

Caporegime
Joined
26 Aug 2003
Posts
37,508
Location
Leafy Cheshire
I'm having a nightmare with extended ACLs on a 3750G, I'm trying to lock down a particular VLAN (230) to only have SMB access to two places (10.1.6.0/24 and 10.1.0.15), to have windows updates from our WSUS server (10.1.0.21 TCP port 8530/8531), and to be able to use the local DNS servers. There are a few more proprietary ports that are also required too.

I also wanted ANY location on our lan to be able to SMB to hosts on VLAN 230, RDP access to be able to come from 10.1.2.0/24, and again for the proprietary ports to be able to get to a specified host (10.2.3.12) on VLAN 230.

I assumed I would need an ACL for IN and an ACL for OUT, in order to achieve the amount of restriction that I wanted to put in place. And so far I have the following:

Code: 
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 445
access-list 110 permit tcp 10.1.2.0 0.0.0.255 10.2.3.12 0.0.0.0 eq 3389
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 53
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 6400
access-list 110 permit udp any 10.2.3.12 0.0.0.0 eq 6400
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 5432
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 5100
access-list 110 permit udp any 10.2.3.12 0.0.0.0 eq 5100
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 5105
access-list 110 permit udp any 10.2.3.12 0.0.0.0 eq 5105
access-list 110 permit tcp 10.1.0.21 0.0.0.0 10.2.3.12 0.0.0.0 eq 8530
access-list 110 permit tcp 10.1.0.21 0.0.0.0 10.2.3.12 0.0.0.0 eq 8531
access-list 110 permit icmp any any
access-list 110 deny ip any any

Code: 
access-list 111 permit tcp 10.2.3.0 0.0.0.255 10.1.6.0 0.0.0.255 eq 445
access-list 111 permit tcp 10.2.3.0 0.0.0.255 10.1.0.15 0.0.0.0 eq 445
access-list 111 permit tcp 10.2.3.12 0.0.0.0 10.1.2.0 0.0.0.255 eq 3389
access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 53
access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 6400
access-list 111 permit udp 10.2.3.12 0.0.0.0 any eq 6400
access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 5432
access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 5100
access-list 111 permit udp 10.2.3.12 0.0.0.0 any eq 5100
access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 5105
access-list 111 permit udp 10.2.3.12 0.0.0.0 any eq 5105
access-list 111 permit tcp 10.2.3.12 0.0.0.0 10.1.0.21 0.0.0.0 eq 8530
access-list 111 permit tcp 10.2.3.12 0.0.0.0 10.1.0.21 0.0.0.0 eq 8531
access-list 111 permit icmp any any
access-list 111 deny ip any any

access-list 110 was applied to int Vlan230 as "ip access-group 110 in" and access-list 111 was applied to int Vlan230 as "ip access-group 111 out".

However whilst I can still ping 10.2.3.12 from my machine (10.1.2.101), I can no longer RDP to it, which to me makes no sense. This shows that "access-list 110 permit icmp any any" is working fine but yet "access-list 110 permit tcp 10.1.2.0 0.0.0.255 10.2.3.12 0.0.0.0 eq 3389" seems to be doing nothing?

Where am I going wrong :confused:

halp!
 
With a little help from DRZ it seems that the issue stems from there being no allowed route for the originating high-port (typically between 60700 and 60799 from my time-limited testing in the last few minutes). However I don't see a simple way of allowing the return ports given that they are randomly generated, and could be coming from any number of hosts on any number of subnets.

VLAN230 is currently untrusted (and hosts an insecure machine), and as such I can't permit ip any any, or even permit any any eq 60700 - 60799 due to security risks.

Stuck :(
 
bigredshark said:
There's a reason firewalls exist...such are the problems of trying to do security on a switch/router etc, it has limitations.
Click to expand...

Unfortunately this problem was more thrown upon us rather than discussed with us.

I've advised the people who made this monumental ****-up of a decision that they will need to purchase additional networking hardware to do what is being asked.

Personally I'd like to just bin the whole system that needs segregating off, but that's a company political issue ;)
 
There shouldn't be a problem with what you're trying to do.
For each entry in one access list based on destination port, you need one in the other based on source port to allow the return traffic.

For example:
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 445
will need:
access-list 111 permit tcp 10.2.3.12 0.0.0.0 eq 445 any

access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 6400
will need:
access-list 110 permit tcp any eq 6400 10.2.3.12 0.0.0.0

It depends, but I wouldn't bother with an outgoing ACL and just filter on incoming.
 
Tui said:
There shouldn't be a problem with what you're trying to do.
For each entry in one access list based on destination port, you need one in the other based on source port to allow the return traffic.

For example:
access-list 110 permit tcp any 10.2.3.12 0.0.0.0 eq 445
will need:
access-list 111 permit tcp 10.2.3.12 0.0.0.0 eq 445 any

access-list 111 permit tcp 10.2.3.12 0.0.0.0 any eq 6400
will need:
access-list 110 permit tcp any eq 6400 10.2.3.12 0.0.0.0

It depends, but I wouldn't bother with an outgoing ACL and just filter on incoming.
Click to expand...

That would be great, if you knew the source port, however given that (for example) SMB uses a randomly generated high-port, there is no way of statically allowing return on a single port. The same goes for RDP.

I can't only filter on incoming as that particular machine needs to be limited from breaking out to anywhere on any port except explicitly the list in the OP. This is an unavoidable situation due to the insecurities of the machine in question.
 
I'd still give it another try because if you did have "ip access-group 110 in" and "ip access-group 111 out" on Vlan230, you also have your source and destination addresses reversed.

If we just look at RDP, the outgoing ACL needs to allow source 10.1.2.0/24, any port, to destination 10.2.3.12, TCP 3389:
access-list 111 permit tcp 10.1.2.0 0.0.0.255 10.2.3.12 0.0.0.0 eq 3389

For the reverse traffic, the incoming ACL needs to allow source 10.2.3.12, TCP 3389, to destination 10.1.2.0/24, any port:
access-list 110 permit tcp 10.2.3.12 0.0.0.0 eq 3389 10.1.2.0 0.0.0.255

SMB from anywhere to the network is similar:
access-list 111 permit tcp any 10.2.3.0 0.0.0.255 eq 445
access-list 110 permit tcp 10.2.3.0 0.0.0.255 eq 445 any

SMB from the network to your network/server:
access-list 110 permit tcp 10.2.3.0 0.0.0.255 10.1.6.0 0.0.0.255 eq 445
access-list 110 permit tcp 10.2.3.0 0.0.0.255 10.1.0.15 0.0.0.0 eq 445
Reverse traffic:
access-list 111 permit tcp 10.1.6.0 0.0.0.255 eq 445 10.2.3.0 0.0.0.255
access-list 111 permit tcp 10.1.0.15 0.0.0.0 eq 445 10.2.3.0 0.0.0.255

And so on.
 
I think you'll find that my ACL's ARE written like that. The problem is (and running a sniff with wireshark will confirm) that the source port is a random high-port typically in the 60000-65000 region. Given that I can't accurately know what source port either an SMB or RDP connection will have, you can't allow the return traffic with a static ACL.

A reactive ACL would do the job, but they aren't supported on the IOS on the 3750G platform, as already stated we'd need a router/firewall to do what we need.
 
Forgive me if i'm wrong but i would agree with TUI with regards to the RDP Traffic

You've specified 3389 as the destination port both ways which it isnt, you need to select it as the source port for returning traffic, destination port would be "any" (>1024)

i.e

access-list XXX permit tcp W.W.W.W X.X.X.X eq 3389 Y.Y.Y.Y Z.Z.Z.Z (Returning Traffic)

so third line in 111 would be:

access-list 111 permit tcp 10.2.3.12 0.0.0.0 eq 3389 10.1.2.0 0.0.0.255 (Outbound from Isolated Host in VLAN 230 to Your machine on subnet 10.1.2.0/24)

(Access lists removed)

A "netstat -an" on your pc would show:

TCP 10.1.2.101:RANDOM-PORT 10.2.3.12:3389 ESTABLISHED

A "netstat -an" on the "isolated" PC should show

TCP 10.2.3.12:3389 10.1.2.101:RANDOM-PORT ESTABLISHED
 
Last edited:
Cheers $c8t@, but 111 was posted as the outgoing ACL on the isolated network interface and since this is server to client traffic from the isolated host, should be in the incoming ACL 110.

It seems the OP has already decided that the only way to do this is with stateful inspection and since this is just a simple filtering of traffic flows, I wouldn't waste any more time continuing to point out the obvious. Never mind.
 
It is all purely academical now anyway, as the problematic server that needed to be isolated is to be removed (along with the sadistic phone system it runs).
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom