[arm-allstar] Firewall thoughts ---was:Trouble with Supermon

[David McGough]

We've gotten way, WAY off the purpose of this mailing list---support for 
HamVoIP/AllStar....So, we should probably rein in this thread.

That being said, yes, I agree that many groups around the world have very
big computers and can apply brute-force plus statistical analysis to crack
many passwords relatively quickly.  But, there are some stark contrasts
that we must remember.

First and foremost: When these groups are brute-forcing a password, they
are able to instantly know if they've succeeded. For example: they obtain
a copy of an Linux/Unix /etc/shadow file and can instantly compare
directly against its contents. In the scenario of an attack against the
sshd, there is a HUGE network latency penalty slowing these tests down,
even if the victim of the attack is on a local LAN! The only solution to
reduce the latency impact is to go massively parallel, with many
simultaneous connections to sshd. In this case, a sshd DoS condition could
be the result and certainly iptables or other rate limiting tools will
help mitigate this type of attack.

Second:  We're not trying to protect World Bank here!! Nobody is going to
spend the money to throw a supercomputer at a RPi3! There will be plenty
of script kiddies, though, running comprehensive dictionary attacks. And,
plenty of users out there still obviously have trivial-to-crack passwords
---if they didn't, even the script kiddies wouldn't waste their time.

Some final food for thought for those (like me) who turn off password
access to sshd and only use PKA keys: What, effectively, is a PKA
public/private key pair???  Simply put, is a very, very complex password
scheme! And, they can potentially be hacked, too, given some agency with 
an awfully good reason to need to allocate the resources to the task!

73, David KB4FXC




On Sat, 19 May 2018, "KI7AY via arm-allstar" wrote:

> Just for a little levity, here. UC Berkley could crack a 10-digit 
password in a few hours. But they gots GIANT computing power!

73 Jim KI7AY


On 5/19/2018 4:17 PM, "David McGough via arm-allstar" wrote:
> Hi Mark,
>
> I don't think Doug was offended, nor was I. He was just making the
> observation that good passwords are still completely viable as a security
> barrier.
>
> And, thanks for your comments about the iptables rules. The Linux
> netfilter firewall tools are very capable and anything a user can do to
> impede hacking ATTEMPTS is a good thing.
>
>
> 73, David KB4FXC
>
>
>
> On Sat, 19 May 2018, "Mark Grigsby via arm-allstar" wrote:
>
>> Sorry to have offended you Doug.
> It was my intention to help someone understand a miss-conception of how the
> command worked, not to engage in an argument, or disagree with you about
> passwords.  Personally I never use passwords, but that is a "day-job" thing.
>
>
>
> On Sat, May 19, 2018 at 1:36 PM, "Doug Crompton via arm-allstar" <
> arm-allstar at hamvoip.org> wrote:
>
>> Yeah, and how many years would it take to hack at 10 digit random
>> upper/lower, numeric, special character password? Probably not in your
>> lifetime with the limits imposed by ssh. I wish people would worry about
>> more important things! No one is going to hack your password if it is a
>> good one.
>>
>> Can we end the firewall/security talk. No one with a good password has been
>> hacked into. If you can't make up a password use a password generator to
>> see what a good one looks like.
>>
>> https://passwordsgenerator.net/
>>
>>
>> *73 Doug*
>>
>> *WA3DSP*
>>
>> *http://www.crompton.com/hamradio <http://www.crompton.com/hamradio>*
>>
>>
>>
>> On Sat, May 19, 2018 at 3:48 PM, "Mark Grigsby via arm-allstar" <
>> arm-allstar at hamvoip.org> wrote:
>>
>>> I am new to allstar hamvoip and the list.  I would like to say thank you
>>> for all the hard work others do.  In regard to the iptables / netfilter
>>> rule above, I think there might be a little confusion about the meaning
>> of
>>> the rule.
>>>
>>> ""iptables -A INPUT  -p tcp -m tcp --dport 222 -m state --state NEW -m
>>> recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j
>>> DROP""
>>>
>>> In this rule you have to make an attempt to connect to the ssh server 4
>>> times in 60 seconds, the 5th connection withing 60 seconds will be
>> denied.
>>> Many ssh servers will allow several attempts at passwords and the hamvoip
>>> server allows up to 6 failures before it disconnects you.  As long as you
>>> don't exceed 4 connections in 60 seconds (one attempt every 20 seconds)
>>> this rule will never activate, and if you pause for 60 seconds it will
>>> automatically clear the offending address from the firewall. this means
>>> that you could try 24 combinations in 60 seconds then pause for 60
>> seconds
>>> and try all over again.
>>>
>>> I use a slightly different version that I will explain below.
>>>
>>> iptables -A INPUT -p tcp --dport 22 ! -s 192.168.12.0/27 -m conntrack
>>> --ctstate NEW -m recent --set --name SSH
>>> iptables -A INPUT -p tcp --dport 22 ! -s 192.168.12.0/27 -m conntrack
>>> --ctstate NEW -m recent --update --seconds 600 --hitcount 4 --rttl --name
>>> SSH -j DROP
>>>
>>>
>>> The difference in this command is that any connections from my personal
>>> virtual host network (192.168.12.0/27) is ignored, and I can try as many
>>> times as I like with no fear of getting locked out.  The second part is
>>> that you only have to try 4 times in 10 minutes before you get locked
>> out.
>>> I have also set my ssh server to only allow 3 attempts per connection and
>>> additionally I force the use of ssh keys and never allow passwords to be
>>> entered interactively.
>>>
>>> In my "day-Job" I also record the IP address of repeated failed logins
>> and
>>> generate a list of addresses that I import to the firewall to deny them
>>> before they get a chance.
>>>
>>> I hope this helps someone, and I would be happy to discuss this and help
>>> others that may not be comfortable at the command line.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, May 17, 2018 at 3:12 PM, "Charles Powell via arm-allstar" <
>>> arm-allstar at hamvoip.org> wrote:
>>>
>>>> I have tacked my last rule as an addition to Doug’s (WA3DSP)’s iptables
>>>> entry for Supermon.  One note - since I have dynamic DNS at all points
>>> for
>>>> my nodes, I do NOT run this in a cron tab.  I use the name instead of
>> IP
>>> in
>>>> Doug’s script.  That way I only run the script at boot from
>> /etc/rc.local
>>>> and does not get flushed out every 10 minutes or whatever the interval
>>>> was.  So here is my addition to the end of the file:
>>>>
>>>>
>>>> iptables -A INPUT  -p tcp -m tcp --dport 222 -m state --state NEW -m
>>>> recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j
>>> DROP
>>>> # Use this statement at the Linux prompt to view results # iptables -L
>>>>
>>>> # EOF
>>>>
>>>>
>>>> So when the hitcount gets to 4 with an incorrect password, that IP is
>>>> dropped and my node becomes invisible.  I couple that with redirecting
>> my
>>>> incoming port in my router.  Between the two, my log is clean and clear
>>> of
>>>> hacking attempts.  If you are using a different port ON THE LOCAL
>> MACHINE
>>>> (not at the router) make sure you change the -dport ‘???’ entry.  Doug
>>> has
>>>> a fine HowTo on setting up iptables for Supermon.  As I said, I do not
>>>> refresh it because there is no need with a dynamic DNS at each
>>>> router/access, provided you use the name and not an IP address.  I use
>>> NoIP
>>>> for dynamic assignments and although I have to verify once a month, it
>>> has
>>>> never failed to update the IP within a few minutes.  The NoIP system
>>>> reminds me with an e-mail a couple of days before the confirmation is
>>> due,
>>>> and it’s free that way.
>>>>
>>>> 73,
>>>>
>>>> Charles - NK8O
>>>>
>>>>> On May 17, 2018, at 7:14 AM, k6cks01 via arm-allstar <
>>>> arm-allstar at hamvoip.org> wrote:
>>>>> That is very interesting Charles, would you be interested in sharing
>> an
>>>> example of your script?Rory, K5CKS
>>>>>
>>>>> Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone
>>>>> -------- Original message --------From: Charles Powell via
>> arm-allstar
>>> <
>>>> arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org>> Date:
>> 5/16/18
>>>> 9:55 PM  (GMT-06:00) To: ARM Allstar <arm-allstar at hamvoip.org <mailto:
>>>> arm-allstar at hamvoip.org>> Cc: Charles Powell <5h3dx.zinga at gmail.com
>>>> <mailto:5h3dx.zinga at gmail.com>> Subject: Re: [arm-allstar] Firewall
>>>> thoughts ---was:Trouble with Supermon
>>>>> Remember it is still possible to write an IP tables rule that blocks
>> an
>>>> attacker after the 3rd (or whatever number you choose) attempt with an
>>>> incorrect password   It is VERY effective.  A log with a brute force
>>> attack
>>>> will have pages and pages of information from the same IP address.
>>> Between
>>>> diversion and a good IP tables script, I see absolutely no hack
>> attempts.
>>>> I take that back.  I had one - that was shutdown on password #4.
>>>>> 73,
>>>>>
>>>>> Charles - NK8O
>>>>>
>>>>>> On May 16, 2018, at 9:48 PM, David McGough via arm-allstar <
>>>> arm-allstar at hamvoip.org> wrote:
>>>>>>
>>>>>> My opinion is that pre-shared keys for SSH are a great step in the
>>> right
>>>>>> direction. But, leaving it on port 22 might still lead to problems.
>>>> First,
>>>>>> this is still a TCP port, and it can be impacted by protocol-level
>>>> (level
>>>>>> 3 or level 2) attacts. If nothing else, it might lead to a DoS
>>>> condition.
>>>>>> Second, even with pre-shared keys, the ssh daemon leaks information.
>>>> For
>>>>>> example, on my system with ssh passwords disabled:
>>>>>>
>>>>>> mcgough at david-vb:~$ telnet 192.168.232.111 222
>>>>>> Trying 192.168.232.111...
>>>>>> Connected to 192.168.232.111.
>>>>>> Escape character is '^]'.
>>>>>> SSH-2.0-OpenSSH_7.2
>>>>>>
>>>>>>
>>>>>> So, with this info, I can rapidly determine that the sshd is present
>>>> and I
>>>>>> can determine it only seems to allow PSK authentication. So, I
>> change
>>>> my
>>>>>> attack strategy!
>>>>>>
>>>>>>
>>>>>> 73, David KB4FXC
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 16 May 2018, "Jeff Karpinski via arm-allstar" wrote:
>>>>>>
>>>>>>> Really should disable password SSH logins. Limit to pre-shared keys
>>>> and it won’t matter what bit what port you use. 22 is fine.
>>>>>>
>>>>>>> On May 16, 2018, at 7:18 PM, David McGough via arm-allstar <
>>>> arm-allstar at hamvoip.org> wrote:
>>>>>>>
>>>>>>> Hi Guys,
>>>>>>>
>>>>>>> I haven't commented much about the firewall / open ports issue, so
>>>>>>> far...I've been really busy this week.
>>>>>>>
>>>>>>> Anyhow, I agree with Tony that "security by obscurity" is indeed a
>>>> viable
>>>>>>> strategy to reduce the number of drive-by port scans and attacks.
>>> But,
>>>> the
>>>>>>> ports you choose must truly be OBSCURE! For example, with a SSH
>>> server,
>>>>>>> ports 22, 222, 2022, 2222, 4022, etc., (most everything ending in
>>>> "22")
>>>>>>> will get rampantly scanned!!  But, put ssh on port 7589. Nada! Not
>> a
>>>>>>> single scan!
>>>>>>>
>>>>>>> There are a number of excellent tools for Linux which will help
>> with
>>>>>>> understanding what ports are open and the traffic on your network,
>>>> too.
>>>>>>> Some are: netstat, nmap and tcpdump/wireshark.
>>>>>>>
>>>>>>> Running a "netstat -anp" (as root) on your local Linux box show all
>>>> the
>>>>>>> current network bindings, including open ports, connections to
>> ports,
>>>> etc.
>>>>>>> The nmap program is a "hackers wonderland" ...nmap is a robust tool
>>>> which
>>>>>>> will allow you to actively probe networks looking for open ports,
>>>> hidden
>>>>>>> devices, etc. Just do BE AWARE that if you probe someone's network
>> on
>>>> the
>>>>>>> Internet, you'll likely trip intrusion alarms!!! This type of
>>> Internet
>>>>>>> probing is also a violation of most ISP's acceptable use
>> policies--so
>>>> be
>>>>>>> careful with this tool!!!!
>>>>>>>
>>>>>>> tcpdump and wireshark/tshark help round out your network analysis
>>>> toolkit!
>>>>>>> These tools allow you to "sniff" all the traffic passing through a
>>>> network
>>>>>>> interface by placing the interface in promiscuous mode---meaning it
>>>>>>> reports anything it can hear, whether destined for its IP address
>> or
>>>> not.
>>>>>>> I won't get into the details about these scanners in this message
>> or
>>>> I'll
>>>>>>> be writing a novel--these tools are VERY sophisticated! For
>> example,
>>>> you
>>>>>>> can use them to sniff plain-text passwords or even passively
>> monitor
>>>> and
>>>>>>> PLAY the actual audio traffic from Asterisk/AllStar!
>>>>>>>
>>>>>>>
>>>>>>> Finally, I want to mention that firewalls are not the end-all
>> be-all
>>> of
>>>>>>> security and they can lull you into a FALSE sense of security! Here
>>> is
>>>> an
>>>>>>> example of how this is frequently true: Lets say that your system
>>> has 3
>>>>>>> ports open: port tcp/222 (ssh), port tcp/80 (http) and port
>> udp/4569
>>>>>>> (IAX2). You setup a firewall and block everything, but open
>> pinholes
>>>> for
>>>>>>> the 3 ports listed above. Your firewall allows everyone to connect
>> to
>>>>>>> these ports, no restrictions....So, what have you accomplished with
>>>> the
>>>>>>> firewall????  NOTHING!  ....I'll end on this note as something to
>>>> ponder.
>>>>>>>
>>>>>>> 73, David KB4FXC
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 16 May 2018, "Tony Ross via arm-allstar" wrote:
>>>>>>>
>>>>>>>> While some people would criticize such alternate ports for wks
>>>>>>> (well-known services) as "security by obscurity", it does work.
>>>>>>>
>>>>>>> I had a repeater owner ask for my help, as one of his irlp nodes
>>>> seemed
>>>>>>> to not respond to ssh client requests; he couldn't log in remotely.
>>> It
>>>>>>> was difficult, but I eventually found a prompt. I immediately
>> looked
>>>> at
>>>>>>> /var/log/* and found some very large syslog files. Looking at their
>>>>>>> contents showed an ssh attack on port 22, so I changed the port to
>>>>>>> something in a different range, re-started the sshd and the problem
>>>> stopped.
>>>>>>> Using simple system tools such as grep, sort, awk, uniq and wc, it
>>> was
>>>>>>> easy to find that > 3.7 million ssh attempts in 4 days from 4
>>>> east-Asian
>>>>>>> IP addresses had essentially crippled the system.
>>>>>>>
>>>>>>> It did speak well for his choice of passwords though.
>>>>>>>
>>>>>>> On 05/15/2018 07:19 PM, "Charles Powell via arm-allstar" wrote:
>>>>>>>> I use a port in the 9000s because it is an unexpected service
>> there.
>>>> Your mileage may vary.
>>>>>>>> 73,
>>>>>>>>
>>>>>>>> Charles - NK8O
>>>>>>>>
>>>>>>>>> On May 15, 2018, at 12:59 PM, Doug Crompton via arm-allstar <
>>>> arm-allstar at hamvoip.org> wrote:
>>>>>>>>> Typically port 8080 is used but you can use high number if that
>>> does
>>>> not
>>>>>>>>> work. Here are three examples - 15700, 16300, 17400  but you are
>>> not
>>>>>>>>> limited to them.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *73 Doug*
>>>>>>>>>
>>>>>>>>> *WA3DSP*
>>>>>>>>>
>>>>>>>>> *http://www.crompton.com/hamradio <http://www.crompton.com/
>>> hamradio
>>>>> *
>>>>>>>>>
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> arm-allstar mailing list
>>>>>>> arm-allstar at hamvoip.org
>>>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>>>>
>>>>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>>>>> _______________________________________________
>>>>>>
>>>>>> arm-allstar mailing list
>>>>>> arm-allstar at hamvoip.org
>>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>>>
>>>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>> arm-allstar mailing list
>>>>>> arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org> <mailto:
>>>> arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org>>
>>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar <
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar> <
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar <
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar>>
>>>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org <
>>>> http://hamvoip.org/> <http://hamvoip.org/ <http://hamvoip.org/>>
>>>>> _______________________________________________
>>>>>
>>>>> arm-allstar mailing list
>>>>> arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org>
>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar <
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar>
>>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org <
>>>> http://hamvoip.org/>
>>>>> _______________________________________________
>>>>>
>>>>> arm-allstar mailing list
>>>>> arm-allstar at hamvoip.org <mailto:arm-allstar at hamvoip.org>
>>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar <
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar>
>>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org <
>>>> http://hamvoip.org/>
>>>> _______________________________________________
>>>>
>>>> arm-allstar mailing list
>>>> arm-allstar at hamvoip.org
>>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>>
>>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>>>
>>>
>>>
>>> --
>>> DE KA7FHA
>>> --
>>> Some carbon based operating systems should be left with no accessible
>>> keyboard or mouse
>>> _______________________________________________
>>>
>>> arm-allstar mailing list
>>> arm-allstar at hamvoip.org
>>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>>
>>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>> _______________________________________________
>>
>> arm-allstar mailing list
>> arm-allstar at hamvoip.org
>> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
>>
>> Visit the BBB and RPi2/3 web page - http://hamvoip.org
>>
>
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________

arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar

Visit the BBB and RPi2/3 web page - http://hamvoip.org