cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
572
Views
0
Helpful
6
Replies

SIG1203: Getting 63.63.63.63 as both source and destination

ddinh
Level 1
Level 1

Has anyone experienced this type of alarm? I have anti-spoofing at the router.

OUT OUT 5 1203 63.63.63.63 63.63.63.63 (ports)0 0

OUT OUT 5 1203 63.63.63.63 128.38.0.80 (ports)0 0

Thanks for any responses.

6 Replies 6

brenden
Level 1
Level 1

We have also experienced those here too as well.

We have experienced this as well on the 1204 alarm.

This is pretty common on the 1204 alarm, but will occasionally also be seen on other 1200 series IP Fragment alarms.

This 63.63.63.63 address is being seen because the IP Fragmentation Reassembly is unable to completely reassemble the fragment, because of missing fragments or the alarm firing before all of the fragments have been received. We replace the incomplete data with ascii ? which equates to 63 decimal, hence the 63.63.63.63 IP address.

In the case of the 1204, the initial fragment is missing. The IP Fragmentation Reassembly code was coded to pull the ip address information from the first fragment, but since it hasn't seen the first fragment the ip address field still contains the ? entries and the address winds up being written as 63.63.63.63.

In the case of the 1203 alarm, the overwrite may be happening between two fragments before the first fragment is seen by the sensor.

One of our developers had this to say about a similar case awhile back:

They can correct this problem by allocating more buffer space for the reassembly engine. Have them try these settings:

ReassembleFragments On # Fragment Reassembly On/Off

ReassembleFragmentTimeout 60 # Seconds to wait for a completed Dgram

ReassembleMaxFragmentsPerDgram 1000

ReassembleMaxTotalFragments 40000

ReassembleMaxDgrams 2000

If your settings are less than above, then try increasing to the above values and see if the 63.63.63.63 address stops being seen.

NOTE1: The 1204 is usually indicative of the sensor not waiting long enough for all the fragments. Increasing your settings may help eliminate 1204s from being generated.

1204s could also happen if attackers are not sending the first fragment, or in some cases a user's settings on a router or firewall may not be permitting the first fragment, but allowing the other fragments.

NOTE2: The 1203 could also be caused by the the settings being too small; try increasing the settings to the above values.

If increasing the settings does not eliminate the 1203 then it is likely a genuine attack where the attacker is trying to evade the IDS system by having fragments over write the data in other fragments, or trying to cause system malfunctions in the machine being attacked.

I increased the settings and it did not eliminate the 1203. (Note: all settings were ok except for ReassembleMaxTotalFragments 40000 with the following error:

"Warning! nrConfigure could not parse the following line(s)

in /org1/host201/cfg/version.2/version.2.4/version.2.4.35/packetd.conf:

Reason: unrecognized token.

eventLevelOfCommandLogs 3

ReassembleMaxTotalFragments 40000"

You mentioned that this would likely be a genuine attack. If this is the case, then how would I mitigate this attack without the true source or destination ip addresses?

"eventLevelOfCommandLogs 3" may be a misspelling. It should be:

EventLevelOfCommandLogs 3 with a an upper case E.

The "ReassembleMaxTotalFragments 40000" is OK. nrConfigure just may not know about the token. Check your errors.packetd file. If packetd isn't complaining then you entered it correctly, and nrConfigure just can't configure it through the GUI. It will write it back to the conf file when push a configuration though.

As for the 1203 issue, you make a good point. I'll have to pass that question on to our signature developers for an answer there.

This will fire on 1206 signatures as well.