Warren Togami Jr. [ARCHIVE] on Nostr: 📅 Original date posted:2013-08-16 📝 Original ...
📅 Original date posted:2013-08-16
📝 Original message:https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
*Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node, it becomes more expensive for attackers to use
a single host exhaust a target node's resources. This iptables firewall
based example has almost zero drawbacks, but it is too complicated for most
people to deploy. Yes, there is a small chance that you will block
legitimate connections, but there are plenty of other nodes for random
connections to choose from. Configurable per source IP and source subnet
limits with sane defaults enforced by bitcoind itself would be a big
improvement over the current situation where one host address can consume
limited resources of many target nodes.
This doesn't remove the risk of a network-wide connection exhaustion attack
by a determined attacker, but it at least makes multiple types of attacks a
lot more expensive. This also doesn't do much against the io
vulnerability, which would require major redesigns to prevent in Bitcoin.
https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
*Want to safely delay the block size limit increase for another year or two?
* This patch alone enables that.
On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike at plan99.net> wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
>
> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block sizes,
> even post April. It can probably be safely delayed for a while.
>
>
> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> Cool. Maybe it's time for another development update on the foundation
>> blog?
>>
>>
>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
>>
>>> Mike asked what non-0.9 code I'm working on; the three things on the top
>>> of my list are:
>>>
>>> 1) Smarter fee handling on the client side, instead of hard-coded fees.
>>> I was busy today generating scatter-plots and histograms of transaction
>>> fees versus priorities to get some insight into what miner policies look
>>> like right now.
>>>
>>> 2) "First double-spend" relaying and alerting, to better support
>>> low-value in-person transactions. Related:
>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>;
>>>
>>>
>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>>> block size limit, how we can do it safely, and go through all of the
>>> arguments that have been made against it and explain why they're wrong.
>>>
>>> --
>>> --
>>> Gavin Andresen
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/c9fbdf46/attachment.html>;
📝 Original message:https://togami.com/~warren/archive/2013/example-bitcoind-dos-mitigation-via-iptables.txt
*Anti-DoS Low Hanging Fruit: source IP or subnet connection limits*
If you disallow the same IP and/or subnet from establishing too many TCP
connections with your node, it becomes more expensive for attackers to use
a single host exhaust a target node's resources. This iptables firewall
based example has almost zero drawbacks, but it is too complicated for most
people to deploy. Yes, there is a small chance that you will block
legitimate connections, but there are plenty of other nodes for random
connections to choose from. Configurable per source IP and source subnet
limits with sane defaults enforced by bitcoind itself would be a big
improvement over the current situation where one host address can consume
limited resources of many target nodes.
This doesn't remove the risk of a network-wide connection exhaustion attack
by a determined attacker, but it at least makes multiple types of attacks a
lot more expensive. This also doesn't do much against the io
vulnerability, which would require major redesigns to prevent in Bitcoin.
https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
*Want to safely delay the block size limit increase for another year or two?
* This patch alone enables that.
On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn <mike at plan99.net> wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
>
> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block sizes,
> even post April. It can probably be safely delayed for a while.
>
>
> On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn <mike at plan99.net> wrote:
>
>> Cool. Maybe it's time for another development update on the foundation
>> blog?
>>
>>
>> On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen <gavinandresen at gmail.com>wrote:
>>
>>> Mike asked what non-0.9 code I'm working on; the three things on the top
>>> of my list are:
>>>
>>> 1) Smarter fee handling on the client side, instead of hard-coded fees.
>>> I was busy today generating scatter-plots and histograms of transaction
>>> fees versus priorities to get some insight into what miner policies look
>>> like right now.
>>>
>>> 2) "First double-spend" relaying and alerting, to better support
>>> low-value in-person transactions. Related:
>>> *Have *a *Snack*, Pay with *Bitcoins*<http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf>;
>>>
>>>
>>> 3) Work on 2-3 whitepapers on why we need to increase or remove the 1MB
>>> block size limit, how we can do it safely, and go through all of the
>>> arguments that have been made against it and explain why they're wrong.
>>>
>>> --
>>> --
>>> Gavin Andresen
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130816/c9fbdf46/attachment.html>;