We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

Event ID 529 from AP domain despite firewall rule

Medium Priority
749 Views
Last Modified: 2013-12-07
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

Open in new window

Comment
Watch Question

Commented:
event source please

Author

Commented:
Oops.

Source = Security
Category = Logon/Logoff
Type = Failure Aud
Event ID = 529
User = NT AUTHORITY\SYSTEM


Author

Commented:
Is SonicWall not capable of blocking all traffic from the source IP?  That is my preference, that their packets be stopped at the firewall.
Carlos DiazMilitary Systems Equipment Specialist
CERTIFIED EXPERT

Commented:
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.

Author

Commented:
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?

Author

Commented:
I downloaded latest firmware from SonicWall.  Hopefullly that will resolve my problem.
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.