<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'>That you have some ACLs that whack low-hanging fruit doesn't negate the fact that you can't block the untrusted Internet accessing an intentionally publicly accessible port.<div><br></div><div>It's all just a distraction from the fact that *SOME* services *MUST* remain available to the general public and those services are subject to abuse.</div><div><br></div><div><br></div><div>As long as there are things that must be available to the general public (likely forever), there needs to be an abuse reporting process that works.<br><br><div><span name="x"></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br>http://www.ics-il.com<br><br>Midwest-IX<br>http://www.midwest-ix.com<span name="x"></span><br></div><br><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Stephen Satchell" <list@satchell.net><br><b>To: </b>nanog@nanog.org<br><b>Sent: </b>Wednesday, April 29, 2020 12:35:20 PM<br><b>Subject: </b>Re: Abuse Desks<br><br>On 4/29/20 9:57 AM, Mike Hammett wrote:<br>> My routers have ACLs, but my servers for the most part do not.<br><br>I'm not trying to argue, but...what servers do you have that don't have <br>sysadmin-definable firewalls and tun-able knobs? My edge routers are <br>Linux boxes (CentOS 8 for the one I'm now building). Moreover, I can <br>have NetworkManager fire off a script that modifies the firewall <br>settings as interfaces go up and down.<br><br>> It's kind of counter productive to put ACLs on SMTP, POP3, IMAP, and<br>> HTTP\S ports, now isn't it? SIP, FTP, and SSH may or may not make<br>> sense, depending on the type and volume of users.<br>I was taught by my networking betters that you need to block certain <br>types of public inbound packets, always, that match any of:<br><br>1. WAN packets with local/LAN source address<br>2. WAN packets with local/LAN broadcast/net src-dst address<br>3. WAN packets with known broadcast/net src-dst address<br>4. WAN packets with local/LAN small services<br>5. WAN packets with local/LAN unimplemented services<br>6. WAN packets with blackholed source address<br><br>On EVERY device with a public IP address. WITHOUT FAIL.<br><br>I have these blocks on every single public-facing mail server I build. <br>I have these blocks on every single public-facing Web server I build. <br>Indeed, I can't fathom why I would *not* have these in place for every <br>single public-facing device. I don't necessarily log every occurance, <br>but I do drop matching packets on the floor, unceremoniously.<br><br>This is the foundation upon which I build custom additions, such as <br>allowing 22/tcp only from specific IP addresses.<br><br>I don't depend on the edge router to catch all the cases, because each <br>server has specific services it provides. So, for example, my DNS <br>servers not only implement all six basics, but also incorporates request <br>rate limiting, to avoid participating in DDOS events. Ditto NTP <br>servers. 80/tcp and 443/tcp? Dropped on the floor.<br><br>Sorry to preach, but I'm in the process of building a NFTABLE-based <br>firewall and this happens to be part of the specs for it.<br></div><br></div></div></body></html>