This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Receiving IPS alerts (2-3 times /day). Usually from the same IP address (sometimes from one within the same range), but content is the same

Intrusion Prevention Alert

An intrusion has been detected. The packet has *not* been dropped.
If you want to block packets like this one in the future,
set the corresponding intrusion protection rule to "drop" in WebAdmin.
Be careful not to block legitimate traffic caused by false alerts though.

Details about the intrusion alert:

Message........: MALWARE-OTHER Win.Malware.Ursu-9821797-0 download attempt
Details........: https://www.snort.org/search?query=56912
Time...........: 2021-02-12 02:00:32
Packet dropped.: no
Priority.......: high
Classification.: A Network Trojan was Detected
IP protocol....: 6 (TCP)

Source IP address: 184.150.154.11 
Source port: 80 (http)
Destination IP address: xxx.xx.xx.xxx 
Destination port: 51576


I checked the settings in IPS attack patterns, and all rules are set to "drop"
Firewall log:
2021:02:12-02:00:29 athens snort[29360]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="alert" reason="MALWARE-OTHER Win.Malware.Ursu-9821797-0 download attempt" group="500" srcip="184.150.154.11" dstip="xxx.xx.xx.xxx" proto="6" srcport="80" dstport="51576" sid="56912" class="A Network Trojan was Detected" priority="1" generator="1" msgid="0"
I was getting fed up with the messages (figuring they were either false positives or some script kiddie), so I put in a firewall rule in the the hopes of ridding my self of the repeated messages.
Bell-AS577 = 184.15.128.0/18
The messages continue.  Anyone with sage advice?


This thread was automatically locked due to age.
Parents
  • first: The FW-Rule don't match, because the session is established from internal and is written to the session table.
    If there is a session-entry at the session-table no more FW-rules are evaluated.
    So you can't block the traffic this way. Possible you can block the session-initiation by using Bell-AS577 as destination.

    As I said, a response packet is blocked. Access is initiated from your network.
    You should try to find the source of communication.
    It is also important whether the attempt at communication takes place regularly / repeatedly.
    Possible "every time the user starts his PC", every 4 hours, same times every day.
    It may be a false positive .. A regular app may try to reach his update-server.
    The answer you will find within Firewall- or WebFilter-Log.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Reply
  • first: The FW-Rule don't match, because the session is established from internal and is written to the session table.
    If there is a session-entry at the session-table no more FW-rules are evaluated.
    So you can't block the traffic this way. Possible you can block the session-initiation by using Bell-AS577 as destination.

    As I said, a response packet is blocked. Access is initiated from your network.
    You should try to find the source of communication.
    It is also important whether the attempt at communication takes place regularly / repeatedly.
    Possible "every time the user starts his PC", every 4 hours, same times every day.
    It may be a false positive .. A regular app may try to reach his update-server.
    The answer you will find within Firewall- or WebFilter-Log.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

Children
No Data