![[DBTech] DragonByte Security](/community/data/resource_icons/5/5868.jpg?1592168450){kind=icon}
It’s always better to post @ my site to avoid issues getting lost, sometimes I check this site on a device other than my work computer and things can slip my mind, sorry about that
I’ll look into it as soon as I can.
It looks like the HaveIBeenPwned API has changed. Please try disabling the HIBP integration from the XenForo options as that should resolve the login error.I'll keep that in mind, and thanks
GuzzleHttp\Exception\ConnectException:
cURL error 35: Recv failure: Connection reset by peerTorRepository::updateNodes() is fetching the Tor bulk exit list.RequestException:catch (RequestException $e)
{
\XF::logException($e, false, "[Security] Error fetching TOR exit nodes: ");
return;
}GuzzleHttp\Exception\ConnectException.ConnectException is not a subclass of RequestException, the existing catch block does not handle this particular connection failure. The exception therefore propagates into XenForo's server error log instead of following the intended graceful failure path.ConnectException could also be handled here, or the appropriate broader Guzzle exception type could be caught.HTTP: 200
TLS verification: OK
Response size: 21535 byteshttps://check.torproject.org/torbulkexitlist?ip=<host>&port=<port>ip/port parameters may now be obsolete.
This happens when you have setup a security watcher to trigger "Admin lock". Editing a user profile is exactly the admin permission needed to unlock an account. You can avoid using that feature if you don't want admins to be emailed.
I'll change that for the next version, thanks
This is Tapatalk's fault. It has been causing problems since its inception, I honestly didn't even realise anyone still uses it. That being said, your ticket @ my site is open and will be addressed in the next update.
LogicException: Template public:PAGE_CONTAINER error: Cannot modify container while locked
src/XF/Container.php:325#0 src/XF/Container.php(111): XF\Container->assertNotLocked()
#1 src/XF/Container.php(68): XF\Container->set('dbtech_branding', Array)
#2 src/XF/App.php(2923): XF\Container->offsetSet('dbtech_branding', Array)
#3 src/addons/DBTech/Security/Template/Callback/Copyright.php(40): XF\App->__set('dbtech_branding', Array)
#4 src/XF/Template/Templater.php(1911): DBTech\Security\Template\Callback\Copyright::getCopyrightText(...)Please see the post directly above yours as well as the announcement here: https://www.dragonbyte-tech.com/threads/hotfixes-for-xenforo-products.27015/ which also mentions DB Security
Update highlights
!!! This version requires PHP 8.2 !!!
This version features multiple big new features and changes, all requested by you. I hope you enjoy
The biggest new addition is Cloudflare integration. You can now optionally use Cloudflare to block countries - either in addition to, or instead of, the regular XenForo IP banning feature. Furthermore, banning an IP address via Cloudflare is now a possible security watcher action, just...
dbtech_security_comment column from xf_ip_match; uninstallStep3 (runMiscCleanUp()) then queries that same column. This was reproduced three times on the beta. We round-tripped 5.1.4 in the same isolated environment (fresh XF 2.3.13, PHP 8.4.25, etc.) and uninstalled without error, confirming this regression was introduced by the 5.2.0b1 rewrite. The add-on gets stuck mid-removal with no working retry path.Setup.php:219-272Install/UninstallDataTrait.php:42-45
). Https seems to work with the link you're using to capture that data.
That is...quite the oversight on my part
Shows how long since I touched the Setup.php file itself, haha. I'll reshuffle the files so Step 3 becomes Step 1, etc. Thanks!Interesting, thank you for checking and letting me know! From my git history I can see I originally created the feature in 2019, so perhaps they didn't have a HTTPS certificate at that point, or (like the old Country VAT rate APIs I used for eCommerce at one point) they charged for HTTPS.2) In both 5.1.4 and the 5.2.0 Beta, country ban lists are fetched over http:// from ipdeny.com with no integrity check, then inserted directly into the ban table. Low risk probably, but a MITM'd response could ban the entire internet from the forum (worst case
Thank you very much, I greatly appreciate itWill circle back if anything else comes up.
We tested this one directly since it's a core product we use as well. There were no real conflicts found. This addon and Xon's would probably only overlap when it comes to the IP checking. But, Xon's addon uses XF's core system for this whereas this addon feeds it's own reverse proxy. At most, they could disagree with what a visitors IP actually is, but that's about it.
../vendor/badbehaviour/badbehaviour/src/Util/HeaderUtil.php:59-71$addrs = array_reverse(preg_split('/[\s,]+/', $headers_mixed[$header]));
$trusted_proxies = $settings['reverse_proxy_addresses'] ?? [];
foreach ($addrs as $addr) {
$addr = trim($addr);
if (empty($addr)) continue;
$is_trusted = !empty($trusted_proxies) ? IpUtil::match_any($addr, $trusted_proxies) : false;
$is_private = IpUtil::is_private($addr);
if (!$is_trusted && !$is_private) {
return $addr;
}
}Repository/WatcherRepository.php:82-86'reverse_proxy' => [
'enabled' => (bool) $options->dbtech_security_badbehavior_reverse_proxy['enabled'],
'header' => $options->dbtech_security_badbehavior_reverse_proxy['header'] ?: 'X-Forwarded-For',
'addresses' => [],
], 'addresses' => [], << This looks like it's hard coded with no option to populate. There is no admin-facing field in the ACP for entering trusted proxy IP ranges, so the empty array can never be populated. The risk here is when a reverse-proxy support enabled, any visitor could potentially spoof their apparent IP via a forged X-Forwarded-For header, potentially bypassing IP bans, country blocking, and bot detection, with no configuration path available to prevent it.
