[arm-allstar] Firewall thoughts ---was:Trouble with Supermon
KI7AY
jim at ki7ay.com
Sat May 19 17:00:46 EST 2018
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
More information about the arm-allstar
mailing list