Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
JP_Rex
Collaborator
Collaborator
Jump to solution

Weird IP (0.0.127.x) in IPS Logs

Hello,

Does anyone now the source address 0.0.127.243?

 

<row>
<field name="time" value="2024-10-07T12:08:55Z" resolved="Today, 14:08:55"/>
<field name="id" value="c5e61144-9f5d-c7c6-6703-cf5700000180"/>
<field name="sequencenum" value="205"/>
<field name="src" value="0.0.127.243"/>
<field name="dst" value="10.x.y.z"/>
<field name="attack" value="Windows SMB Protection Violation"/>
<field name="attack_info" value="Brute Force Scanning of CIFS Ports"/>
<field name="protection_name" value="Brute Force Scanning of CIFS Ports"/>
<field name="protection_id" value="asm_dynamic_prop_CIFS_BF_PORT_SCAN"/>
<field name="severity" value="Medium" icon="Levels/Color_4_2"/>
<field name="confidence_level" value="Low" icon="Levels/Blue_5_1"/>
<field name="performance_impact" value="Critical" icon="Levels/Color_5_5"/>
<field name="protection_type" value="IPS" icon="Protection/Protections"/>
 
This kind of log entry is visible in Log sinceR81.20 ~HFA70:
 
I know IP like 0.0.0.x, but this seems different.
 
Regards
 
Peter
1 Solution

Accepted Solutions
JP_Rex
Collaborator
Collaborator

R&D found the Bug. There is a Fix currently for R82 (GA). It will be installed on our Gateway when we update from EA to GA, later this month.

The Bug was introduced into the main train with  R81.20 HFA 65 and is tracked under  PRHF-36813. 

If you have this error please contact the TAC nearest to you for a port of the Fix.

 

Regards

 

Peter

View solution in original post

11 Replies
PhoneBoy
Admin
Admin

That doesn't seem like a valid IP address.
Might need TAC to investigate that.

0 Kudos
JP_Rex
Collaborator
Collaborator

I opened the TAC SR two or three weeks before I wrote this.

It is with R&D.
Regards
Peter

0 Kudos
Lesley
Leader Leader
Leader

Looks a bit look a loopback IP that got messed up. Do you know traffic comes from internal or internet?

I see destination internal IP and not external so I assume internal? 

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
No2
Participant

@JP_Rex Did you ever get an answer on this?

I also noticed something similar in a customer's environment. Reading the packet capture shows a different source IP than the log, itself.

I'm in the process of investigating the device generating the traffic to learn more. Considering opening a TAC case to report it as unexpected behavior, since this doesn't otherwise appear to be a valid log.

0 Kudos
No2
Participant

@JP_RexGot a response for a CP representative. Looks like this is a bug that will be patched by PRHF-36797.

0 Kudos
JP_Rex
Collaborator
Collaborator

Sounds good.
Did you have the same IP Pattern (0.0.127.x) in your logs?
Regards
Peter

0 Kudos
No2
Participant

Yes, same IPs specifically in IPS logs. Reviewing the attached packet captures in Wireshark showed the real source IP.

You might have TAC double check with R&D whether PRHF-36797 is relevant to your case.

0 Kudos
JP_Rex
Collaborator
Collaborator

Do that.

But check the RAW log entry before How to enable raw log data for firewall logs in R80.x and R81.x 

Because the SmartView Service adds Information and may change the RAW Data.

Regards
Peter

JP_Rex
Collaborator
Collaborator

R&D found the Bug. There is a Fix currently for R82 (GA). It will be installed on our Gateway when we update from EA to GA, later this month.

The Bug was introduced into the main train with  R81.20 HFA 65 and is tracked under  PRHF-36813. 

If you have this error please contact the TAC nearest to you for a port of the Fix.

 

Regards

 

Peter

jo_dolowsk
Participant

same issue

0 Kudos
Jarvis_Lin
Collaborator

We have also found this kind of log among our customers. Will this bug be included in the R81.20 jumbo hotfix?

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events