Unauthorized user attempt

[kinmun]

i noticed that there are quite a number of unauthorize user trying to gain access to my firewall.

other than removing ssh n https access, is there anything else i can do ?

[neonbit]

A few things I could recommend if you don't want to disable ssh/https access from your WAN port:

1. Change the port numbers for HTTPS (443) and SSH (22) from the default ones

2. Use 2 factor authentication for all the admin logins (the FortiGate comes with two free mobile tokens)

3. If you know the IP address that you'll be connecting from for the admin access, then add these to the trusted hosts (configured under each administrator account)

[gschmitt]

neonbit wrote:

A few things I could recommend if you don't want to disable ssh/https access from your WAN port:

Personally, I would only ever enable Administrative Access on your wan port temporarily. I rather use VPN to dial in to access the device

[nothingel]

I have used the restrict IP functionality of admin accounts and even changed ports but I grew tired of unknown people attempting to login anyway (using common names like "root"). Normally the IP restrictions would prohibit all untrusted IPs from even connecting but I always used a dummy user with no IP restrictions so that the administrative services would still be open because I wanted PING to work.  (I've often wished PING could be controlled separately from the other administrative services.)

Presently, I've moved the administrative ports back to their defaults but use a local-in policy (CLI only) to first exempt trusted IPs followed by another policy to block all access to the administrative ports.  Now, nobody except trusted IPs can attempt connections via HTTPS or SSH but PING still works from anywhere.

I wish local-in policies could be viewed from the GUI.  I don't care about editing as much as the ability for somebody else to have a clue what I've done.  I'm talking about 5.0.x here, FWIW.

[gschmitt]

nothingel wrote:

I wish local-in policies could be viewed from the GUI.  I don't care about editing as much as the ability for somebody else to have a clue what I've done.  I'm talking about 5.0.x here, FWIW.

Uhm... they are? Go to System > Config > Features select Show more turn Local In Policy On and Apply

[nothingel]

gschmitt wrote:

Uhm... they are? Go to System > Config > Features select Show more turn Local In Policy On and Apply

Yes, you're right, but they don't show user-generated policies.  I should have more clearly stated this in my post.  The only thing I see are policies controlled by the system.  Again, this is in 5.0.x.

[sym]

nothingel wrote:

Presently, I've moved the administrative ports back to their defaults but use a local-in policy (CLI only) to first exempt trusted IPs followed by another policy to block all access to the administrative ports.  Now, nobody except trusted IPs can attempt connections via HTTPS or SSH but PING still works from anywhere.

I wish local-in policies could be viewed from the GUI.  I don't care about editing as much as the ability for somebody else to have a clue what I've done.  I'm talking about 5.0.x here, FWIW.

Went the same route as you. Using local-in-policy definitions to define what's allowed to wan1:

[ul]

Allow PING from All 

Allow TRACEROUTE from All

Allow HTTP, HTTPS, SSH, SNMP from trusted Networks

Deny HTTP, HTTPS, SSH for All.[/ul]

Took me a while to figure out that I needed to create a Service Object definition for the HTTPS Port I moved on WAN1 (9431) .

So my ruleset looks like this:

config firewall local-in-policy
 edit 1
 set intf "wan1"
 set srcaddr "all"
 set dstaddr "all"
 set action accept
 set service "PING"
 set schedule "always"
 next
 edit 2
 set intf "wan1"
 set srcaddr "all"
 set dstaddr "all"
 set action accept
 set service "TRACEROUTE"
 set schedule "always"
 next
 edit 3
 set intf "wan1"
 set srcaddr "TRUSTED_IP_GROUP"
 set dstaddr "all"
 set action accept
 set service "HTTP" "HTTPS" "SSH" "SNMP" "PING"
 set schedule "always"
 next
 edit 4
 set intf "wan1"
 set srcaddr "all"
 set dstaddr "all"
 set service "HTTP" "HTTPS" "SSH" "HTTPS_9431"
 set schedule "always"
 next
end

[nothingel]

sym wrote:

Went the same route as you. Using local-in-policy definitions to define what's allowed to wan1:

[ul]

Allow PING from All 

Allow TRACEROUTE from All

Allow HTTP, HTTPS, SSH, SNMP from trusted Networks

Deny HTTP, HTTPS, SSH for All.[/ul]

I'm glad you found this useful!

In my case, I found no reason to explicitly allow ICMP-type traffic in the local-in policies.  I would be interested to know if your testing revealed anything that I perhaps overlooked.

[sym]

nothingel wrote:

In my case, I found no reason to explicitly allow ICMP-type traffic in the local-in policies.  I would be interested to know if your testing revealed anything that I perhaps overlooked.

You mean other ICMP traffic than PING and TRACEROUTE? Same with me. Doesn't seem useful unless you have edge cases you need to support. 

I personally find it quite strange that Fortinet sees PING as administrative requests. Coming from Juniper / Netscreen, it is much more easy to configure PING / Traceroute on WAN from ANY there...

[HA]

Hello,

I personally used the following method.

First, I create an admin profile with NONE privilege.

Next, a create a user 'called it PING' with the NONE profile and NO IP restriction (to allow ping from everywhere).

Next, I limit the admin user to specific IP Range.

The external user can still try to connect but even if they discover the PING password, no privilege will be granted...

Regards,

HA