Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
zack
New Contributor

Fortigate listening on port 8009

Hello My fortigate appears to be listening on port 8009 on our internet connected interfaces. Not cool. How do I turn that garbage off? I can;t find it anywhere in the GUI or CLI guide and I must be missing something.
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
16 REPLIES 16
zack
New Contributor

.....so I tried to just view the local-in-policies int he cli and nothing comes up... get firewall local-in-policy returns nothing show firewall local-in-policy returns: config firewall local-in-policy but no rules or other info....
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
ede_pfau
Esteemed Contributor III

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.

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
zack
New Contributor

I' m getting the concept but just don' t care for the implementation. The lack of a GUI support for these features is a big strike against the manufacturer in my mind. Having all these ports open by default (specially for disabled or unused features) is another big strike in my mind. The CLI also doesn' t seem to be implemented well either. I can' t even view these local-in policies from the CLI. Commands are returning no results. Dumping the entire system config and searching it only shows settings for them when it comes to logging. So yea - this is particularly frustrating. Seems half baked to me.. Support advised me to create a rule (like a prior poster) which also did not close the port. They' ve since gone dark on me with no additional suggestions. That' s strike 3... All of these things have me wondering if Fortinet will continue to be the right choice for us come service renewal time.
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
(2) FortiGate 300A (clustered) 4.2.9 (1) Fortigate 310B 4.2.9 (1) Fortianalyzer 100C 4.2.4
emnoc
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau
Esteemed Contributor III

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.

Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
neonbit
Valued Contributor

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
Wayne11
Contributor

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
Labels
Top Kudoed Authors