Re: [c-nsp] cisco ACL filter outbound only
ooops. extablished is of course a type and should be established. Basically that means the ACK bit is set. -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision. >-Original Message- >From: Keith Medcalf >Sent: Wednesday, 16 September, 2020 04:39 >To: 'cisco-nsp@puck.nether.net' >Subject: RE: [c-nsp] cisco ACL filter outbound only > > >Actually standard packet filtering is supported by all Cisco products, >and most others as well. Packet filters do not do state tracking. The >packet filters you want will only work for TCP. You need to block >everything else. > >outbound on the interface to "the rest of the universe": >permit tcp any >deny ip any >... whatever other shit you want to permit to go out ... > >inbound on the interface from "the rest of the universe": >permit tcp any extablished >deny ip any >... whatever other shit you want to permit to go in ... > >Cisco (and others) have worked this way for about 40 years. > >-- >Be decisive. Make a decision, right or wrong. The road of life is paved >with flat squirrels who could not make a decision. > >>-Original Message- >>From: cisco-nsp On Behalf Of Emille >>Blanc >>Sent: Tuesday, 15 September, 2020 10:20 >>To: Mike ; cisco-nsp@puck.nether.net >>Subject: Re: [c-nsp] cisco ACL filter outbound only >> >>> Again, the cli seems to indicate support for all the things >>> necessary, which includes the idea of 'established', which is why I >ask >>> if THIS platform does in fact do what the cli suggests: >> >>No, the ASR920 (Unless it's hiding in a recent IOS release), does not do >>any kind of state tracking. You'll be better served looking at the ISR >>or Firewall families for that. >> >>What you're seeing in the CLI is pretty commonplace these days - to be >>fair, not just with Cisco - where an un-supported feature is 'left in' >>the command line. >> >>If in doubt, try it. Worst case it won't work, and then you can bounce >>the config off TAC to get one of their "unsupported configuration" >canned >>responses. :] >> >>From: cisco-nsp on behalf of Mike >> >>Sent: Tuesday, September 15, 2020 8:52 AM >>To: cisco-nsp@puck.nether.net >>Subject: Re: [c-nsp] cisco ACL filter outbound only >> >>On 9/15/20 8:08 AM, Brian Turnbow wrote: >>>> It just seems to me that it is indeed possible using the above to put >>it >>>> together. Is this all just non-working on this platform? >>>> >>> The difference is in connection state. >>> An ACL does not track it so you can do >>> Permit tcp any any established >>> Inbound or outbound on a port , but that will only check that the ip >>packet has ack or rst set for the tcp session . >>> I can still send you an inbound tcp packet with ack or rst set even >if >>it did not originate from "inside" and pass your filter. >>> It will also not help in any way for udp etc >>> The ACL does not know that a first packet was sent out so it should >>await a response >>> This is why you need a firewall be it on the router or external. >>> >>Hi, >> >>Again, the cli seems to indicate support for all the things >>necessary, which includes the idea of 'established', which is why I ask >>if THIS platform does in fact do what the cli suggests: >> >>rvhs-asr920(config-ext-nacl)#permit tcp 0.0.0.0 0.0.0.0 any ? >> ack Match on the ACK bit >> dscp Match packets with given dscp value >> eq Match only packets on a given port number >> established Match established connections >> fin Match on the FIN bit >> fragmentsCheck non-initial fragments >> gt Match only packets with a greater port number >> log Log matches against this entry >> log-inputLog matches against this entry, including input interface >> lt Match only packets with a lower port number >> match-allMatch if all specified flags are present >> match-anyMatch if any specified flag is present >> neq Match only packets not on a given port number >> option Match packets with given IP Options value >> precedence Match packets with given precedence value >> psh Match on the PSH bit >> rangeMatch only packets in the range of port numbers >> rst Match on the RST bit >> syn Match on the
Re: [c-nsp] cisco ACL filter outbound only
Actually standard packet filtering is supported by all Cisco products, and most others as well. Packet filters do not do state tracking. The packet filters you want will only work for TCP. You need to block everything else. outbound on the interface to "the rest of the universe": permit tcp any deny ip any ... whatever other shit you want to permit to go out ... inbound on the interface from "the rest of the universe": permit tcp any extablished deny ip any ... whatever other shit you want to permit to go in ... Cisco (and others) have worked this way for about 40 years. -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision. >-Original Message- >From: cisco-nsp On Behalf Of Emille >Blanc >Sent: Tuesday, 15 September, 2020 10:20 >To: Mike ; cisco-nsp@puck.nether.net >Subject: Re: [c-nsp] cisco ACL filter outbound only > >> Again, the cli seems to indicate support for all the things >> necessary, which includes the idea of 'established', which is why I ask >> if THIS platform does in fact do what the cli suggests: > >No, the ASR920 (Unless it's hiding in a recent IOS release), does not do >any kind of state tracking. You'll be better served looking at the ISR >or Firewall families for that. > >What you're seeing in the CLI is pretty commonplace these days - to be >fair, not just with Cisco - where an un-supported feature is 'left in' >the command line. > >If in doubt, try it. Worst case it won't work, and then you can bounce >the config off TAC to get one of their "unsupported configuration" canned >responses. :] > >From: cisco-nsp on behalf of Mike > >Sent: Tuesday, September 15, 2020 8:52 AM >To: cisco-nsp@puck.nether.net >Subject: Re: [c-nsp] cisco ACL filter outbound only > >On 9/15/20 8:08 AM, Brian Turnbow wrote: >>> It just seems to me that it is indeed possible using the above to put >it >>> together. Is this all just non-working on this platform? >>> >> The difference is in connection state. >> An ACL does not track it so you can do >> Permit tcp any any established >> Inbound or outbound on a port , but that will only check that the ip >packet has ack or rst set for the tcp session . >> I can still send you an inbound tcp packet with ack or rst set even if >it did not originate from "inside" and pass your filter. >> It will also not help in any way for udp etc >> The ACL does not know that a first packet was sent out so it should >await a response >> This is why you need a firewall be it on the router or external. >> >Hi, > >Again, the cli seems to indicate support for all the things >necessary, which includes the idea of 'established', which is why I ask >if THIS platform does in fact do what the cli suggests: > >rvhs-asr920(config-ext-nacl)#permit tcp 0.0.0.0 0.0.0.0 any ? > ack Match on the ACK bit > dscp Match packets with given dscp value > eq Match only packets on a given port number > established Match established connections > fin Match on the FIN bit > fragmentsCheck non-initial fragments > gt Match only packets with a greater port number > log Log matches against this entry > log-inputLog matches against this entry, including input interface > lt Match only packets with a lower port number > match-allMatch if all specified flags are present > match-anyMatch if any specified flag is present > neq Match only packets not on a given port number > option Match packets with given IP Options value > precedence Match packets with given precedence value > psh Match on the PSH bit > rangeMatch only packets in the range of port numbers > rst Match on the RST bit > syn Match on the SYN bit > time-range Specify a time-range > tos Match packets with given TOS value > ttl Match packets with given TTL value > urg Match on the URG bit > > >___ >cisco-nsp mailing list cisco-nsp@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Campus Network - Deployment mode of Perimeter Firewalls
What is the difference? Does not the "campus network" provide a service? -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision. >-Original Message- >From: cisco-nsp On Behalf Of Nick >Hilliard >Sent: Tuesday, 11 August, 2020 03:34 >To: Yham >Cc: cisco-nsp@puck.nether.net NSP >Subject: Re: [c-nsp] Campus Network - Deployment mode of Perimeter >Firewalls > >Yham wrote on 11/08/2020 04:33: >> Thanks for your comments. I kinda agree with you on avoid using >> transparent mode however not clear why you wouldn't want your >> north-south traffic pass through perimeter security devices (FWs). how >> would you protect your network from outside if you don't have firewalls >> in the traffic path? I have seen some enterprises use by-pass switches >> to go around the firewalls in case of an unexpected failure from where >> firewalls can't recover. > >I missed that this was a campus network, and assumed it was a service >provider. > >Yeah, politically credible reasons for wanting some or all parts of a >campus behind firewalls of whatever form. It's a completely terrible >idea if you're a service provider though. > >Nick > >___ >cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Campus Network - Deployment mode of Perimeter Firewalls
Not to mention the obvious observation that a firewall designed to "fail open" must not have anything of any importance behind it, so it (the firewall) merely exists for "checkbox compliance" with the checklists of incompetent arseholes and clueless retards, and not because it serves (or is intended to serve) any useful purpose. -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision. >-Original Message- >From: cisco-nsp On Behalf Of Gert >Doering >Sent: Tuesday, 11 August, 2020 01:18 >To: Yham >Cc: cisco-nsp@puck.nether.net NSP >Subject: Re: [c-nsp] Campus Network - Deployment mode of Perimeter >Firewalls > >Hi, > >On Mon, Aug 10, 2020 at 11:33:06PM -0400, Yham wrote: >> Thanks for your comments. I kinda agree with you on avoid using >transparent >> mode however not clear why you wouldn't want your north-south traffic >pass >> through perimeter security devices (FWs). how would you protect your >> network from outside if you don't have firewalls in the traffic path? I >> have seen some enterprises use by-pass switches to go around the >firewalls >> in case of an unexpected failure from where firewalls can't recover. > >What is the point of a firewall in front of a web server? > >The web server should not have any services running besides "web", and >these have to be available from the outside. > >Adding a firewall means "you put a device in front of it that can handle >less load and costs more" - but where's the security gain? > >gert > >-- >"If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never >doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh >Mistress > >Gert Doering - Munich, Germany >g...@greenie.muc.de ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] big uptime - what you got ?
On Monday, 10 February, 2020 14:10, Tom Hill wrote: >On 10/02/2020 21:01, Keith Medcalf wrote: >> How about you just say in English what it is you want to say instead >> of wasting everyone's time? > "Click the fucking link and find out" ? > (Protip: never ask a Brit to be explicit.) >> Page does not exist, and I do not do tinyurl or bitly or any of that >> sort of obfuscation crap. > If you've decided to obfuscate HTTP 302 responses from your life, I'm > not sure I can really help you navigate Cisco's security tools anyway. Seems pretty straightforward to me. You posted a link. It was broken. Case closed. > Suffice it to say, there are a heap of critical and/or high-level > security vulnerabilities listed for the Cisco IOS version referenced by > the OP (12.2(31)SGA1). Eschewing those recommendations in favour of > dick-waving over high uptimes is an industry practice that we should > really have killed-off by now. Just because *you* or some other person thinks there are *critical* security vulnerabilities does not mean that those vulnerabilities are exploitable in any particular instance of the installation of that hardware or software. Just because "A" is a vulnerability does not mean that one needs to "fix or upgrade" anything if "A" is already mitigated. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] big uptime - what you got ?
On Monday, 10 February, 2020 11:15, Tom Hill wrote: >On 10/02/2020 15:48, Aaron Gould wrote: >> Dude it's bridging eth frames just fine, why would i >I can TOTALLY find half a dozen reasons in here, braaa: >https://tinyurl.com/uu3dmyb (https://tools.cisco.com/security ... ) Page does not exist, and I do not do tinyurl or bitly or any of that sort of obfuscation crap. How about you just say in English what it is you want to say instead of wasting everyone's time? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
