ACL's and fragmented packets

iamme4eva

Hi,

I've just read a throwaway line in the OCG that says that a disadvantage of static packet filtering is

Does not filter fragmented packets with the same accuracy as nonfragmented packets.

Can anyone expand on that and say why please?

Nick.

SecurityThroughObscurity

For a non-initial fragment that contains no layer 4 information, a layer 4 ace can still permit the packet.

iamme4eva

I think I see, thanks.

So it's because the TCP header is only in the first packet - the fragments will all have the same IP header, but only the first packet would have the TCP header which includes the port information?

So...

permit tcp host 10.1.1.1 host 20.2.2.2 eq www
deny ip any any

Something like this, for example, would allow the first packet of a fragmented series, but deny the rest of the stream as there is no L4 info in the packet?

Is that right?

MickQ

Exactly (first bit). The subsequent packets lack information that would be matched against in the ACL.

NetworkVeteran

permit tcp host 10.1.1.1 host 20.2.2.2 eq www
deny ip any any

Something like this, for example, would allow the first packet of a fragmented series, but deny the rest of the stream as there is no L4 info in the packet?

Nope! For non-fragmented packets or initial fragments, the above would only permit packets from 10.1.1.1=>20.2.2.2 with TCP destination port 80. However, for non-initial fragments it would permit all packets from 10.1.1.1=>20.2.2.2.

Cisco IOS can implement what you said above, but it would need to be done as follows--

deny ip host 10.1.1.1 host 20.2.2.2 fragments
permit tcp host 10.1.1.1 host 20.2.2.2 eq www
deny ip any any

iamme4eva

Thanks.

NV - Why would it fall back to permit for the traffic without the destination port then? That seems like odd behaviour.

I'm going to get some VM's and GNS3 fired up when I have the time and do this properly for myself...just to see what happens.

MickQ

I put it down to compatibility. You need to use the keyword "fragments".

It's the same with security loopholes in other systems. They can be secure, but users will want it made easier for them and thereby points of attack are made.

iamme4eva

So...would my example above only allow non-initial fragments between 10.1.1.1 -> 20.2.2.2, or would all non-initial fragments be allowed regardless of addresses?

Are you saying that the packet is still checked against the access list, and matches because it does match the source and end IP addresses, realises it's a fragment and thinks "that could be a continuation to something I've already allowed, so I'd best let it through"?

For example then...

10.1.1.1:1000 -> 20.2.2.2:80...all allowed.
10.1.1.1:1000 -> 20.2.2.2:81.....initial fragment denied, subsequent fragments pass.
10.2.2.2:1000 -> 4.4.4.4:81....all denied.

That sound about right?

MickQ

Pretty much from my limited experience of trying it.

iamme4eva

I've made a start on labbing it. I'm writing it up as I go on my blog...My Brain **** » MTU / Fragmentation / ACL Tests….Part 1

I haven't got as far as the access lists though, I've hit a few things happening that surprised me and have spend most of my time googling random side events like the overheads for HDLC etc.

That said, it's all good learning, and eventually I'll get as far as sticking the access-lists on and nailing down exactly what happens! I aim to try the three scenarios I said in my previous post. I just need to learn how to use Ostinato next, to generate some TCP traffic!

Cheers for your pointers guys!

MickQ

Speedbumps like that can be annoying but help so much with the learning

iamme4eva

10.1.1.1:1000 -> 20.2.2.2:80...all allowed.
10.1.1.1:1000 -> 20.2.2.2:81.....initial fragment denied, subsequent fragments pass.
10.2.2.2:1000 -> 4.4.4.4:81....all denied.

Just to close this thread off, I've finished labbing it and found it does act how I asked in my previous post. The entire thing is on my blog if anyone wants to read.

There's also a Cisco Whitepaper on it: Access Control Lists and IP Fragments - Cisco Systems