Hello,
We have one Ubuntu Server there we have enabled SSH and now I'm trying to provide SSH access for some users, but I would like to apply application control to the rule. In rule I added SRC, DST, User Group and Port (TCP 22), then created application group, where I blocked all applications but enabled SSH Applications (did override), but users can't access to the server. But then I added to this application rule also one override rule, where select also "Canonical Ubuntu" application and then users received access.
But in this "Canonical Ubuntu" ( https://www.fortiguard.com/encyclopedia/iotapp/10000501 ) I see al lot of protocols (UDP, SNMP, TCP, HTTP, SSH) I need to provide access just to SSH. How I can do It. And also by best practice how do I need to create policy in such cases?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
may I know, why you want add application control to the policy. You can simply add service ssh to that policy.
HI,
You could achieve this by simply create a Firewall policy with Source, Destination and Service (as SSH-TCP22). So why would you need application control here. What are the objectives ?
If you still want application control, you can create a Application Profile blocking all Application category while adding SSH application to be allow as Override and then call this in the Firewall policy which is created above.
Best Regards,
Yes, I would like to control access by Application, not just with port.
I did as you said, Created separate access control profile, blocked all application and permit just SSH. But users could not have access until I enabled also "Canonical Ubuntu" application.
Hi,
Fair enough, but still in the Firewall policy you only allow service TCP-22 which should restrict any other access other than port 22 for this Ubuntu Server from Layer 4 perspective and you still allowed only the respective application with application control at the Application layer.
Best Regards,
Your advise is allow access with "Canonical Ubuntu" application (which has UDP, SNMP, TCP, HTTP, SSH added) and then also add Just 22 port, correct?
But In this case If I change for example port for HTTP to 22 this rule also allow HTTP traffic with changed port, correct?
Hi,
If you use HTTP on non-standard port (ex: TCP -22), this is where your application control comes into play which only allows "Canonical Ubuntu" and not HTTP Session. In this case your attempt to perform HTTP on port 22 should be blocked as it expected HTTP traffic in port 80 and not 22.
Please test this and let me know the outcome.
Best Regards,
I mean, If I change port on the server side from 80 to 22. It will be allowed, correct?
Application control and other deep level inspection takes place once the firewall policy is matched, firewall policy match happens based on the Interfaces, IP,protocol and port numbers.
So if your application is on port 80, and policy is allowing port22, the traffic won't work even if the application control allows the particular application, same is the case if application control signature allows multiple port but firewall policy allows only port 22. Only traffic on port22 is expected to work.
I understood how works deep inspection, but see:
I would like to enable SSH via fortigate to Ubuntu server.
I tried to enable passing ssh with standard application. It didn't work until I addedd "Canonical Ubuntu" application. In "Canonical Ubuntu" Application I see:
I would not like enable SNMP, HTTP and so on. My question is:
If I allow access from 1.1.1.1 to 2.2.2.2 with 22 port and select this application.
If I have HTTP enabled on 2.2.2.2 and change port from 80 to 22 will Fortigate allow this traffic?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1545 | |
1030 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.