Wednesday, 25 February 2009

Rate Limit and QoS

One of the biggest problems with WAN links to how to manage your traffic, should it be percentage based or rate limited?

Well percentage based is fine to a point, that is to say its fine but in a IP calls it could be a problem and some other real time services such a video.

Quick example 50% of your WAN link is reserved for IP calls by you QoS policy lets say... but if more than x number of users make a call the link will have too much traffic and calls will become fuzz to say the least.
So to over come this we are going to just allow 15 on our 1158kbps line with no more than 100kbps on each.

The following example shows a T1 (1536 kbps) link configured to permit RSVP reservation of up to 1158 kbps, but no more than 100 kbps for any given flow on interface serial 0/0. Fair queuing is configured with 15 queues to support those reserved flows, should they be required.

interface serial0/0
fair-queue 64 256 15
ip rsvp bandwidth 1158 100


Another way this can be done is between a host or range so that the quolity remains high for the links between

To enable a router to simulate receiving and forwarding Resource Reservation Protocol (RSVP) RESV messages, use the ip rsvp reservation global configuration command. To disable this feature, use the no form of this command.
ip rsvp reservation session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-dport
sender-sport next-hop-ip-address next-hop-interface {ff | se | wf} {rate | load} bandwidth
burst-size

The following example specifies the use of a Shared Explicit style of reservation and the controlled load service, with token buckets of 100 or 150 kbps and 60 or 65 kbps maximum queue depth:
ip rsvp reservation 224.250.0.2 172.16.1.1 UDP 20 30 172.16.4.1 Et1 se load 100 60
ip rsvp reservation 224.250.0.2 172.16.2.1 TCP 20 30 172.16.4.1 Et1 se load 150 65


The following example specifies the use of a Wild Card Filter style of reservation and the guaranteed bit rate service, with token buckets of 300 or 350 kbps and 60 or 65 kbps maximum queue depth:
ip rsvp reservation 224.250.0.3 0.0.0.0 UDP 20 0 172.16.4.1 Et1 wf rate 300 60
ip rsvp reservation 226.0.0.1 0.0.0.0 UDP 20 0 172.16.4.1 Et1 wf rate 350 65


Note that the Wild Card Filter does not admit the specification of the sender; it accepts all senders. This action is denoted by setting the source address and port to zero. If, in any filter style, the destination port is specified to be zero, RSVP does not permit the source port to be anything else; it understands that such protocols do not use ports or that the specification applies to all ports. This can can be a problem if other services are on the same range so best to define access lists to block all unwanted traffic.

Last but not least.
To reserve a strict priority queue for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the ip rtp priority interface configuration command. To disable the strict priority queue, use the no form of this command.
ip rtp priority starting-rtp-port-number port-number-range bandwidth


The following example first defines a CBWFQ configuration and then reserves a strict priority queue
with the following values: a starting RTP port number of 16384, a range of 16383 UDP ports, and a
maximum bandwidth of 40 kbps:

! The following commands define a class map:
class-map class1
match access-group 101
exit

! The following commands create and attach a policy map:
policy-map policy1
class class1
bandwidth 3000
queue-limit 30
random-detect
random-detect precedence 0 32 256 100
exit

interface Serial1
service-policy output policy1
! The following command reserves a strict priority queue:
ip rtp priority 16384 16383 40


Defining what is best for you or even using all of these rate limits and QoS is something that will be up to you... but remember not to use too many of them as other wise you will end up with a lines that are never fully used as all the policy's prevent it.

Good rule of thumb keep the policy's simple.

Friday, 20 February 2009

DMZ for Legacy applications?

The majority of enterprises have the habit of forgetting one or more Legacy applications are running out of date software and perhaps even unsupported version and due to design reason can’t be upgraded.

By design I mean ether the program was poorly written and won’t run even in compatibility mode on later versions as the Developer didn’t use coding standards.

Trust me when I say 90% of the time developers seem blissfully unaware there is even such a thing as standard practice to developing.

Or the software house no longer exists, the reasons are numerous but the outcome is the same you have a hole in your security.

Out of data version of software make you vulnerable to code exploits, DoS and other well known attacks on these applications.

Remember that you have just as many security risks in your company as outside of it.

So to better secure your application and avoid security breaches or DoS attacks place the older application into a DMZ in the same way you would with web server or email server so that you can control the traffic that is going to and from them. (Don’t put them in the same DMZ as your public facing servers such as web and email or the network administrator from hell will eat your soul!!!) ok he won't but I needed to make it clear to you. Put them in a separate DMZ for internal use only.

Remember that limiting the ports and destinations of the traffic will make it far more secure; it is also good practice to limit the way traffic flows on your LAN, where possible place all application servers into a DMZ or at least limit on the switches or VLAN’s the traffic flowing between them.

OK enough theory now for real life example… company has old in house application that runs the report for managers on projected sales nothing special in that but its running of a visual basic application with a SQL backend, so far nothing special however the SQL server is version 7.0 that is no longer supported or patched, the developer made some coding in the database that stops the reports from working in later version and the developer no longer works for the company so we need to keep it for now.

Using well known exploits I when from having a user account with limited access to SA access in just under 20minutes (thanks to Google) no deep SQL knowledge needed just some light reading, just type the version and word exploit and your halfway done.

After some meetings it was shown that if you had only the visual basic application accessing SQL on what is well known ports we could prevent 98% or the attacks, still not built proof but much better than a before.

So remember DMZ’s are not just for public facing services, as half the security risk in working on your network.