Reality Check On Exposed Ports

[LayerEight]

Let me start by saying I'm not the network guy, I'm more of the endpoint guy. But I'm also kind of the security guy (IT department is, well... lean).

With that being said, on more than one occasion now, I've noticed that we were exposing things we shouldn't via Shodan. We own a block of public IP's. One was the login page to a critical internal service. Another was a recursive DNS server and port 53. The former was an accidental misconfiguration that I brought up and was fixed (looking at the logs it was getting hammered with brute force attempts, as you would expect). The latter, the network guy just didn't know it wasn't a good idea.

I don't pretend to know everything, so I'm just hoping for a reality check on what we still have exposed across multiple public IP's.

We have a FortiGate. We have VPN setup. It requires MFA. I believe it's L2TP with IPsec.

Ports 1701 UDP and 179 are exposed across multiple public IP's that we are using. On Shodan, for 1701, it says something about missing an assigned tunnel ID. Is that the FortiGate's response to the Shodan crawl?

I have a Shodan account, and when I search for other exposed 1701 ports that are identical to ours, there are typically anywhere from 15-20 results across the entire world. That seems.. low.

Does 1701 actually need to be exposed for an L2TP VPN to work? If so, wouldn't it make sense to only expose it on one IP and not all of them?

179 is BGP related. It looks like 3.9 million public IP's expose that. Maybe not as concerned there. Although I look at similar entities public IP's and they don't have that exposed?

3.2 million exposed port 1701. But only <20 matching ours exactly. Others show like a byte array only:

\x01\x80\x08\x00\x00\x00\x00\x00\x02\x80\x08

Or that with 'Specify your assigned tunnel ID' or 'Missing your assigned tunnel ID'.

The network guy is approachable, and I have brought it up. He wasn't sure if our 1701 being exposed had to do with our VPN or he thought maybe it had something to do with "our tunnel to AWS". I told him it seemed VPN related.

Just trying to gain some insight and make sure we're not doing anything dumb. I've found some legitimately scary things before as I'd mentioned, so I feel my feels aren't totally unwarranted. But if I bring it up again, I'd like to have some actual substance instead of speculation. I've tried Googling answers but can't find anything concrete or specific to FortiGates.

Thanks!

[Anthony_E]

Hello,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[Anthony_E]

Hello,

We are still looking for someone to help you.

We will come back to you ASAP.

Regards,

[pminarik · Accepted solution]

UDP/1701 is likely open because by default the L2TP-wizard created config will permit plaintext L2TP without IPsec encapsulation:

config vpn l2tp

    set enforce-ipsec disable*|enable

end

(note: From what I checked, switching this enforcement to enabled doesn't close the port, it just drops the packets)

Assuming your setup is sane and all clients connect via L2TP/IPsec, you should be able to block plain L2TP packets coming to your WAN with a local-in policy like this:

config firewall local-in-policy
    edit 0
        set intf "<wan-interface>"
        set srcaddr "all"
        set dstaddr "all" # or replace with an object for WAN intf's IP
        set service "L2TP"
        set schedule "always"
end

Let me state the obvious out of abundance of precaution: A wise person will implement this when connected locally to the FortiGate, or with a backup access path, NOT while connected to the L2TP tunnel in question. :)

-------------------------

Similar approach is typically applied to BGP.

It will ignore packets coming to your WAN IP from remote IPs that don't match any configured BGP peers, but if you want to close the port completely to "keep things neat", do it as a local-in policy blocking BGP for the relevant interface/IP.

[LayerEight]

Thank you! This is exactly what I was looking for. Really appreciate this response.

Will bring this up with our network admin and hopefully learn a thing or two.