Hi Michael,
TNX for your explanation, but perhaps too complex for a practical application, at least for me :)
Since, in practice, we are not protecting the Fort Knox :) some practical scripts already applied somewhere should be enough effective and easy to apply ...
73, gus
On 10/11/2015 04:39 PM, Michael Fox (N6MEF) wrote:
(Please trim inclusions from previous messages) _______________________________________________ Gus,
The secure approach to firewall rules is to set your default policy to drop, then write rules to allow the specific traffic you want (protocol/port(s), interface(s), source addr(s), dest addr(s)). For example, maybe you only allow telnet to be forwarded from your amprnet interface to your JNOS tunnel interface if it is from 44.x addresses. So you write a rule to allow that. But anything else, including telnet from anywhere else to anywhere else, would be dropped by the default policy.
For the example that started this thread, if you don't use snmp, then don't write a rule. It will be dropped by the default drop policy. But maybe you want to allow snmp from a specific subnet on your own network (where your management hosts are). So you write an accept rule for that. Anything else, including snmp from other source addresses, would be dropped by the default policy.
To check for abuse within the list of allowed traffic, you can use something like fail2ban. You set up match criteria (log message format, how many times, within what time period). If fail2ban finds matches, it writes a firewall rule to ban that host completely for a specified period of time. You can even have it send you email to tell you what was banned, why (which match rule plus a list the matched log entries), and include a whois output for the offending host.
For example, now that JNOS can use a fixed log filename, you can set up fail2ban to scan the JNOS log for login failures and, if found, have fail2ban ban those addresses by automatically adding rules to your firewall config.
The combination of default drop policy and fail2ban on the allowed traffic is very effective.
Michael N6MEF
-----Original Message----- From: 44Net [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Gustavo Ponza Sent: Sunday, October 11, 2015 3:06 AM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Subject: PTD
(Please trim inclusions from previous messages) _______________________________________________ Hi,
for you experts on the matter concerned: how should be the minimal best setup (or how about schools of thought, if any) to protect at best our linux systems?
In particular, as impelling request, how to prevent the following 'non ampr' host to be indefinitely connected to my system?
i0ojj:~$ nslookup 81.174.235.131 Server: 8.8.8.8 Address: 8.8.8.8#53
Non-authoritative answer: 131.235.174.81.in-addr.arpa name = a.comgw.net.
Very TNX!
73, gus
On 10/10/2015 09:15 PM, Brian wrote:
(Please trim inclusions from previous messages) _______________________________________________ Rob;
On Sat, 2015-10-10 at 21:06 +0200, Rob Janssen wrote:
Please MAKE SURE that you block all incoming SNMP traffic from internet
to amprnet!
(especially when you are using community names like "public")
Of course I have that filtered.
The bad guys use SNMP as an attack amplifier. One time I moved a switch to another address and it became exposed, and
within 3 days I had an abuse report.
Now I have a general rule that drops all SNMP at our gateway.
That's what I do here, drop all SNMP out however it doesn't prevent the incoming floods of frames. You have to actually receive them in order to drop them... like amps need to pass 100% through a fuse/breaker to blow it.
I found the source host and it's been halted. The device was a firewall of all things.
(of course the real problem is the ISPs that refuse to implement BCP38,
source address filtering)
In this case, the ISP was behind granting their client permission to attack. Nice policy eh? Reason: *I* was not their paying customer. I could pursue negligence if I wanted to push the issue.