I am running Asterisk 16.9 on FreeBSD 12.1-RELEASE-p1. I keep seeing lines like this in my logs. [Apr 1 13:30:33] NOTICE[101155][C-00004526] chan_sip.c: Call from '' (45.143.220.235:5356) to extension '2037' rejected because extension not found in context 'unauthenticated'. I have a script that checks for things like this and adds them to my packet filter (pf). Everything seems to work up to a point. The IP address gets added to my AUTOBLOCK table. The second rule, right after the friends whitelist, blocks any IP in that table. If I try to ping or traceroute to it I can't get through. I ran netstat -a and sockstat -c and the IP address does not show up in the connections. Every test suggests that the system is doing exactly what I want it to do. The weird thing is that the attempts don't stop. That IP continues to try different numbers. There are two ways that I have found so far to actually stop the attack. One is to completely stop Asterisk and then restart it. Obviously not a good option on a production switch. The other way is to null route the IP. That stops it cold. That's better but it needs me to manually intervene. However, it does make it clear that the IP address is not being faked somehow. I also tried doing "pfctl -k 45.143.220.235" but that says that no connections were dropped. It looks like pf is convinced that the connection is gone. So, can anyone suggest why the attack keeps happening? -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com
D'Arcy Cain <darcy at VybeNetworks.com> writes:> I have a script that checks for things like this and adds them to my > packet filter (pf). Everything seems to work up to a point. The IP > address gets added to my AUTOBLOCK table. The second rule, right after > the friends whitelist, blocks any IP in that table. If I try to ping or > traceroute to it I can't get through. I ran netstat -a and sockstat -c > and the IP address does not show up in the connections. Every test > suggests that the system is doing exactly what I want it to do.But yet, new packets from that IP address reach asterisk. It seems almost entirely clear to me that you have a firewall problem, not an asterisk problem. I would test this out with a remote machine under your control, and packet trace. I would check for a buggy firewall rule that is somehow accepting packets from new tcp or udp packets as matching an old connection state object. I would check for the new attempts as coming from something that matches the original "connection", even if UDP.> The weird thing is that the attempts don't stop. That IP continues to > try different numbers. There are two ways that I have found so far toYou say "continues to try", but surely you are not surprised that packets arrive at your computer. I think you are surprised that they make it to asterisk. But your language doesn't quite line up with that. Am I misinterpreting?
On 2020-04-01 15:12, Greg Troxel wrote:> D'Arcy Cain <darcy at VybeNetworks.com> writes: > But yet, new packets from that IP address reach asterisk. It seems > almost entirely clear to me that you have a firewall problem, not an > asterisk problem.This could well be but Asterisk is the only thing that continues to communicate.> I would test this out with a remote machine under your control, and > packet trace. I would check for a buggy firewall rule that is somehow > accepting packets from new tcp or udp packets as matching an old > connection state object. I would check for the new attempts as coming > from something that matches the original "connection", even if UDP.Here is the first four lines from "pfctl -sr": pass in quick on bge0 from <FRIENDS> to any flags S/SA keep state block drop in log quick on bge0 from <ENEMIES> to any block drop in log quick on bge0 from <AUTOBLOCK> to any block drop out log quick on bge0 from any to <AUTOBLOCK> Unless pf is broken I can't see how anything besides my "friends" can be getting through.>> The weird thing is that the attempts don't stop. That IP continues to >> try different numbers. There are two ways that I have found so far to > > You say "continues to try", but surely you are not surprised that > packets arrive at your computer. I think you are surprised that they > make it to asterisk. But your language doesn't quite line up with > that. Am I misinterpreting?Maybe. By "try" I don't mean "try to get through". I mean "try to access my switch". They aren't actually breaking in. My passwords are strong enough to frustrate them. -- D'Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation - Propelling Business Forward http://www.VybeNetworks.com/ IM:darcy at VybeNetworks.com VoIP: sip:darcy at VybeNetworks.com