[c-nsp] How to prevent https facebook from the cisco router 1841
Pablo Lucena
plucena at coopergeneral.com
Thu Nov 14 10:40:53 EST 2013
You can do something like this on a 1841:
class-map match-any BLOCKED-WEBSITES
match access-group name BLOCKED-WEBSITES-ACL
match protocol http host "*facebook*"
policy-map BLOCK_WEB
class BLOCKED-WEBSITES
drop
int f0/0
service-policy input BLOCK_WEB
The ACL can also be used to match on specific IPs...you can do a nslookup
on facebook.com and get the list of addresses that resolved. This can
change though (as you know facebook has MANY addresses).
Another fault with this is that it only matches on HTTP. If the user uses
HTTPS then they can get through.
A better option would be using OpenDNS (free!). You can block specific web
pages, or entire categories of web pages. Then on your router you can set
up filtering of outbound DNS traffic to any other DNS server besides the
OpenDNS ones (to stop smart users that figure out that by changing their
DNS server they can bypass the block).
Pablo
On Thu, Nov 14, 2013 at 10:02 AM, <cisco-nsp-request at puck.nether.net> wrote:
> 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. [IOS XR] export to default-vrf (Catalin Petrescu)
> 2. Re: [IOS XR] export to default-vrf (Oliver Boehmer (oboehmer))
> 3. Re: 7600 10GE card recommendations (1 & 2 port cards)
> (James Bensley)
> 4. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
> 5. Re: Effect of simultaneous TCP sessions on bandwidth (Tom Storey)
> 6. Re: How to prevent https facebook from the cisco router 1841
> (A.L.M.Buxey at lboro.ac.uk)
> 7. Re: How to prevent https facebook from the cisco router 1841
> (Doug McIntyre)
> 8. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
> 9. Re: nexus-switche issues no arp-requests (Oswald, Thomas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Nov 2013 10:36:45 +0200
> From: Catalin Petrescu <cpmarvin at gmail.com>
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] [IOS XR] export to default-vrf
> Message-ID:
> <CAP=_-
> 9Nqqp9XVsxZw_dbFJ9UGF_b0Uxjr7Vtc9bonRu_dxRdfw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi all,
>
> Did anyone get this to work on XR 4.3.2.
>
> vrf TEST
> address-family ipv4 unicast
> export to default-vrf route-policy default_policy_pass_all
>
> route-policy default_policy_pass_all
> pass
> end-policy
>
> router bgp
>
> vrf TEST
> rd 1:1
> address-family ipv4 unicast
> redistribute connected metric 10
> redistribute static metric 10
>
> RP/0/RSP1/CPU0:#sh route vrf TEST
> ....
> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> 17:54:43
>
> RP/0/RSP1/CPU0:#sh route 99.99.99.1
> Thu Nov 14 03:34:31.038 EET
>
> % Network not in table
>
> the goal is to get routers ( 99.99.99.1/32) from vrf TEST in grt (
> defaul-vrf) .
>
> Thx,
>
> Catalin Petrescu
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 14 Nov 2013 09:07:36 +0000
> From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> To: Catalin Petrescu <cpmarvin at gmail.com>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> Message-ID: <CEAA5035.6F35C%oboehmer at cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> >Hi all,
> >
> >Did anyone get this to work on XR 4.3.2.
> >
> >vrf TEST
> > address-family ipv4 unicast
> > export to default-vrf route-policy default_policy_pass_all
> >
> >route-policy default_policy_pass_all
> > pass
> >end-policy
> >
> >[...]
> >RP/0/RSP1/CPU0:#sh route vrf TEST
> >....
> >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> >17:54:43
>
> is this an iBGP or an eBGP vrf route you are trying to export? Only
> external or locally originated routes are candidates to be exported from a
> VRF (anywhere, wether in global or into a different VRF), you need to do
> this on the originating PE. This rule is there to avoid loops, similar to
> standard BGP advertisement rule of only sending iBGP paths to external or
> RR-client peers.
>
> oli
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 14 Nov 2013 09:42:05 +0000
> From: James Bensley <jwbensley at gmail.com>
> To: Nick Hilliard <nick at foobar.org>, "cisco-nsp at puck.nether.net"
> <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] 7600 10GE card recommendations (1 & 2 port cards)
> Message-ID:
> <
> CAAWx_pXWiOrGM-1TLCjgj_Zjb6UncFs2ei_BjrUQJCH+A1KKBg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Nick,
>
> Many thanks for the info, that is very useful :)
>
> I shall continue to research and include the Ws-X7604-10GE.
>
> Kind regards,
> James.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 14 Nov 2013 13:57:39 +0200
> From: Catalin Petrescu <cpmarvin at gmail.com>
> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> Message-ID:
> <CAP=_-
> 9P+gCn+HZYpJ3fLaP8tuEf8e+5VvaedDGvQUQk+Ovo-UA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> hi Oliver,
>
> In this case it's a iBGP route but i've tested with connected static and
> ospf and it's the same.
>
> vrf RO_CASA
> address-family ipv4 unicast
> import route-target
> 1:1
> !
> export to default-vrf route-policy default_policy_pass_all
> export route-target
> 1:1
> !
>
> RP/0/RSP1/CPU0:#sh route vrf TEST
> .....
> C 10.10.100.0/24 is directly connected, 21:18:10, BVI1
> L 10.10.100.200/32 is directly connected, 21:18:10, BVI1
> C 10.200.200.0/24 is directly connected, 00:01:40, TenGigE0/0/1/3.200
> L 10.200.200.1/32 is directly connected, 00:01:40, TenGigE0/0/1/3.200
> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> 21:15:11
> L 192.168.1.1/32 is directly connected, 21:18:10, Loopback100
> O 200.200.200.200/32 [110/2] via 10.200.200.200, 00:01:32,
> TenGigE0/0/1/3.200
>
> RP/0/RSP1/CPU0:# sh route 10.10.100.0
> Thu Nov 14 06:54:56.034 EET
>
> % Network not in table
>
> RP/0/RSP1/CPU0:#sh route 200.200.200.200
> Thu Nov 14 06:55:02.156 EET
>
> % Network not in table
>
> Thx,
>
> Catalin
>
>
>
> On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
> oboehmer at cisco.com> wrote:
>
> >
> > >Hi all,
> > >
> > >Did anyone get this to work on XR 4.3.2.
> > >
> > >vrf TEST
> > > address-family ipv4 unicast
> > > export to default-vrf route-policy default_policy_pass_all
> > >
> > >route-policy default_policy_pass_all
> > > pass
> > >end-policy
> > >
> > >[...]
> > >RP/0/RSP1/CPU0:#sh route vrf TEST
> > >....
> > >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > >17:54:43
> >
> > is this an iBGP or an eBGP vrf route you are trying to export? Only
> > external or locally originated routes are candidates to be exported from
> a
> > VRF (anywhere, wether in global or into a different VRF), you need to do
> > this on the originating PE. This rule is there to avoid loops, similar to
> > standard BGP advertisement rule of only sending iBGP paths to external or
> > RR-client peers.
> >
> > oli
> >
> >
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 Nov 2013 13:08:45 +0000
> From: Tom Storey <tom at snnap.net>
> To: Youssef Bengelloun-Zahr <youssef at 720.fr>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth
> Message-ID:
> <
> CAFDgZgUmqKSCMQjQ0w_uXUbyg4UTTV42vpdLx+uh2HC9JyLeNg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> So if I understand this correctly, with two tests running, each test
> only manages about 50% of the bandwidth of the link?
>
> Are these tests sending data in only one direction, or both?
>
> If they are sending data in both directions, would it not make sense
> that each can only use about half the link? A sends ~50% to B which is
> repeated back to A, and C sends ~50% to D which is repeated back to C.
> That makes about 100% utilisation each way?
>
> Maybe I missed something...
>
> On 10 November 2013 21:26, Youssef Bengelloun-Zahr <youssef at 720.fr> wrote:
> >
> >
> > Le 11 nov. 2013 ? 04:22, Randy <randy_94108 at yahoo.com> a ?crit :
> >
> >>
> >>
> >>>>> - TCP traffic hits some kind of limit and isn't able to achieve
> more
> >>>>> than 40-60 Mbits/s in average <=== That's the problem we are
> facing
> >>
> >> what happens if you do this -
> >>
> >>
> >> a transfer from host A(fra) to host B(ham) and another transfer at the
> same time from host D(ham) to host C(fra)? Do still avg at 90M for each
> transfer or do both drop to the 40M avg? If you pull off 90M it would
> eliminate the link. If not; since you have enabled high performance
> options, tcp timestamping used to calculate RTT perceives congenstion(with
> the increase of traffic across link) and initiates slowstart.
> >
> > Hello,
> >
> > Funny you mention this :
> >
> > a- first, we start transfer from A (FRA) to B (HAM), we achieve BW close
> to 90 mbits/s,
> >
> > b- second, we start transfer from B to A (while first transfer is
> running) and BW for first transfer collapses.
> >
> >
> >>
> >> if what you are seeing only applies for simultanours transfers:
> >>
> >> A To B and B to A, It would seem to imply A and B are the bottlenecks.
> >
> > Hello, seems very unlikely to me :
> >
> > - At location A, we have a Brocade CER-RT acting as a PE delivering
> Layer 2 service to the customer.
> >
> > Customer server is directly connected using a GigE port.
> >
> > - At location B, we have some kind of Alcatel CPE provided by LL
> provider.
> >
> > Customer server is directly connected using a FE port.
> >
> > Thanks.
> >
> >
> >
> >>
> >> hth,
> >> ./Randy
> >>
> >
> > _______________________________________________
> > 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: 6
> Date: Thu, 14 Nov 2013 13:43:33 +0000
> From: A.L.M.Buxey at lboro.ac.uk
> To: mohamed nagy <eng.mohamednagy at gmail.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] How to prevent https facebook from the cisco
> router 1841
> Message-ID: <20131114134333.GB9160 at lboro.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> > i need to prevent users to open Facebook https traffic from my router
> cisco
> > 1841
>
> you will need to invest in other technology that can achieve this...and
> wonder
> why you dont get the best people working for your company. blocking
> facebook isnt
> a technical issue...its a human resource issue. if your company doesnt
> want users
> accessing facebook from your network (at which point they'll use the
> 3G/4G/etc with
> their own devices) then they need to know this and management need to deal
> with it.
> ensure proper disciplinary proceedings for anyone caught doing facebook on
> company
> time and then the problem will be solved.....(but see my point about the
> sort of
> people who will work there).
>
> alan
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 14 Nov 2013 08:05:37 -0600
> From: Doug McIntyre <merlyn at geeks.org>
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] How to prevent https facebook from the cisco
> router 1841
> Message-ID: <20131114140537.GA45235 at geeks.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Nov 14, 2013 at 01:43:33PM +0000, A.L.M.Buxey at lboro.ac.uk wrote:
> > > i need to prevent users to open Facebook https traffic from my router
> cisco
> > > 1841
> >
> > you will need to invest in other technology that can achieve this...
>
>
> I agree about the technology part. Run a box built to do this sort of
> thing. I wouldn't think of using any low-end router to do firewall
> functions any longer, dedicated hardware firewalls are a fraction of
> the price of router hardware, and can handle infinately more bandwidth
> and features. I could block facebook (or just about any "internet app")
> for an internal user in about 15 seconds of setup on my FortiNet
> firewall that my users are behind.
>
> > .. blocking facebook isnt a technical issue...its a human resource
> > issue. if your company doesnt want users accessing facebook from
> > your network (at which point they'll use the 3G/4G/etc with their
> > own devices) ..
>
>
> If they have a 1841 router, it is probably a smaller company, and they
> probably don't have the resources to police their users like a larger
> company. A technology solution is easier.
>
> But it is a whole different thing to check sites on your phone
> bypassing work restrictions, vs. on the desktop. On the desktop, it
> is hard for a manager to see if the user is doing legit work functions
> or not, but always fondling their phone is totally different looking
> to the manager.
>
> If you need to just train the employee not to do the improper steps,
> and putting in technology blocks is easier than standing over them
> school teacher style to make sure they are working the full work day.
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 14 Nov 2013 16:34:08 +0200
> From: Catalin Petrescu <cpmarvin at gmail.com>
> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
> Message-ID:
> <CAP=_-
> 9N2HmXNHqruj+tDHOx4TMWUbAAmAXRZL+wsijmmJpk5Lg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Thx Oliver .
>
> router bgp xx
> address-family ipv4 unicast << this was missing
>
> vrf TEST
> address-family ipv4 unicast
> redistribute connected metric 10
> redistribute static metric 10
>
> as the leak route is know via bgp ( in default vrf) and not
> connected/static ( as in vrf )
>
> Regards,
> Catalin
>
>
> On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
> oboehmer at cisco.com> wrote:
>
> >
> > >Hi all,
> > >
> > >Did anyone get this to work on XR 4.3.2.
> > >
> > >vrf TEST
> > > address-family ipv4 unicast
> > > export to default-vrf route-policy default_policy_pass_all
> > >
> > >route-policy default_policy_pass_all
> > > pass
> > >end-policy
> > >
> > >[...]
> > >RP/0/RSP1/CPU0:#sh route vrf TEST
> > >....
> > >B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
> > >17:54:43
> >
> > is this an iBGP or an eBGP vrf route you are trying to export? Only
> > external or locally originated routes are candidates to be exported from
> a
> > VRF (anywhere, wether in global or into a different VRF), you need to do
> > this on the originating PE. This rule is there to avoid loops, similar to
> > standard BGP advertisement rule of only sending iBGP paths to external or
> > RR-client peers.
> >
> > oli
> >
> >
>
>
> ------------------------------
>
> Message: 9
> Date: Thu, 14 Nov 2013 16:02:38 +0100
> From: "Oswald, Thomas" <th.oswald at telekom.de>
> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] nexus-switche issues no arp-requests
> Message-ID:
>
> <D9F50A0C85164A44B0202D32455750A2041FC0D547 at QEO40075.de.t-online.corp>
> Content-Type: text/plain; charset="iso-8859-1"
>
> fuck! The faulty behavior disappears. Just rebooting the nexus-switch. Two
> days to view a lots of logg-messages, error discovery, tests... For what?
> For nothing. And now I'm not absolutely sure that the fault will not raise
> up again. That does not inspire me with confidence.
>
>
>
> ^^?-?^^
>
> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von
> Oswald, Thomas
> Gesendet: Dienstag, 12. November 2013 17:42
> An: cisco-nsp at puck.nether.net
> Betreff: [c-nsp] nexus-switche issues no arp-requests
>
> Hallo all,
>
> I see a very strange behavior on my two nexus switches.
>
> Both are Nexus 5548 with L3-daughter-cards. Both do l2 and l3-switching,
> ACL-filtering and other things. Furthermore I have a set of servers
> connected to both switches in a vPC-setup. All in all I do nothing special.
>
> After reloading the primary switch (vpc-primary, root-bridge for all vlans
> and hsrp-active with preemption for all SVIs) the switche comes back online
> and after getting up all links and reconverging everthing the network
> breaks. After a lot of debugging and curses and connection tries and a few
> additional gray hairs later I have got it to work by pinging all
> ip-addresses from the switch that I have previously rebooted.
>
> Later I do some tests to find out what was going wrong. I found out that
> if I clear the arp-cache I will get the same issue. Pinging from server A
> in one subnet to server B in another subnet doesn't lead to success,
> because the switch issues no arp-requests. To make it work just ping server
> B from the switch and all works fine. The switch does arp, the arp-table is
> updated and the pings from the server A will reach the server B.
>
> Any ideas?
>
> Regards
> Thomas
> ^^?-?^^
>
>
> _______________________________________________
> 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/
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> cisco-nsp mailing list
> cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
>
> ------------------------------
>
> End of cisco-nsp Digest, Vol 132, Issue 44
> ******************************************
>
--
More information about the cisco-nsp
mailing list