DavidMCook
asked on
Event ID 529 from AP domain despite firewall rule
We are seeing about 5 or 6 Event ID 529 messages everyday, all from an Asia-Pacific IP address range. The first 3 octets are always the same - 121.12.175. To combat hacking attempts, we created a rule on our SonicWall TZ-180 appliance to block all traffic from 121.0.0.0 - 121.255.255.255. In spite of this rule, we continually see these hacking attempts. What I don't understand is why SonicWall is allowing the traffic to be passed on to the Windows 2003 SBS. What is more disturbing is the fact that source port 4564 is known to be a worm with DDoS capabilities. Any suggestions?
Logon Failure:
Reason: Unknown user name or bad password
User Name: administrator
Domain: 64.190.70.66
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: ZZWLINE
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 121.12.175.194
Source Port: 4564
event source please
ASKER
Oops.
Source = Security
Category = Logon/Logoff
Type = Failure Aud
Event ID = 529
User = NT AUTHORITY\SYSTEM
Source = Security
Category = Logon/Logoff
Type = Failure Aud
Event ID = 529
User = NT AUTHORITY\SYSTEM
ASKER
Is SonicWall not capable of blocking all traffic from the source IP? That is my preference, that their packets be stopped at the firewall.
I'm not sure about SonicWall configs, but it most cases, troubleshooting firewalls that let packets through that you don't want can be done in this order:
- check for a failover pass-through mode
- check that the rule/policy/acl that stops the undesired traffic comes before other rules/policies/acls that apply to the same range for permits(most firewalls use the top-down method to process rules/policies/acls)
- check that the source address/range is correct as well as the destination
- check that the protocol/protocol suites is/are correct
- check that the destination port(s) are correct
As for that source port, most source ports are generated randomly. the important part is the destination port.
- check for a failover pass-through mode
- check that the rule/policy/acl that stops the undesired traffic comes before other rules/policies/acls that apply to the same range for permits(most firewalls use the top-down method to process rules/policies/acls)
- check that the source address/range is correct as well as the destination
- check that the protocol/protocol suites is/are correct
- check that the destination port(s) are correct
As for that source port, most source ports are generated randomly. the important part is the destination port.
ASKER
co1000100 suggestion to check the order of the firewall rules may have hit on the reason. Unfortunately, SonicWall seems to put all of the ALLOW rules first followed by the DENY rules, and I haven't been able to figure out how to change them. Any other suggestions?
ASKER
I downloaded latest firmware from SonicWall. Hopefullly that will resolve my problem.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.