BWC Cybersecurity Overlord ✭✭✭
Reactions
Comments
-
The "Path listens on" is always your end and tells the ES on which ports it should listen to receive mails. In your case it listens to all addresses the ES has assigned to and only on the ports configured. IMHO your inbound flow should only cover port 25, because it's a gateway and not meant for MUA initiated traffic. The…
-
@ITRAD43 there is no exclude from IP Spoof detection, if the Firewall receives a packet from an address which is not routed over that specific interface it counts as spoof. Why is this device sending the ping from a wrong address? If this device is multi-homed? —Michael@BWC
-
This is good news, welcome aboard. —Michael@BWC
-
I've seen this for years and don't bother anymore. If it shows just a single message, it will most likely not list it and loading forever. I did not found any real logic behind it. I'am not a big fan of the queue management on ES. —Michael@BWC
-
@ngrubb crank up a packet-monitor on both sides with the IPs of both servers and capture only dropped packets, this should give you a hint if the firewall is involved or not. If there is ANY service allowed between them then it's probably not a firewall issue. —Michael@BWC
-
I did not received any CATP reports by mail for a while, but if memory serves me right, they could be found under Settings → Notification Center, which is the obvious path I would look for, NOT. —Michael@BWC
-
@adrb04 what Firmware are you running on the TZ 600? There was an issue recently and it "should" be fixed in 6.5.4.15-117n (dont confuse it with -116n) and 6.5.5.1-6n. —Michael@BWC
-
There are some shortcomings for SSL-VPN (no Wireguard, no fail2ban, …) and not being able to allow only authorized Endpoints is one of them. You just cant limit access to SSL-VPN on SonicOS at the moment, and I fear this will never change, because all roads are heading to Cloud Secure Edge for SNWL. The SMA (100 or 1000…
-
MAC addresses are Layer 2, SSL-VPN is on Layer 3. You cannot block based on MAC address when coming from the WAN. —Michael@BWC
-
@tb_redondo this answer is still valid. https://community.sonicwall.com/technology-and-support/discussion/comment/12937#Comment_12937 —Michael@BWC
-
I guess SonicWall did not disclose the internal URLs affected. It would not make any difference anyhow for securing your appliance. Log Events are properly documented over here (if you're on Gen6 you need to search for the Gen6 reference documentation). —Michael@BWC
-
@Mariusz do you have DPI-SSL enabled? Because for HTTPS it only works that way. CFS, GAV, GeoIP, Botnet and Anti-Spyware do provide a block page, IPS and AppControl do not. —Michael@BWC
-
@Norsmith what are you trying to accomplish? Please elaborate. —Michael@BWC
-
@SWall_Forever this Access Rule sounds insanely stupid, but to assess the risk the accompanying NAT rules are crucial. Only the traffic that gets NATed will hit the Access Rule. What is the destination of your NAT rules, your PBX? In my opinion there is no need for inbound Rules to get VoIP working properly, but it depends…
-
If you don't want to disable GeoIP & Botnet logging then you're probably out of luck. The logging of this event is stupid, because it's done even with Remediation disabled in the settings. Setting the loglevel to Warning might help, but I can't tell what you'll missing. —Michael@BWC