[nsp] RE: blocking Msn messenger on PIX /Re: Suggestions on
tracking do wn bandwidth offenders
Martin Wills
MWills at cxtec.com
Wed Jul 14 15:09:17 EDT 2004
Hi All,
2x birds, 1x stone:
Here's a thought- Using Cisco NBAR we ID MSN messenger and a slew of other
types of traffic. Typically, once we have I.D.ed the type of traffic we
want to block, we can classify it using QoS. With the QoS configured, we
can typically enable a policer that could, for example, drop all traffic
related to MSN messenger.
In Regards to bandwidth oversubscription, we can address this by
prioritizing the important traffic, ensuring that it takes priority & has
access when & where it's needed. This works well in concert with link
efficiency mechanisms (like header compression, for example). In the event
we have not-so-important traffic, we could usually limit that traffic so it
might be able to utilize no more than 10% of the available bandwidth, for
example.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guid
e09186a0080087cd0.html#wp1072129
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuratio
n_guide_chapter09186a00800b75cc.html
Best regards,
J. Martin Wills; CQS, CCNP, CCDP
-----Original Message-----
From: cisco-nsp-request at puck.nether.net
[mailto:cisco-nsp-request at puck.nether.net]
Sent: Wednesday, July 14, 2004 2:06 PM
To: cisco-nsp at puck.nether.net
Subject: cisco-nsp Digest, Vol 20, Issue 38
Send cisco-nsp mailing list submissions to
cisco-nsp at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
cisco-nsp-request at puck.nether.net
You can reach the person managing the list at
cisco-nsp-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."
Today's Topics:
1. RE: blocking Msn messenger on PIX
(Hudson Delbert J Contr 61 CS/SCBN)
2. bgp - aggregates and specific routes (Roger)
3. Suggestions on tracking down bandwidth offenders (Tony Mucker)
4. Re: Suggestions on tracking down bandwidth offenders
(Mike Lewinski)
5. RE: Suggestions on tracking down bandwidth offenders
(Raymond, Steven)
6. Re: bgp - aggregates and specific routes (joshua sahala)
7. Re: Suggestions on tracking down bandwidth offenders
(joshua sahala)
8. Re: Suggestions on tracking down bandwidth offenders (Tony Mucker)
9. Re: Suggestions on tracking down bandwidth offenders
(Michael Axelrod)
10. Re: Suggestions on tracking down bandwidth offenders
(Hank Nussbacher)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Jul 2004 09:41:20 -0700
From: Hudson Delbert J Contr 61 CS/SCBN
<Delbert.Hudson at LOSANGELES.AF.MIL>
Subject: RE: [nsp] blocking Msn messenger on PIX
To: "'Muhammad Talha'" <talha at worldcall.net.pk>,
cisco-nsp at puck.nether.net
Message-ID:
<7EACCDBB65D37443912D80713CC1245D02382A3B at fsnsab20.losangeles.af.mil>
Content-Type: text/plain; charset="iso-8859-1"
remember..
netsec doesnt roast turkeys...cant set it and forget it..
security in depth requires multi-layers of measures and procedures..
which must be tweaked and massaged based on enterprise security policy
which in turn needs to be massaged based on industry and markets.
there are ways.....
example...after establishing what the acceptable use is....
ranging from none of this traffic in either direction at all to
only some users or subnets to completely open.
may seem to be more work that worth but it is a practical approach as
it scales well for other scenarios like securing you nets from stuff like
p2p
garbage.
1. remove the desktop admin rights from the user, if you can. this
helps immensely.
2. if possible, push for prohibiting these connection ATTEMPTS as
operational policy.
3. if it doesnt break 'for business apps', block or prevent
installation of any client
software that uses this protocol, remove or disable any client
software on the user
desktops.
4. write perl/python/vb/java/whatever kind of packetsucker scripts that
detect the address/port
patterns of suspected messenger protocol.
5. spoof rsvp's to these guyz from a messenger honeypot, if they
respond, use whatever
blocking scheme (nets or host or ports from those nets or hosts)
6. an added enforcement benefit might be to re-direct internal client
shenangans in the logs
of the honeypot (hr issue...) btw....create a vpn and tunnel the
logs to a 'dropsafe'
machine on the inside so they are not compromised in case of
litigation later.
~piranha
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Muhammad Talha
Sent: Wednesday, July 14, 2004 12:24 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [nsp] blocking Msn messenger on PIX
> Kristofer Sigurdsson wrote:
>
> >Mark Tinka, Tue, Jul 13, 2004 at 04:07:03PM +0200 :
> >
> >
> >>On Tuesday 13 July 2004 15:36, Paul Stewart wrote:
> >>
> >>
> >>>Unfortunately doesn't work unless you block port 80 as well and you
> >>>probably don't want to do that... MSN messenger will default to TCP/80
> >>>when it can't reach 1863. What I ended up doing at a few sites that
had
> >>>their own internal DNS was creating entries for messenger.msn.com
(double
> >>>check that - it may have changed) to point to 127.0.0.1 therefore it
> >>>couldn't login at all.... Worked like a dream....
> >>>
> >>>
> >>But this would work best if the site doesn't want 'everyone' using MSN.
What
> >>about if only 10% of all staff are authorised to use it?
> >>
> >>The other issue is a smart user will simply use another name server some
where
> >>on the global Internet, or at the ISP, for resolution, especially if
they are
> >>sharp enough to ping 'messenger.msn.com' and see the resolved IP =
> >>127.0.0.1 :).
> >>
> >>
> >
> >How about simply blocking messenger.hotmail.com (207.46.104.20) for those
who are
> >not authorised to use MSN?
> >
> >
> If you have TACACS server, an authentication proxy can be implemented
> using PIX firewall. The feature is called per user ACL using av-pair of
> radius. Search CCO and you will find many references to it.
One more thing if u give manually proxy in browser . Blank your Dns
setting ( no dns is configured )
browser use dns of proxy. msn will still work using any proxy. so make
fake entry in dns wont work.
i will try to look at authentication proxy feature .
Thanks & Regards
Talha
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
------------------------------
Message: 2
Date: Wed, 14 Jul 2004 12:02:52 -0500
From: Roger <grunky at rockriver.net>
Subject: [nsp] bgp - aggregates and specific routes
To: cisco-nsp at puck.nether.net
Message-ID: <40F5673C.50300 at rockriver.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
I have a question reguarding BGP aggregate routes and more specific
routes. Currently we have 2 WAN links w/ large carriers running eBGP, we
advertise our /19 aggregate, example 192.168.0.0/19.
A customer of ours, who's range is say 192.168.16.0/24 will be using our
numbers and advertising said route to other eBGP peers.
My question is - if the link between us and our customer at 16.0/24 goes
down we need to advertise that 16.0/24 as invalid while still
advertising our /19. The customer w/ the 16.0/24 should still be
connected via their other eBGP links.
How would I do this? Currently my BGP setup is like so. Now if the
16.0/24 peering session goes down traffic will still flow because it
will be lumped into our /19.
router bgp 1
no synchronization
bgp log-neighbor-changes
network 192.168.0.0 mask 255.255.224.0
neighbor 1.2.3.4 remote-as 1234
neighbor 1.2.3.4 description WAN Link 1
neighbor 1.2.3.4 send-community
neighbor 5.6.7.8 remote-as 5678
neighbor 5.6.7.8 description WAN Link 2
neighbor 5.6.7.8 send-community
neighbor 192.168.16.254 remote-as 2
neighbor 192.168.16.254 description downstream customer
neighbor 192.168.16.254 send-community
!
ip route 192.168.0.0 255.255.224.0 Null0
------------------------------
Message: 3
Date: Wed, 14 Jul 2004 10:24:25 -0700
From: Tony Mucker <Tony at tonymucker.com>
Subject: [nsp] Suggestions on tracking down bandwidth offenders
To: cisco-nsp at puck.nether.net
Message-ID: <40F56C49.1090808 at tonymucker.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I've got a bandwidth problem (who doesn't). Something has been
saturating my poor little T1 for 24 hours straight now. For those of
you curious, here's what it looks like:
http://www .ghideon.com/router-day.png
Remove the white space and enjoy. In the past I've used ethereal dumps
to figure out who the big talkers were, but frankly it takes too long to
crunch all the packets. I've also tried etherApe, but the analysis
makes my poor little laptop crawl. Are there any tools out there that
will speed this up? Possibly by looking at the firewall logs?
Thanks
Tony
------------------------------
Message: 4
Date: Wed, 14 Jul 2004 11:32:32 -0600
From: Mike Lewinski <mike at rockynet.com>
Subject: Re: [nsp] Suggestions on tracking down bandwidth offenders
To: cisco-nsp at puck.nether.net
Message-ID: <40F56E30.4030402 at rockynet.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Tony Mucker wrote:
> I've got a bandwidth problem (who doesn't). Something has been
> saturating my poor little T1 for 24 hours straight now. For those of
> you curious, here's what it looks like:
>
> http://www .ghideon.com/router-day.png
>
> Remove the white space and enjoy. In the past I've used ethereal dumps
> to figure out who the big talkers were, but frankly it takes too long to
> crunch all the packets. I've also tried etherApe, but the analysis
> makes my poor little laptop crawl. Are there any tools out there that
> will speed this up? Possibly by looking at the firewall logs?
For long term monitoring I like setting up a dedicated IDS box with ipfm
and snort. Tuning the latter will take a bit of work but you can get
down the number of false alerts. I wrote a stupid perl script to extract
the ipfm data and create MRTG graphs by IP. This assumes you can do port
monitoring on a switch. Actually, assuming that you have a managed
switch, running some kind of monitoring tool on it is probably going to
be your simplest option. I had to resort to ipfm mainly because it was a
WLAN with no ports to monitor.
------------------------------
Message: 5
Date: Wed, 14 Jul 2004 10:38:52 -0700
From: "Raymond, Steven" <steven_raymond at eli.net>
Subject: RE: [nsp] Suggestions on tracking down bandwidth offenders
To: Tony Mucker <Tony at tonymucker.com>
Cc: cisco-nsp at puck.nether.net
Message-ID:
<DDB2E58FE1DF174CBF8F66337DDD39E1578195 at wava00s2ke2k01.corp.pvt>
Content-Type: text/plain; charset="iso-8859-1"
> to figure out who the big talkers were, but frankly it takes
> too long to
> crunch all the packets. I've also tried etherApe, but the analysis
> makes my poor little laptop crawl. Are there any tools out
> there that
> will speed this up? Possibly by looking at the firewall logs?
Have you tried 'ip accounting output-packets' on your LAN interface(s)?
To narrow the output down, it then helps to do something like this:
sh ip accounting | e (_[0-9]_|_[0-9][0-9]_)
Which means "exclude any lines 1 or 2 digit numbers surrounded by spaces".
Add more [0-9] to look at only the larger talkers.
It's quick & dirty, but easy.
HTH
------------------------------
Message: 6
Date: Wed, 14 Jul 2004 13:40:13 -0400
From: joshua sahala <jejs at sahala.org>
Subject: Re: [nsp] bgp - aggregates and specific routes
To: Roger <grunky at rockriver.net>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20040714174013.GA18690 at aurvandil.sahala.org>
Content-Type: text/plain; charset="us-ascii"
On (14/07/04 12:02), Roger wrote:
> To: cisco-nsp at puck.nether.net
> From: Roger <grunky at rockriver.net>
> Date: Wed, 14 Jul 2004 12:02:52 -0500
> Subject: [nsp] bgp - aggregates and specific routes
>
> I have a question reguarding BGP aggregate routes and more specific
> routes. Currently we have 2 WAN links w/ large carriers running eBGP, we
> advertise our /19 aggregate, example 192.168.0.0/19.
ok so far
> A customer of ours, who's range is say 192.168.16.0/24 will be using our
> numbers and advertising said route to other eBGP peers.
your numbers?
> My question is - if the link between us and our customer at 16.0/24 goes
> down we need to advertise that 16.0/24 as invalid while still
> advertising our /19. The customer w/ the 16.0/24 should still be
> connected via their other eBGP links.
how are you learning the /24? if you are learning it from your
customer, then when the link goes down, you will stop learning that
prefix and will subsequently stop advertising it. if you are
learning it via some other means, then i'd need to know how that is
to answer this.
> How would I do this? Currently my BGP setup is like so. Now if the
> 16.0/24 peering session goes down traffic will still flow because it
> will be lumped into our /19.
/24 is more specific than /19, so for addresses in that /24, traffic
will go towards your customers other providers. all other traffic
for the /19 will come to you
>
> router bgp 1
> no synchronization
> bgp log-neighbor-changes
> network 192.168.0.0 mask 255.255.224.0
> neighbor 1.2.3.4 remote-as 1234
> neighbor 1.2.3.4 description WAN Link 1
> neighbor 1.2.3.4 send-community
> neighbor 5.6.7.8 remote-as 5678
> neighbor 5.6.7.8 description WAN Link 2
> neighbor 5.6.7.8 send-community
> neighbor 192.168.16.254 remote-as 2
> neighbor 192.168.16.254 description downstream customer
> neighbor 192.168.16.254 send-community
> !
> ip route 192.168.0.0 255.255.224.0 Null0
this looks good - make sure that you are using some prefix filters
and/or as path filters to prevent readvertising prefixes that you do
not want to provide transit for ;-)
/joshua
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
- Douglas Adams -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
https://puck.nether.net/pipermail/cisco-nsp/attachments/20040714/9229832f/at
tachment-0001.bin
------------------------------
Message: 7
Date: Wed, 14 Jul 2004 13:44:25 -0400
From: joshua sahala <jejs at sahala.org>
Subject: Re: [nsp] Suggestions on tracking down bandwidth offenders
To: Tony Mucker <Tony at tonymucker.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <20040714174425.GB18690 at aurvandil.sahala.org>
Content-Type: text/plain; charset="us-ascii"
On (14/07/04 10:24), Tony Mucker wrote:
>
> I've got a bandwidth problem (who doesn't). Something has been
> saturating my poor little T1 for 24 hours straight now. For those of
> you curious, here's what it looks like:
>
> http://www .ghideon.com/router-day.png
>
> Remove the white space and enjoy. In the past I've used ethereal dumps
> to figure out who the big talkers were, but frankly it takes too long to
> crunch all the packets. I've also tried etherApe, but the analysis
> makes my poor little laptop crawl. Are there any tools out there that
> will speed this up? Possibly by looking at the firewall logs?
>
depends on what kind of firewall you have - there are scripts for
various firewalls, providing you have some sort of accounting turned
on. for your router you can do some basic accounting too. either
using netflow or ip accouting. google for top talkers scripts for
each
/joshua
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
- Douglas Adams -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
https://puck.nether.net/pipermail/cisco-nsp/attachments/20040714/874e506c/at
tachment-0001.bin
------------------------------
Message: 8
Date: Wed, 14 Jul 2004 10:46:22 -0700
From: Tony Mucker <Tony at tonymucker.com>
Subject: Re: [nsp] Suggestions on tracking down bandwidth offenders
To: joshua sahala <jejs at sahala.org>
Cc: cisco-nsp at puck.nether.net, Tony Mucker <Tony at tonymucker.com>
Message-ID: <40F5716E.6040907 at tonymucker.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm using a PIX 520, PIXOS 6.3 (sorry, forgot to mention that). I tried
the ip accounting for the output packets, but unfortunately all the
traffic is going to the firewall. Is there anything I can monitor on
the firewall to do this?
joshua sahala wrote:
>On (14/07/04 10:24), Tony Mucker wrote:
>
>
>>I've got a bandwidth problem (who doesn't). Something has been
>>saturating my poor little T1 for 24 hours straight now. For those of
>>you curious, here's what it looks like:
>>
>>http://www .ghideon.com/router-day.png
>>
>>Remove the white space and enjoy. In the past I've used ethereal dumps
>>to figure out who the big talkers were, but frankly it takes too long to
>>crunch all the packets. I've also tried etherApe, but the analysis
>>makes my poor little laptop crawl. Are there any tools out there that
>>will speed this up? Possibly by looking at the firewall logs?
>>
>>
>>
>
>depends on what kind of firewall you have - there are scripts for
>various firewalls, providing you have some sort of accounting turned
>on. for your router you can do some basic accounting too. either
>using netflow or ip accouting. google for top talkers scripts for
>each
>
>/joshua
>
>
------------------------------
Message: 9
Date: Wed, 14 Jul 2004 10:44:26 -0700
From: "Michael Axelrod" <axelrod1 at comcast.net>
Subject: Re: [nsp] Suggestions on tracking down bandwidth offenders
To: "Tony Mucker" <Tony at tonymucker.com>, <cisco-nsp at puck.nether.net>
Message-ID: <003801c469ca$35b54940$d408020a at cybersourcent.com>
Content-Type: text/plain; charset="iso-8859-1"
I use netflow for a quick look at the top traffic consumers.
Statistics can be cleared - "clear ip flow stats" - and you can view the
stats flow by flow.
Just need to make sure that netflow is on the egress and ingress interfaces
to get bi-directional traffic stats.
Mike
----- Original Message -----
From: "Tony Mucker" <Tony at tonymucker.com>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 14, 2004 10:24 AM
Subject: [nsp] Suggestions on tracking down bandwidth offenders
> I've got a bandwidth problem (who doesn't). Something has been
> saturating my poor little T1 for 24 hours straight now. For those of
> you curious, here's what it looks like:
>
> http://www .ghideon.com/router-day.png
>
> Remove the white space and enjoy. In the past I've used ethereal dumps
> to figure out who the big talkers were, but frankly it takes too long to
> crunch all the packets. I've also tried etherApe, but the analysis
> makes my poor little laptop crawl. Are there any tools out there that
> will speed this up? Possibly by looking at the firewall logs?
>
> Thanks
> Tony
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
------------------------------
Message: 10
Date: Wed, 14 Jul 2004 21:01:27 +0200
From: Hank Nussbacher <hank at mail.iucc.ac.il>
Subject: Re: [nsp] Suggestions on tracking down bandwidth offenders
To: "Michael Axelrod" <axelrod1 at comcast.net>, "Tony Mucker"
<Tony at tonymucker.com>, <cisco-nsp at puck.nether.net>
Message-ID: <5.1.0.14.2.20040714210031.00b11e00 at mail.iucc.ac.il>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 10:44 AM 14-07-04 -0700, Michael Axelrod wrote:
And that your router is *not* doing DCEF otherwise the 'sho ip cache flow'
data will just be flows the RSP is seeing.
-Hank
>I use netflow for a quick look at the top traffic consumers.
>Statistics can be cleared - "clear ip flow stats" - and you can view the
>stats flow by flow.
>Just need to make sure that netflow is on the egress and ingress interfaces
>to get bi-directional traffic stats.
>
>Mike
>----- Original Message -----
>From: "Tony Mucker" <Tony at tonymucker.com>
>To: <cisco-nsp at puck.nether.net>
>Sent: Wednesday, July 14, 2004 10:24 AM
>Subject: [nsp] Suggestions on tracking down bandwidth offenders
>
>
> > I've got a bandwidth problem (who doesn't). Something has been
> > saturating my poor little T1 for 24 hours straight now. For those of
> > you curious, here's what it looks like:
> >
> > http://www .ghideon.com/router-day.png
> >
> > Remove the white space and enjoy. In the past I've used ethereal dumps
> > to figure out who the big talkers were, but frankly it takes too long to
> > crunch all the packets. I've also tried etherApe, but the analysis
> > makes my poor little laptop crawl. Are there any tools out there that
> > will speed this up? Possibly by looking at the firewall logs?
> >
> > Thanks
> > Tony
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
------------------------------
_______________________________________________
cisco-nsp mailing list
cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
End of cisco-nsp Digest, Vol 20, Issue 38
*****************************************
More information about the cisco-nsp
mailing list