https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162011-01-23T20:21:00ZpfSense bugtrackerpfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=47772011-01-23T20:21:00ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Target version</strong> deleted (<del><i>2.0</i></del>)</li></ul><p>You're hanging PHP by doing that, don't do that is the answer. Killing all php processes at the console or an existing SSH session will fix it. The console menu over SSH can't load when PHP is hung. There are plenty of ways to DoS yourself especially when you're authenticated, should be fixed at some point assuming it's replicable but not targeting 2.0 as it would never be hit in a real scenario.</p> pfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=47782011-01-23T20:37:19ZAlexander Kalashnikovst41ker@yandex.ru
<ul></ul><p>I'm sure that that is a pretty real scenario, since that two or more admins can make some changes simultaneously.</p>
<p>I can not start any commands from the local console and I can not login via ssh. Somehow I've got the reboot command to be executed via ssh (ssh <a class="email" href="mailto:root@server.localdomain.local">root@server.localdomain.local</a> reboot) but the server got stuck and responses only to ping now.<br />Also until syslogd was online I've got some messages regarding the reboot. But in fact the server did not reboot. It seems like php init scripts causing the server to stuck at some point.</p>
<p>I think that all system scripts must be run only by the cli version of php.</p> pfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=47832011-01-24T09:38:45ZAlexander Kalashnikovst41ker@yandex.ru
<ul></ul><p>UPD:</p>
<p>System can be only rebooted by issuing ssh [ip] reboot -q</p> pfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=47952011-01-25T03:04:49ZChris Buechlercbuechler@gmail.com
<ul></ul><p>I can't replicate this even clicking the force sync button as fast and as many times as I possibly can, it just works. May be something something that's easier to trigger on slow hardware. Triggering 4-5 config syncs per second isn't going to happen even if you have a whole team of admins logged in at once. 'ssh [ip] killall php' will fix too.</p> pfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=47962011-01-25T07:47:38ZAlexander Kalashnikovst41ker@yandex.ru
<ul></ul><p>I can reproduce it only using a "big" configuration file (~120 firewall rules + 10 interfaces) and with moderate HW performance difference on nodes (2.8GHz CoreDuo and 2.1Ghz Celeron). Master is more powerfull. In my virtual lab I could not reproduce an issue with the same config. And you're right: the only difference I saw is that both WMs has the same productivity but not my real firewall configurations. To reproduce an issue try to rise php fcgi processes priority on the slave.</p>
<p>kill(all) does not work with any SIGNAL, only reboot helps.</p>
<p>It's obvious that you need to check for current status of the slave before the syncronization.</p> pfSense - Bug #1226: Possible DOS in CARP synchronizationhttps://redmine.pfsense.org/issues/1226?journal_id=106392013-02-12T13:16:00ZJim Pingle
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Closed</i></li></ul><p>This has, in all likelihood, been fixed since then. The behavior would at least have changed on 2.1 after the recent php+lighty changes.</p>