Options
IETF RADIUS Dictionary Attack Vulnerability
djhurt1
Newbie ✭
A third party has scanned our network for vulnerabilities recently. This popped up on the first scan. This is one vulnerability that I thought I took care of but it showed up again on the second scan. We've disabled management on WAN port. I've port scanned the WAN IP and nothing responds on port 1812 for me. There is one default access rule
Here is the a pic of the report
It states port 1812/udp but again I can't get a response on that port in port scan. One idea was to set the from field in access rule to a random address. Any other thoughts on why the sonicwall is responding and how to eliminate it?
Category: Mid Range Firewalls
0
Answers
I did find a default NAT rule which I believe is likely the cause of this however why was this rule auto added? We never used RADIUS. Is this a standard out of the box thing?
@djhurt1 the comment text bubble does not give a hint?
I can only find auto generated Radius rules when SonicPoints are involved. Are you using the SonicWall Switches? There was a Radius section in there, but I can't test this.
--Michael@BWC
@BWC
No sonicwall switch on this firewall. I should correct my statement above, we do have RADIUS(NPS) implemented for a virtual access point but that's it.
@djhurt1 does the bubble for NAT or Access Rules holds any hint?
--Michael@BWC
@bwc just says "Management NAT policy". We use local users on the sonicwall for management. I can't edit/remove the access rule or the NAT rule. I imagine I could go into the /diag page to allow me to delete these rules but as always I question if these are there for something I haven't considered.
@BWC
just says "Management NAT policy". We use local users on the sonicwall for management. I can't edit/remove the access rule or the NAT rule. I imagine I could go into the /diag page to allow me to delete these rules but as always I question if these are there for something I haven't considered.
I've disabled the NAT rule and set the access rule to discard. However ports scans still show UDP Open|Filtered and TCP shows filtered. This happens regardless if the access rule is set to deny or discard.