[c-nsp] Minimal IDS on Catalyst 6509 (Sup720)

[Drew Weaver]

	Does anyone know of any way to do some minimal IDS using the
base image on a Cat 6509 with a Sup 720?

	What I mean is, if more than X amount of port scans leave the
network, log that to a syslog host and then I can have the syslog host
E-Mail me, etc etc.

	I was looking at Snort but I'm not sure how good that works. All
I really want to do is look at the packets that are coming in and going
out of the switch and if its doing 'bad' things notify us.

I mainly just want to be able to detect rooted or hosts which are doing
things "they shouldn't" within a hosting environment.

Thanks,
-Drew

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rodney Dunn
Sent: Monday, June 26, 2006 10:27 AM
To: Joost greene
Cc: Gert Doering; David Freedman; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] tag-switching mtu question

On Mon, Jun 26, 2006 at 03:40:45PM +0300, Joost greene wrote:
> Let me try to summarize.
> 
> Basicly there were TCP MSS, IP MTU and Phsyical MTU and later on MPLS
MTU
> 
> TCP MSS will be used only by the TCP hosts(end-to-end), but can be
> configured for re-write.
> 
> IP MTU can be configured on an Interface and it will set the size of
the IP
> packet before it reaches the interfaces buffers

Not really. A packet comes in and will be put in a buffer. If after
a lookup it's determined that the "ip mtu" of the outbound interface
is less than the length is the ip portion of the packet then that
packet will be fragmented if the DF bit is not set. If the df bit is set
the packet is dropped and an ICMP response sent towards the source.

If the physical MTU is set low then the IP mtu is automatically adjusted
down.

> 
> Physical is the last stage, if the IP is set to something less than
> physical, frame will be caped at layer 2 ?

Not really capped. If it's above the physical mtu the packet is dropped.


> 
> MPLS MTU is because most of interface MTUs are 1500 and you need more
so you
> force it to receive more to be able to put the 1500 bytes packet into
an
> MPLS packet.

Transmit not receive.

> 
> Thanks alot
> 
> On 6/26/06, Gert Doering <gert at greenie.muc.de> wrote:
> >
> > Hi,
> >
> > On Mon, Jun 26, 2006 at 01:40:25PM +0300, Joost greene wrote:
> > > Is anyone willing to explain to me the diff. between IP MTU,
physical
> > MTU,
> > > MPLS MTU and MSS, i am confused.
> >
> > OK, I'll give it a try.
> >
> > All of this is "as it works inside Cisco", as this is nothing a
standard
> > would define, but how a multiprotocol router would handle things.
> >
> > "mtu" is what the "default" MTU for *all* sorts of packets going in
and
> > out, and (unless configured differently) is inherited for IP, IPv6,
MPSL,
> > etc.
> >
> > "IP MTU" is the maximum size of an IP packet sent out of that
interface.
> >
> > The distinction is relevant, because one could want larger packet
sizes
> > for MPLS (to be able to transport full-sized IP frames *inside* the
MPLS
> > packet), but only standard-sized IP packets (because there is
something
> > else in the same IP subnet that cannot handle larger IP packets).
> >
> > "MPLS MTU" -> maximum size for MPLS packets.
> >
> >
> > In an ideal world, one could configure all of these MTUs
independently,
> > and the driver would program the chipset to the "largest MTU
expected".
> >
> > In IOS, that's what happens (I think) if you set "MTU <nnn>".
> >
> > *Some* IOS trains had some confusion about usefulness of larger MTUs
> > (or whatever), and forbid setting "mtu 1530" on an FastE interface -
but
> > for MPLS, you *need* more, so "mpls mtu 1530" was allowed (larger
MPLS
> > MTU than Interface MTU).  Which doesn't make too much sense, so it
was
> > changed again for 12.2SB, as far as I understand - so you can now
> > configure
> > larger "mtu" values again, and all protocols will inherit that value
> > (but can manually be configured for smaller values).
> >
> >
> > Now, TCP MSS is related to IP MTU, but not directly so.  If you have
> > a network with links with different MTU, the sender usually cannot
know
> > this, and will send full-sized (1500 byte) packets.  The first
router
> > that wants to send this packet over a lower-MTU link needs to
fragment
> > it (expensive), or send back an "ICMP fragmentation required" packet
> > (if the sender has set the DF, don't fragment, bit) - so the sender
> > can reduce his packet size.
> >
> > In the time of broken load balancers, or broken firewall admins that
> > filter out all ICMP packets (ICMP IS EVIL!!!), the sending host
might
> > never hear the ICMP "fragmentation required" packet, and thus will
re-send
> > his 1500 byte packet again and again, which has no chance to ever
reach
> > the receiver (path mtu discovery -> blackholing).
> >
> >
> > TCP has a mechanism by which the receiver can advertise how large a
TCP
> > packet ("TCP segment", actually) he can handle - the TCP MSS value
in the
> > TCP header.  So if the receiver knows that the MTU needs to be
smaller,
> > he can advertise a smaller TCP MSS size, and thus make the sender
send
> > out smaller TCP packets.
> >
> > Inside IOS (and other routers), there is a hack, where you can make
the
> > router change the TCP MSS for packets going *through* the router.
So if
> > you know that your DSL customers (for example) have issues with PMTU
> > discovery, you can just configure your router to re-write your
customer's
> > TCP MSS's, and thus work around MTU/fragmentation problems.
> >
> >
> > All of this sucks big time :-)
> >
> > (... and I'm sure that some part of the information above will be
> > incomplete,
> > incorrect, or just plain confusing.  Please correct the obvious,
there's
> > just not enough time to research all of this in even deeper detail
now).
> >
> > gert
> > --
> > USENET is *not* the non-clickable part of WWW!
> >
> > //www.muc.de/~gert/
> > Gert Doering - Munich, Germany
> > gert at greenie.muc.de
> > fax: +49-89-35655025
> > gert at net.informatik.tu-muenchen.de
> >
> _______________________________________________
> 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/