<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: PIX vs IOS in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175005#M698480</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Oleg,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Very insightful comments but I do have to disagree with one point.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.  I would not say that because up to 1% of internet traffic is fragmented that IP fragmentation is common.  Especially when you say that 22% of all fragmentation is caused by tunneling.  Fragmentation in tunneling can easily be overcome by adjusting the workstation maximum MTU sizes.  So that just leaves a maximum of 0.78% of internet traffic.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you are saying that by blocking ICMP path MTU discovery packets, you must allow IP fragments then that is interesting.  I really never thought of it that way.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I subscribe to the theory that it is better to block fragments and protect yourself against rather simplisitc IP fragmentation DoS attacks than it is to allow them.  &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I 100% agree about the IOS being fail-open and the PIX being fail-closed and from a security point of view the hardware firewall is always the best option.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kevin&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 28 Aug 2003 06:47:10 GMT</pubDate>
    <dc:creator>kevin-reynolds</dc:creator>
    <dc:date>2003-08-28T06:47:10Z</dc:date>
    <item>
      <title>PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175000#M698467</link>
      <description>&lt;P&gt;I am attempting to find some type of chart that compares the features and limitations of installing a IOS based firewall compared to an actual PIX.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have searched the Cisco web site, and have come up empty.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks in advance.&lt;/P&gt;</description>
      <pubDate>Fri, 21 Feb 2020 06:56:45 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175000#M698467</guid>
      <dc:creator>bw3481</dc:creator>
      <dc:date>2020-02-21T06:56:45Z</dc:date>
    </item>
    <item>
      <title>Re: PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175001#M698470</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;If the primary purpose of the device is security, use a firewall. If the primary purpose is routing, use a router. Not to be a smartass, that's just the best way to make that decision.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Maybe the reason they don't post a side-by-side comparision is because each router is different and some PIXen also have different features. It's sort of apples and oranges. Since this is a broad subject, you will problably be best served making up your own product matrix and then checking off the features you want.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;IOS Firewall will suck up CPU cycles on a router. PIX is much faster and easier to work and play with. It's also usually cheaper than using a router as a firewall.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you post an idea of how your network is set up and what you want to achieve with the device, I'll bet people will post some more specific info. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 22 Aug 2003 03:19:43 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175001#M698470</guid>
      <dc:creator>r-lemaster</dc:creator>
      <dc:date>2003-08-22T03:19:43Z</dc:date>
    </item>
    <item>
      <title>Re: PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175002#M698472</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Strictly speaking IOS firewall is not a firewall at all. All you need to do to evade application-layer inspection is just fragment your traffic. This will probably never be changed as 1) routers should pass all traffic, even fragmented, 2) Routers' CPUs are usually very slow -- they cannot do virtual reassembly. So, in a long term PIX is a better solution, but it has lots of its own problems.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So, use both &lt;span class="lia-unicode-emoji" title=":winking_face:"&gt;😉&lt;/span&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Oleg Tipisov,&lt;/P&gt;&lt;P&gt;REDCENTER,&lt;/P&gt;&lt;P&gt;Moscow&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Aug 2003 12:36:49 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175002#M698472</guid>
      <dc:creator>ovt</dc:creator>
      <dc:date>2003-08-27T12:36:49Z</dc:date>
    </item>
    <item>
      <title>Re: PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175003#M698474</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Oleg,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I agree with your comments that both should be used, but I wonder why you would not block IP fragments via the use of an ACL?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kevin&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Aug 2003 13:06:25 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175003#M698474</guid>
      <dc:creator>kevin-reynolds</dc:creator>
      <dc:date>2003-08-27T13:06:25Z</dc:date>
    </item>
    <item>
      <title>Re: PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175004#M698478</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Kevin,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1. Up to 1% of Internet packets are fragmented:&lt;/P&gt;&lt;P&gt;8% - reverse order; 0.1% with duplicates or overlapping. Of this 1%: 52% - MS Media Player, 22% -tunneling (source - CAIDA, or like that).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;2. PMTUD sometimes doesn't work as ICMP is blocked somewhere.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;3. PMTUD is not implemented for UDP by M$ (so far as I know).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So, fragmentation is common and normal thing.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Routers SHOULD pass fragments, firewalls MAY not and usually you cannot block *all* fragments with "a-l 100 deny ip any any fragments". You *probably* can block fragments for *specific* protocols that are application-layer-inspected by the IOS firewall (say, SMTP, for SMTP Mail Guard to work), but this is not an easy thing. For example:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;permit tcp any host myserver eq 25&lt;/P&gt;&lt;P&gt;deny ip any host myserver fragments&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;will probably work, but I'm not sure. At least it should be carefully tested.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Most PIX firewall fixups block all fragments of the respective application protocol by default (there are exceptions though - ftp without "strict" keyword, SIP until recently, etc. - they are open for various vulnerabilities).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So, in general, PIX (arguably) do the right thing with fragments. And it is much easyer to configure. I would say that the IOS firewall is "fail-open" and the PIX is "fail-closed" by default regarding the fragments and application-layer inspection, where "fail-open" means "pass the packet if unable to analyze it" and "fail-closed" means "drop it".&lt;/P&gt;&lt;P&gt;This basically means that the IOS firewall is not a firewall at all.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;This is just my opinion.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Oleg Tipisov,&lt;/P&gt;&lt;P&gt;CCSI,&lt;/P&gt;&lt;P&gt;REDCENTER,&lt;/P&gt;&lt;P&gt;Moscow&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 27 Aug 2003 15:57:31 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175004#M698478</guid>
      <dc:creator>ovt</dc:creator>
      <dc:date>2003-08-27T15:57:31Z</dc:date>
    </item>
    <item>
      <title>Re: PIX vs IOS</title>
      <link>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175005#M698480</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Oleg,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Very insightful comments but I do have to disagree with one point.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1.  I would not say that because up to 1% of internet traffic is fragmented that IP fragmentation is common.  Especially when you say that 22% of all fragmentation is caused by tunneling.  Fragmentation in tunneling can easily be overcome by adjusting the workstation maximum MTU sizes.  So that just leaves a maximum of 0.78% of internet traffic.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you are saying that by blocking ICMP path MTU discovery packets, you must allow IP fragments then that is interesting.  I really never thought of it that way.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I subscribe to the theory that it is better to block fragments and protect yourself against rather simplisitc IP fragmentation DoS attacks than it is to allow them.  &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I 100% agree about the IOS being fail-open and the PIX being fail-closed and from a security point of view the hardware firewall is always the best option.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kevin&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 28 Aug 2003 06:47:10 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/pix-vs-ios/m-p/175005#M698480</guid>
      <dc:creator>kevin-reynolds</dc:creator>
      <dc:date>2003-08-28T06:47:10Z</dc:date>
    </item>
  </channel>
</rss>

