Screen OS

Hi,

There is an ISG firewall with integrated IDP.

I got this crazy requirement from customer.

There is radius traffic (UDP) allowed from Server A to Server B via policy in firewall.

When Server A sents packets to Server B, there will be return packets for the traffic in the same session from Server B to Server A. They want this return to be blocked.

- My understanding is that this is not possible as firewall is stateful device.

-This might be possible on router(stateless) with firewall-filters(junos) or acl(cisco)

Does anyone think that i can block this with an integrated IDP.

Will the IDP behave in a stateful manner or will it make decisions based on flow?

I could set up a rule in IDP like:

1.source:Server-A Source-port: Radius Destination:Server-B Destination-Port:any Action:Permit

2.source:Server-B Source-port: Radius Destination:Server-A Destination-Port:any Action:Deny

Regards,

Haze

Hi Haze,

Configure on the Server B a host route for the server A pointing to a fake IP.

Reduce the timeout for the service in the policy to a minimum and/or enable UDP-flood defence (destination IP limit) to avoid the overflow of the session tables when too many RADIUS requests are generated. You can also configure a session limit in the policy.

Kind regards,

Edouard

You could likely write a custom IDP signature that would drop the traffic, but I would pose the question to the customer of why?  Clearly if you block the return, things will not work, right?  Why not just disallow Server A in Server B's radius allowed clients list? 

Hi,

Fedrick, I agree with you that if it is blocked in one direction, it will not work. Well apparently, the customer is crazy and do not have any idea about how firewalls work. I am also thinking that they are not clear about their own requirement. Anyway, i am meeting the customer today to check if there has been any changes to his requirement.

Edouard, i will try your suggestion of putting a bogus route on server-B if they insist on this. Since it is UDP and there are no acknowledgements, it might work. But i don't know about the rest of the settings that you mentioned as i think the bogus route should be enough.

Regards,

Haze

Hi Haze,

The requirement of the customer is really quite exotic. But who knows, perhaps they want to register the time, when every user starts to work, in the RADIUS server log but do not want to authenticate them.

Despite the connectionless nature of  UDP ScreenOS handles it in very similar manner as TCP. This means that the "session" entries are created and consume the FW resources. Depending on the service used, they are closed on the responce ("well known" predefined services like DNS) or after the timeot has expired (f.i. a custom service). I think that predifined RADIUS service can recognise the response. This can be tested if both "Log on session init" and "Log on session close" are activated in the policy. The closure reason may be "AGE OUT" or "RESP".

Kind regards,

Edouard

Hi all,

The issue has been resolved from customer side. They configured Server-B to not sent replies back to Server-A.

Regarding the requirement of customer, i don't have a full picture but my understanding is that Server-A is already sending radius to another server Server-C. They are trying to do something like mirroring(even though this is not really mirroring) of the packets to another server (server-B) from which it does not expect response back(else their systems would run havok)

Thanks for all your help guys.

Regards,

Hazeen