Fix for pnx-mono.exe crashing
47 views
Skip to first unread message
Shaun McLeod - VE4AI
Dec 29, 2017, 10:42:11 PM12/29/17
to P25NX
Mitch (KH6MP) and I were chatting today on WW. The topic of unstable Pis came up. I mentioned some observations, and was encouraged to share this with the group:
For those of you who have noticed pnx-mono.exe crashing (i.e. not running/not connected to P25NX), it's due to the admin interface being accessible to the evil public Internet.
Fellow Canadian hoser Steve (VE3XF) and I both noticed this crashing issue. Setting a nightly crontab to reboot the Pi fixed the issue, but why schedule a reboot? That's not a fix. It's like putting a rag under your fridge, because it keeps leaking. Why not fix the leak?
In this case, the script kiddy hax0rs (or port scanning) was causing the pnx-mono.exe web interface to lock up. Firewalling it completely solves the issue.
On the Pi, implement these firewall rules: (Remove the ' ' quotes from my commands)
'sudo /sbin/iptables -A INPUT -p tcp -s 44.128.0.0/16 --sport 1024:65535 -j ACCEPT --dport 8080'
This rule allows an IP or subnet (44.128.0.0/16 for this example) to connect from client ports 1024-65535, to the pnx-mono web daemon on port 8080. Replace 44.128.0.0/16 with your own subnets or static IP addresses. Make multiple lines if needed.
After you've added your access list, proceed to add this:
'sudo /sbin/iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d 0/0 -j DROP --dport 8080'
Anything else other than the IP(s) or subnet(s) you've allowed in the first line, will be dropped.
Steve and I have been running the iptables rules for the last month or so, and zero crashes since. 100% stable now. So yes, the pnx-mono.exe crashing was absolutely related to unwanted traffic hitting the web interface.
Make sure you put the ACCEPT rules first, then add the REJECT entry. The kernel has to interpret them in a certain order. You'll have to add them to a script that runs at boot time, or manually enter them each time you reboot.
To see a listing of your current iptables rules, run the command: 'sudo iptables -L -n -v'
To flush the rules, if you make a mistake: 'sudo iptables -P INPUT ACCEPT'
Then: 'sudo iptables -F'
Hope this helps those who were experiencing lockups.
Shaun VE4AI (Alien Invasion)
3024003 / 3024004
For those of you who have noticed pnx-mono.exe crashing (i.e. not running/not connected to P25NX), it's due to the admin interface being accessible to the evil public Internet.
Fellow Canadian hoser Steve (VE3XF) and I both noticed this crashing issue. Setting a nightly crontab to reboot the Pi fixed the issue, but why schedule a reboot? That's not a fix. It's like putting a rag under your fridge, because it keeps leaking. Why not fix the leak?
In this case, the script kiddy hax0rs (or port scanning) was causing the pnx-mono.exe web interface to lock up. Firewalling it completely solves the issue.
On the Pi, implement these firewall rules: (Remove the ' ' quotes from my commands)
'sudo /sbin/iptables -A INPUT -p tcp -s 44.128.0.0/16 --sport 1024:65535 -j ACCEPT --dport 8080'
This rule allows an IP or subnet (44.128.0.0/16 for this example) to connect from client ports 1024-65535, to the pnx-mono web daemon on port 8080. Replace 44.128.0.0/16 with your own subnets or static IP addresses. Make multiple lines if needed.
After you've added your access list, proceed to add this:
'sudo /sbin/iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d 0/0 -j DROP --dport 8080'
Anything else other than the IP(s) or subnet(s) you've allowed in the first line, will be dropped.
Steve and I have been running the iptables rules for the last month or so, and zero crashes since. 100% stable now. So yes, the pnx-mono.exe crashing was absolutely related to unwanted traffic hitting the web interface.
Make sure you put the ACCEPT rules first, then add the REJECT entry. The kernel has to interpret them in a certain order. You'll have to add them to a script that runs at boot time, or manually enter them each time you reboot.
To see a listing of your current iptables rules, run the command: 'sudo iptables -L -n -v'
To flush the rules, if you make a mistake: 'sudo iptables -P INPUT ACCEPT'
Then: 'sudo iptables -F'
Hope this helps those who were experiencing lockups.
Shaun VE4AI (Alien Invasion)
3024003 / 3024004
David Krauss
Dec 29, 2017, 11:25:14 PM12/29/17
to Shaun McLeod - VE4AI, P25NX
nice find! that’s why some people never had issues - weren’t getting attacked. others were.
Sent from an iPhone 6
--
You received this message because you are subscribed to the Google Groups "P25NX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to p25nx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/p25nx/00ce6b58-0935-4435-b90f-3f7c5173d751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Steve Jones
Dec 30, 2017, 5:27:59 PM12/30/17
to Shaun McLeod - VE4AI, P25NX
I've got three machines on the network and the only one not firewalled experienced the lockups. The pnx-mono process on the pi would crash and need to be restarted.
I took a working pi/Cisco setup to replace the setup which locked up every few days and nothing changed so I knew it wasn't a hardware or software issue.
I removed the web server redirect line in the Cisco since I login from various addresses. If I ever need to log back into the web server on the pi, I'll just reenable it.
Since then, everything has been stable.
--
Bryan Fields
Dec 30, 2017, 9:31:26 PM12/30/17
to P25NX
On 12/30/17 5:27 PM, Steve Jones wrote:
> I've got three machines on the network and the only one not firewalled
> experienced the lockups. The pnx-mono process on the pi would crash and
> need to be restarted.
It should automatically restart as it's supervised via systemd. That being
> I've got three machines on the network and the only one not firewalled
> experienced the lockups. The pnx-mono process on the pi would crash and
> need to be restarted.
said, the html interface needs to be firewalled, it's not stable when
subjected to internet background radiation.
You can do this on the cisco by mapping the 8080 to a less well known port or
an acl.
Example for my two nodes on my test router:
ip nat inside source static tcp 172.31.4.226 22 interface FastEthernet0/0 45632
ip nat inside source static tcp 172.31.4.227 22 interface FastEthernet0/0 45633
ip nat inside source static tcp 172.31.4.226 8080 interface FastEthernet0/0 45642
ip nat inside source static tcp 172.31.4.227 8080 interface FastEthernet0/0 45643
ip access-list extended MGMT_FILTER
permit tcp 192.168.0.0 0.0.255.255 any range 45630 45650
permit tcp 44.98.0.0 0.0.255.255 any range 45630 45650
permit tcp 208.38.136.0 0.0.0.255 any range 45630 45650
permit tcp host 67.78.199.10 any range 45630 45650
permit tcp 10.0.0.0 0.255.255.255 any range 45630 45650
permit tcp host 96.254.123.27 any range 45630 45650
permit tcp 172.16.0.0 0.15.255.255 any range 45630 45650
deny tcp any any range 45630 45650
permit ip any any
interface FastEthernet0/0
ip access-group MGMT_FILTER in
Don't forget a good vty ACL too.
Next version is going to remove the whole cisco router and replace it with
less complex FTDI device. The config will be a text file too, nor more
webserver.
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
Reply all
Reply to author
Forward
0 new messages