Cool, I'll be setting some of that up in the next few pushes
for fail2ban configurations, likely after fleshing out the
firewall scripting more as they'll use similar matching
statements for ports. I'll be setting a default of 10 minuets
(600 seconds) for ban times and have commented lines
printed under each configuration block for easy modifying
after script run time.
I looked into Python and some of the steps to go through
on translation to another language, there doesn't seem to
be an effective way of translating case/switch statements;
lots of discussion and workarounds. Ruby is looking to be
a simpler switch and I may pursue this as an alternative.
Either way I'll be sharing notes on how I'd translate
portions in the Wiki as I find good examples. For Python
it looks like a lot of rewriting case statements into if/elif
but for Ruby it looks like a few syntax changes and the
use of `put` or `printf` in place of `echo` for reading out
info to the user.
I've also been looking further into encrypted partitions for
chroot jails via `dm-crypt` but have yet to find a solid way
of setting the first passphrase through a script (unless
piping an echo of it is acceptable); everything else is well
documented enough to script though and I'm already
working on how best to scrub the
`/${USER?}/home/.bash_history`
and other logs of script runtime information that is sensitive.
I could use suggestions as to whether or not encrypting a
chroot jail fully or just specific directories would be
preferred; ie just a user's home directory or a web
server's jail? Either way I'll also have to leave notes in the
logs on how to resize encrypted partitions &/or write a
wrapper for doing the task within the main script pack;
looks like the difference between `>` and `>>` on whether
or not a partition is overwritten or appended to when
expanding. If there are suggestions on `dm-crypt`
options, ie algorithms, partition size defaults, whether or
not to use `/dev/random` or `/dev/urandom`..., that
should be default behavior I'm all ears before I get into
drafting this part up.
On February 1, 2016 4:20:01 AM PST, coderman <coder...@gmail.com> wrote:
>On 2/1/16, Michael <strangerthanbl...@gmail.com> wrote:
>> ...
>> My last question (for now) has to do with Fail2Ban and hidden
>services.
>>
>> My question is would you all prefer that separate jail.local
>configuration
>> blocks be written for each Tor service port individually, ei failing
>one
>> port
>> doesn't ban from a possible second hidden service port, or is a fail
>one
>> ban'em all sufficient?
>
>please allow a single default jail.local to be used in one or any Tor
>service port configurations, including hidden service port
>configurations.
>
>then also allow each distinct configuration (IP:port, unix_domain,
>etc) of any Tor service configuration to be blocked individually.
>
>the latter is very useful for power users / multiple onion service
>operators who use service isolation intentionally to mitigate concerns
>of directed attacks, denial of service, or related risks.
>
>(there might be a better way than a sane default, with optional
>per-endpoint limits; that's my favorite approach to this question for
>now.)
>
>
>best regards,
>--
>tor-talk mailing list - tor-talk@lists.torproject.org
>To unsubscribe or change other settings go to
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
