thanks for answering, however would you pls give me some more detail for the "crafted packet" ?

Any related website for reference ? thanks again.

Hi

Here is an article on crafted packets and firewalls.

http://www.securityfocus.com/infocus/1787

In essence packet crafting is all about manipulating data within the packet headers to try and probe/evade/penetrate security devices.

There are a number of freely available tools on the Internet that make crafting packets very easy.

HTH

Jon

>>A packet with a source port of 0 and a destination port of 0 looks like a crafted packet.

Could you tell me why you think a source port of 0 and a destination port of 0 looks like a crafted packet?

many thanks.

Hi

Two things wrong with it

1) There is no service listening on port 0 so the destination port is suspect. Standard services would be for example

tcp port 20/21 = ftp

tcp port 23 = telnet

tcp port 80 = http

but nothing listens on port 0.

2) The source port should never be 0. Generally speaking the source port is dynamically generated on the client and is > 1024.

eg

client = 192.168.1.5

web server = 172.16.1.5

When the client connects to the web server

source IP 192.168.1.5 source port 12010

destination IP 172.16.1.5 destination port 80.

Note port 12010 was chosen at random, as long as it is higher than 1024.

HTH

Jon

Thank you very much.

I do not believe that this is a crafted packet and that there is a simple explanation for the log message that you describe. Pretty obviously the access list used the log paremeter to report this traffic and the log parameter attempts to report the TCP or UDP port number involved. But if the access list has not examined port numbers then it can not report the port numbers and will report (0). If you can clarify the syntax of the access list used, I am confident that we will find that it does permit and deny by IP address but does not specify any checking of TCP or UDP port numbers.

HTH

Rick

here is my access list, just very simple:

interface Serial0

no ip address

ip access-group 115 in

ip access-group 115 out

no ip directed-broadcast

encapsulation frame-relay

!

interface Serial0.1 point-to-point

description connect to primary computer room

ip address 2xx.xxx.xxx.xxx 255.255.255.252

ip access-group 115 in

ip access-group 115 out

no ip directed-broadcast

frame-relay interface-dlci 205

!

interface Serial0.2 point-to-point

description connect to secondsry computer room

ip address 2xx.xxx.xxx.xxx 255.255.255.252

ip access-group 115 in

ip access-group 115 out

no ip directed-broadcast

access-list 115 permit ip any any log

Hi

I have just setup this in a lab and Rick is spot on in this case and it is something i wasn't aware of either. As he says it is because your access-list references ip and not tcp or udp.

Apologies for misleading you in this instance although a lot of what i wrote is still relevant in terms of crafted packets etc. but in this case it is most definitely not a crafted packet.

Thanks for the information Rick.

Jon

Jon

You are quite welcome. I find that this behavior of access lists is frequently not well understood. And much of what you wrote about crafted packets is quite correct, but not the issue in this instance.

HTH

Rick

I didnt realize this behaviour either. But what if i want to log the portnumber. If i for instance write a access-list:

permit tcp any any gt 0 log

permit udp any any gt 0 log

It will log tcp and udp allright. But it will potentially use alot of cpu and other protocols will use up lots of rows in the acl.

Any ideas?

Fredrik

You are correct that the access list that you wrote will log the port numbers for all TCP and all UDP traffic going through the interface(s) where the access list is assigned. And it will consume some CPU cycles to do it, and depending on how you have configured logging (to console? to logging buffer? to syslog servers?) it will consume more CPU cycles to send the log messages to their syslog destinations. How much CPU cycles will depend on how much traffic is going through the interface(s). So you must make a choice: does the port level information have enough value to be worth the overhead that it requires to get it?

I am not sure that other protocols will use lots of rows in the ACL. There is not much else that I know where you need to specify port numbers. So most people when they are doing an access list like this will add one more line of permit ip any any. This allows all IP traffic other than TCP and UDP to go through (probably without logging - unless there is some reason that you want to log ALL traffic through an interface).

HTH

Rick