Fortigate listening on port 8009

Port 8009 is used to download the Forticlient software from the portal. Try searching the policy that enables it on your wan interfaces and disable it if you don' t need it. config firewall local-in-policy edit <policy_number> set status disable end Regards.

8009

Just create a local firewire policy and custom service with a deny action config firewall service custom edit " port_8009_tcp" set protocol TCP/UDP/SCTP set tcp-portrange 8009 next end config firewall local edit 0 set intf " wan1" set srcaddr " all" set dstaddr " all" set service " port_8009_tcp" set schedule " always" next

I wish they let me modify the local in policies

What do you mean " wish the let you modify" you can.See the 2nd post ( by me ), you have the ability to filter anyting that ' s local no different than a juniper SRX . if you think about it. the allowaccess and local-in-policy is the exact same things on juniper SRX ( system services ) but 100x more effective and easier imho ( Okay not 100X better but 10 times better ) if you would execute the sample policy provided, you will see that 8009 would be close on a followup scan.

I should not need to create a deny rule as the default deny all rule should cover it since there is no higher priority/ordered policy specifically allowing it.

fwiw, regular fwpolicies ipv4 or ipv6 has nothing todo with this.

Repeat after me cli cli cli cli It ( fortigate ) is the same or similar to a juniper SRX to some degree. So if it can be done in a SRX, it probably be done on a FGT but simpler. And uses the same concept ( per-se ) and the fortinet engineers took what juniper did and made it smarter. And the WebGUI is slicker and quicker :) So yes you can do EVERYTHING in the CLI actually more than what you can do in the WebGUI. I spend approx 90% of my days work in CLI mode. fwiw; I don' t know of one fortigate model that will NOT allow you to modify local-in-policies if it has support for in policies.

Maybe the concept of this is not yet clear enough: Port 8009 is used for traffic to/from the FGT itself. It does not have anything to do with traffic that is controlled by the FGT (streaming through it). FGT generated traffic is controlled by ' local-in' /' local-out' policies. Regular policies (which you have tried) only control traffic passing through the FGT. Sometimes ' local-in' policies are visible in the policy table but are NOT directly editable. Take for example the ' allowaccess' settings in the interface setup. Checking one of these options will generate or modify a ' local-in' policy (but the other way around is not allowed). And, depending on GUI settings (' features' ) and on hardware model local-in policies might only be modified in the CLI, as emnoc already stated. Esp. the smallest FGTs (20, 30, 40) do not have all GUI options available. And yes, it' s debateable whether a firewall should have open ports after a ' factory reset' or not. I bet that if service ports were closed Customer Support would see a sharp rise in support calls though.

Ouch Let me try to clear some things up. The local in policies are normally executed from the cli, ( I don' t think it' s available in the WebGUI nor any methods to enabled in the WebGUI ....someone correct me if I' m wrong ) By default there' s no local-in policies installed The default action is to allow all in, where in comparison with SRXes you have to turned it on and allow it ( this could bad to some degree or in SRX platform it cause a lot of other problems like ..." Hey, OSPF does work!" ) when you execute the show firewall local your results will be nothing ( no policies exists by default compared to a chkpt, SRX, and my favorite = Another Sorry Appliance , the fortinet is proably the easiest and most effective means for traffic controls once again imho and experience. yes this function is not regularly used or even known, but it' s highly effective and useful It not wide spotlighted by most firewall engineers But compared to the 3 above mention firewalls, the fortinet is probably hands down the best with regards to local-in

Having all these ports open by default (specially for disabled or unused features) is another big strike in my mind.

Fortinet for ages has maintained a list of services that are used BY all fortinet products. You and every engineer ( fortinet ) should be aware and review these on a regular basis. As engineers, we should do ports scan against our hardware b4 and after implementation to find anything that might be exposed. Fortinet does a good job with passing knowledge and never hides anything once again imho and based on experience with dealing with them for 9+ years. I would take a fortigare over most other vendors products in a heart beart. Even where the fail or weak at, they are still far advance the pack in a lot of other areas. btw, here' s the list of common ports and services directionality http://kb.fortinet.com/kb/viewContent.do?externalId=10773 You can also use a combination of these cli cmds diag sys tcpsock fnsysctl cat /proc/net/tcp <-----you will have todo some hex converison

I totally agree with emnoc on all points but I can see your frustration. Maybe your expectations were too high in the beginning, like having an all-GUI management. I' ve seen the CP GUI and wonder how many drill lessons it takes to handle it. Totally overloaded IMHO. So each vendor makes decisions between completeness of tools and ease of use for everyday tasks. Bloated GUIs tend to lead to errors on my side because I' ve been overlooking a setting. For me, it' s enough to know that there is a feature or parameter which I can use to achieve my goal even if it' s only available in the CLI. After all, a Fortigate is Linux based like all the others, so a CLI comes in naturally. Now, the reason why I' m posting at the moment is a warning: the ' fnsysctl' command that emnoc posted is a direct call to the filesystem. You do have to know what you are doing or it will wreak havoc on the system. This definitely is dangerous, and IMHO not necessary for what you are trying to achieve. Be warned. A bit of history: in the beginning, only a few ports were open to support FortiOS (like FortiGuard ports). Then, more services were demanded by the users. Then Fortinet documented the list of ports used to facilitate audits. And even some while later they introduced editable local policies. Local policies had been in place all the time but only in the last few revisions of FortiOS they have been made accessible following user demand. In short: FortiOS is an OS in development. User demand is driving the features that are available. But expecting an all-GUI based management is probably too much, and not intended for good reasons. If you don' t see local-in policies in the CLI then just create one. Might be unexpected but sometimes it works this way.

There' s also a neat pdf that shows the ports used by FortiGates/Analyzers and Managers. I' ve uploaded it here:

http://speedy.sh/e5mHY/Ports-Used-by-Fortinet.pdf

fully agree with ede_pfau and emnoc! And about the missing GUI features....I remember pretty well those times with Novell Netware and an Admin always had to KNOW what he did within the CLI. Later on with Windows Servers, every noob was able to click around the GUI and the problems started So I really don' t mind a well documented CLI for a few features instead a GUI for a Firewall, this gives me the certainty that only people with the knowledge are able to change settings and not anyone who can just move a mouse