Greetings.
Lately my small amateur server been severely flooded with similar
activities:
Nov 21 22:54:01 linux postfix/smtp/smtpd[26048]: connect from
unknown[200.7.249.218]
Nov 21 22:54:02 linux postfix/smtp/smtpd[26048]: disconnect from
unknown[200.7.249.218]
Nov 21 22:55:01 linux postfix/smtp/smtpd[26048]: connect from
unknown[83.70.149.33]
Nov 21 22:55:04 linux postfix/smtp/smtpd[26048]: disconnect from
unknown[83.70.149.33]
Nov 21 22:56:59 linux postfix/smtp/smtpd[26066]: connect from
mail.devaney.net[96.91.214.49]
Nov 21 22:57:00 linux postfix/smtp/smtpd[26066]: disconnect from
mail.devaney.net[96.91.214.49]
Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: connect from
unknown[83.70.149.33]
Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: disconnect from
unknown[83.70.149.33]
Nov 21 23:02:27 linux postfix/smtp/smtpd[26203]: connect from
unknown[186.33.182.12]
Nov 21 23:02:28 linux postfix/smtp/smtpd[26203]: disconnect from
unknown[186.33.182.12]
Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: connect from
unknown[unknown]
Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: disconnect from
unknown[unknown]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: connect from
unknown[50.126.82.18]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: lost connection after HELO
from unknown[50.126.82.18]
Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: disconnect from
unknown[50.126.82.18]
System logs were building up very fast!
Created new entries for fail2ban porogram and got rid of this in a few
minutes time!
In jail.local file added:
[postfix-auth]
enabled = true
filter = postfix.auth
action = iptables-multiport[name=postfix,
port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath = /var/log/mail.log
In filter.d folder added new filter postfix.auth.conf with regex:
#
failregex = ^%(__prefix_line)slost connection after (AUTH|UNKNOWN|EHLO) from
(.*)\[<HOST>\].*
^%(__prefix_line)sconnect from unknown\[<HOST>\].*
^%(__prefix_line)swarning: hostname.*
ignoreregex =
#
>From now on NO MORE such crap!!!
Best regards.
Tom - SP2L
Speaking of documentation...
Every once and a while I get an email from someone, and it's not clear
to them how the IP space is useful, "since everyone on the internet
already has a publicly routeable address."
Maybe that can be made clearer some where? Just a suggestion.
> Ah, I stand corrected; I've updated the entry. The section on 44.128/16 was
> pointing to an obsolete article that incorrectly gave the impression that
> that subnet was unroutable like an RFC1918 network, whereas it's really just
> reserved for testing.
> Unfortunately, there's an article on www.eastnetpacket.net that incorrectly
> states that it *IS* an RFC1918-style network and people outside the AMPRNet
> are quoting it as justification for using the network AS an unrouted network.
Well, that amprnets.txt file of course has existed and has been maintained on
hamradio.ucsd.edu for many many years. I have 3 old copies and all of them mention
that it may be assumed that any packets with 44.128 addresses are bogons, so
this text has probably been there for at least a decade if not much more.
Currently this file does not exist anymore at hamradio.ucsd.edu, I presume its
function has been taken over by the "networks" menu item at portal.ampr.org.
However, that listing does not mention 44.128.0.0/16 at all. When it is desired
to change the definition of this subnet, it may be better to provide an explicit
new definition, instead of trying to remove the old definition from internet
without providing a new one.
I think that is not going to work well, given the way information is stored,
copied and archived on the web.
Also note that this information on portal.ampr.org is only available to registered
users, so it would be wise to put some information on a publicly available site
as well (maybe a description of the subnetting of net 44 at the top level without
all that country-specific info). That could be on the www.ampr.org site.
Rob
There are some rather troublesome inaccuracies in the Wikipedia
article on the AMPRNet. Does anyone on this list have edit privileges
on this page so those could be corrected?
- Brian
Quick question: why is 44.127/16 listed as "No Country" on the portal? How
are the subnet allocations different from allocations that belong under a
specific country?
Thanks,
Assi
Hi Brian,
I don't see the rip broadcasts from ucsd to my gateway at 69.165.175.62
since a couple days. I'm still in the encap.txt and I still see the
regular packets routed by ucsd.edu addressed to my subnets coming in.
Something wrong at that end?
Bob (Boudewijn) VE3TOK
--
There is nothing permanent except change
Heraclitus
> I've tried a few other things with no avail at this point.
Put a monitoring device at the outside port, or start a data capture in the router itself when EdgeOS can
do that, and then check what is arriving when you do the outside ping.
When you see packets coming from 169.228.66.251 addressed to your external IP with protocol field 4 you
at least know the external causes are covered. You can then concentrate on the setup of your router.
When no such packets appear, the problem is in your gateway setup at portal.ampr.org or your DNS entry.
As I don't see your callsign or AMPRnet IP anywhere in your message I can't do much research...
Rob
The host 'hamradio.ucsd.edu' will be offline some of Monday to
upgrade its operating system. Services such as this mailing
list and the DNS robot will be unavailable during that time.
- Brian
> Any ideas? I feel like I did configure the tunnel correctly, but I don't
> see anything on the LAN. Will post config if needed.
Your gateway config looks OK to me.
Your route entry appears in our gateway:
44.98.17.32/27 via 73.1.142.180 dev tunl0 proto ampr-ripd metric 4 onlink
(of course useless for us, because the method described on the WiKi does not
provide connectivity for gateway stations other than amprgw)
I can ping your external address.
Maybe Comcast or the modem is filtering IPIP?
Rob
