[arm-allstar] Firewall thoughts ---was:Trouble with Supermon
Mark Grigsby
ka7fha at gmail.com
Sat May 19 16:02:17 EST 2018
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
>
--
DE KA7FHA
--
Some carbon based operating systems should be left with no accessible
keyboard or mouse
More information about the arm-allstar
mailing list