ScreenOS Firewalls (NOT SRX)
Highlighted
ScreenOS Firewalls (NOT SRX)

SSG5 does not block access

[ Edited ]
3 weeks ago

Hello,

My story is very sipmple: I have an ssg5 firewall conected to the internet. Since I do not wish myself any contact from outside, I created a very simple policy rejecting all traffic from any address from untrust to trust.

However this night a server inside my networt recorded a logon attempt. Luckily the connection was blocked, but the problem is, that it was blocked inside by the server, and should be blocked by the firewall.

Any ideas how it is possible?

Regards

6 REPLIES 6
Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

3 weeks ago

The default configuration on the SSG5 would not allow any connections from the internet to your server login.

 

The configuration to look for that would allow this is destination nat and a policy that allows the traffic.  Both must be in place for the connection to go through the firewall.

 

Check the policy at

Policy > Policies

Look for the untrust to trust (default zone) or whatever zone you created for the server.

If this is not in place also confirm there are no untrust to untrust allow policies.

 

If the policy exists it will give a clue as to which destination nat method was used.  Directly in the advanced tab is one version.  If this is not there then there may be a setup on the untrust interface itself under

Network > Interfaces > list

edit your untrust interface and look for setups in the MIP, DIP, VIP tabs

 

If these are not configured then the attacker was internal.  This is actually pretty common.  The attacker has used a malicious link or other method to compromise another computer on your network.  This computer is then used to move laterally to servers and other targets.

 

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

3 weeks ago

Thank you for the answer.

I will start from the end:

1. If my server was compromised from inside, the blocked ip that the server blocked would be an internal one as well (or am I wrong?).

2. Do you mean that if I have a policy rejecting all trafic from untrunst to trust, and at the same time some VIPS configured in my untrust interface, then it will still allow this traffic??? (the only other policy is from trust to untrust - allow, otherwise no other policies).

3. As mentioned in 2, the only active policies are:

a. Untrust - trust - reject (no nat in advance settings, nothing else configured there)

b. Trust - untrust - allow

c. Trust - trust (two internal subnets) - allow

Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

3 weeks ago

Hi Kordian,

 

1) The blocked IP by the server should be an internal one. However, there is always a chance the attacker is trying to spoof the IP address using some software hiding the actual IP address.

 

2) Even if a VIP is configured, that has to be used in a policy to allow traffic from untrust to trust.

 

3) With the policies you have, there is no chance for anyone beyond the firewall to pass through and reach the server. Infact, the first policy i.e. Unturst-trust - reject is not necessary on a firewall as the default action on the firewall with no policy configured is a default deny. Traffic is not allowed until and unless you have a policy exclusively configured for that address range.

 

Hope this helps.

 

Thanks and Regards,

Pradeep Kumar M

 

|| If this solves your problem, please mark this post as "Accepted Solution" so we can help others too ||

Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

[ Edited ]
3 weeks ago

Thank you!

And sorry to inform, that this answer does not help - it makes it even more confusing. :-)

The only advantage is that I am now sure everything was correctly setup.

My network is a private small network with phisical access for me only in a tiny small village. The attack took place during the night, while all in the house were sleeping. I noticed many "Dst IP session limit!" and "IP spoofing! From" alerts (what on Earth do ip addresses from USA want from me and my firewall???)

Sorry, but it does not make sense.

I also have screening enabled on my untrust interface. Changed the DoS thresholds to 1, maybe they will leave me in peace...

Regards

Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

3 weeks ago

Can you confirm that there are no untrust to untrust policies?

This is another vector that  can be used if there right vip/dip/mip are configured.

 

Were you able to confirm that the untrust interface does not have vip/dip/mip configured?

this message makes me think you do have some kind of forwarding configured that may be used by this external threat.  If you are not publishing a server to the internet these should be removed.

"Dst IP session limit!"

 

The"IP spoofing! From" alert indicates the firewall knows the addresses are being forged and the attack is more on the DoS side than a compromise attempt.

 

Once all possible policy and nat forwarding methods are off, there is no way the traffic from the untrust side would be forwarded to your internal network.

 

By an internal attack, what I meant was a computer on your internal network has been hacked and is now a platform for external agents to use for lateral internal movement.  Have a close look at computers connected to the network that are left on overnight for indicators of being compromised.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Highlighted
ScreenOS Firewalls (NOT SRX)

Re: SSG5 does not block access

3 weeks ago

Yes, I can confirm there are no untrust to untrust policies.

The untrust interface has one VIP port enabled. You mentioned previously however, that with the reject policy this should not apply. I will remove it.

As for internal attack, all possible computers were off at this time. Only one phone with access to WLAN had this access. WLAN access is restricted to selected mac devices as well. So very much unlikely, I would say.

This was the second time such an incident occurs, I ignored the first one, but now I am worried, especially since I have been using these firewalls elsewhere.

Regards