tomocisco wrote:
In my company's corporate LAN, the servers are located on a seperate VLAN. We are using a multilayer switch Catalyst 3560G. I have concern on how to secure the servers beyond the default security provided by the switch.
I witnessed a demonstration, where a hacker was able to execute a script (he wrote using C programing language) to access servers remotely and take control of the desktop and run any program desired (even though there was access list statements filtering window remote desktop access).
Can some one advice me on how to implement appropriate security to secure our servers by stopping/filtering access from the multilayer switch. I know that in most cases they exploit the use of open ports to gain access, how can I know the right ports to shut to avoid.
I used the access list statement below to filter remote desktop access to the servers.
access-list 100 remark remote-access-acl
access-list 100 deny deny tcp 172.20.x.0 0.0.0.255 172.20.y.0 0.0.0.255 eq 3389 log
access-list 100 permit ip any any
But it is not enough to check the hacking scenerio described in the demonstration cited above.
What port numbers are exploited by by program scripts, if I am to shut them down .
Thanks
Thomas

Thomas

There are a number of issues here. You do not explain what the programme was doing so it's difficult to be precise but there is a difference between

a) blocking ports on a network device which stops certain attacks/hacks

b) a flaw in the program code which allows a hacker to exploit the flaw to gain access not intended

a) can be dealt with by using acls on switches/routers. A further step is to use firewalls. But even here you need to be careful. If for example an exploit uses port 445 on windows, you cannot simply block port 445 because then any number of other things break.

b) cannot be dealt with by acls or firewalls (stateful firewalls at least). The reason is that if you allow access to a web server for example you need to open port 80. If there is a flaw in the web server code then you cannot simply block port 80 because then no one has access to the web server. So the solutions to this sort of security issue have to be dealt with differently. There are a number of approaches

i) the first and most obvious is if it is a well known exploit the web server vendor will in all likelihood issue a fix (patch) to remove the exploit. If however it is part of the intended application behaviour that is being exploited (SQL is a good example) then there is no patch to apply as such so you then have to look into

ii) Application layer firewalls - these firewalls actually understand the application commands rather than just keeping state as ASA/Pix firewalls do. Note that ASA/Pix firewalls do have an element of application layer intelligence for certain protocols - fixup and inspect bits of code, but these are limited compared to a firewall that can actually monitor and understand the applications command and data. With an application layer firewall you could actually allow or disallow certain SQL statements for example.

So if they are so good why not use them all the time ?. Because by their very nature they are very specific ie. an application layer firewall that understands SQL will not understand SMTP, so you then need an application layer firewall that understands SMTP etc.. And they introduce more latency than a stateful firewall.

Statefull firewalls are very general in contrast ie. they deal with TCP/UDP/ICMP + some application layer intelligence as mentioned above so they can be applied to most applications.

iii) IDS/IPS - (Intrusion Detection/Intrusion Prevention) - these devices can also evaluate the actual commands and look for patterns in the data traffic and if they see something that you have said should not be allowed they can warn (IDS) or actually block (IPS).

A further point is where the attack took place. If the hacker was demonstrating connected to your network then that is a lot easier for them than from outside your network. If you are worried about internal attacks then NAC, tight desktop security policies etc. are the way to go.

If from outside the network then you shouldn't be allowing RDP from outside to inside anyway. And if you need to give RDP access that way then use an IPSEC VPN or an SSL VPN to secure the connection.

Finally, don't forget host IDS/IPS where you run an IDS/IPS on the actual host as opposed to network IDS/IPS which i was referring to above. There is only so much an acl can do for you and in this case i think it is fairly limited.

Jon