topic Re: Connection issue in Network Security

Connection issue

sgoethals1 — Mon, 11 Mar 2019 10:58:13 GMT

Hi Folks,

I recently made some changes on our firewall to use port redirection. Essentially, I wanted to use a different port for people on the outside to connect to my SQL server. Thanks to those that answered my post, everthing works great.

However, I noticed that if someone on the local network uses the server (the one the changes effect) to make a connection to the Internet, suddenly, no one one on the outside can connect to the machine. I have to clear the XLATE table before it accepts connections. (all other connections are fine)

I examined the xlate table and it appears that when an outbound connection is made, it uses one of my global addresses instead of the static address I setup.

I've posted a partial config and xlate table for review. If someone could let me know what I did wrong, I would appreciate it...Thanks

access-list outside_access_in permit tcp any host x.x.x.109 eq 7505

access-list outside_access_in permit tcp any host x.x.x.109 eq 7506

access-list outside_access_in permit tcp any host x.x.x.109 eq pcanywhere-data

access-list outside_access_in permit tcp any host x.x.x.109 eq 5632

access-list outside_access_in permit tcp any host x.x.x.109 eq www

access-list outside_access_in permit tcp any host x.x.x.109 eq https

static (inside,outside) tcp x.x.x.109 5632 192.168.0.109 5632 netmask 255.255.255.255 0 0

static (inside,outside) tcp x.x.x.109 pcanywhere-data 192.168.0.109 pcanywhere-data netmask 255.255.255.255 0 0

static (inside,outside) tcp x.x.x.109 7505 192.168.0.109 1433 netmask 255.255.255.255 0 0

static (inside,outside) tcp x.x.x.109 7506 192.168.0.109 1434 netmask 255.255.255.255 0 0

static (inside,outside) tcp x.x.x.109 www 192.168.0.109 www netmask 255.255.255.255 0 0

static (inside,outside) tcp x.x.x.109 https 192.168.0.109 https netmask 255.255.255.255 0 0

static (outside,inside) 192.168.0.109 x.x.x.109 netmask 255.255.255.255 0 0

XLATE Connection (partial)

PAT Global x.x.x.109(80) Local 192.168.0.109(80)

Global x.x.x.111 Local 192.168.0.109

The above global statement should use the same .109 address when a connection is made to the outside, but for some reason it grabs one of the addresses from my dynamic pool (it starts at 110).

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 15:50:55 GMT

I'm not sure what the following statement is meant to achieve

static (outside,inside) 192.168.0.109 192.168.0.109

Is 192.168.0.109 on the inside of the pix which it seems to be from the config ?

Jon

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 16:05:41 GMT

Yes, the 192.168.0.109 address is on the inside.

Forgive my ignorance, but I though with static translations, I need to translate from the outside interface to the inside interface AND from the Inside interface to the outside.

Is this not the case?

I want folks from the outside to translate to the 192.168.0.109 address and any connections that originate from the inside to use the x.x.x.109 address.

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 16:26:54 GMT

No you don't need this statement.

static (inside,outside) x.x.x.109 80 192.168.0.109 80

means

From the outside you can access the 192.168.0.109 server on port 80 by connecting to x.x.x.109 on port 80.

It also translates the the 192.168.0.109 server to x.x.x.109 when it connects out.

static (outside,inside) syntax is usually used for translating source IP addresses.

HTH

Jon

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 16:44:13 GMT

Thanks for the info Jon.

I removed the statement as you suggested, cleared xlate, and tried my scenario.

Unfortunately, it still doesn't work.

Inbound connections are redirected to the correct port. However, as soon as I start an outbound connection (browser to Internet) from the machine, it grabs an address from my global pool. At that time, any future inbound connections are unsuccessful. If I clear xlate, then things resume normally.

I know with PAT, once I specifically redirect a port, I must use additional static statements for any other ports I want opened. But what tells the PIX to use the address I defined when it is outbound?

I never had this problem until I started to redirect one port to another. As you might guess, I had many individuals attempting logins on my SQL server with the standard port. Since I've redirected the ports, this has ended, yet I have this new problem...

Thanks in advance.

Scott

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 16:53:17 GMT

Scott

you are translating the x.x.x.109 address to 192.168.0.109 for all the ports so why not just have one static statement

static (inside,outside) x.x.x.109 192.168.0.109 netmask 255.255.255.255

Jon

Re: Connection issue

rigoberto.cintron — Wed, 15 Aug 2007 17:17:16 GMT

And then restrict which ports you want open with ACL's.

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 19:10:53 GMT

I did have it the way you suggested. The problem is that is I do as you suggest, and open the port for SQL (1433), everyone attempts to hack into my SQL database.

By using port redirection, 7505 ---> 1433, it makes it a little tougher for someone on the outside. They don't know it is an SQL port.

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 19:12:05 GMT

If there is a better way to do this, then please let me know

Re: Connection issue

rigoberto.cintron — Wed, 15 Aug 2007 19:19:33 GMT

The PIX/ASA has an sql inspection engine to prevent attacks. If you want to use a different port, then change the port in the SQL server and then allow that port.

Check this link:

http://www.cisco.com/en/US/customer/docs/security/asa/asa72/configuration/guide/inspect.html#wp1347071

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 19:38:31 GMT

Scott

if you are using a different port than the standard SQL port then who are your users ? How do you communciate to them that they have to connect to a different port ?

The problem is the any. Is this because your users can access the server from any IP address ?

Jon

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 19:47:11 GMT

My users are customers that hit the SQL server from a website we've developed. I can easily control what port they connect to, so for this reason, changing the port isn't an issue. My main concern is the bozo's that find an open SQL port and attempt to access the SQL database through the standard SA, ADMIN, or Root accounts. My logs show 5-6 attempts per second at guessing the password for these accounts. We've hardened the system by disabling these common accounts, but I was hoping that redirecting the port would cure most of the attempts. Once I added the static statement to change the port numbers, the entries in the log stopped. As I posted the issue is when I create an outgoing connection from the server. All I have to do is open a browser and access a webpage, and it uses an address from the NAT pool instead of the static address I want.

An option is to change the actual port that SQL operates on, but I was hoping I wouldn't have too.

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 19:50:46 GMT

Scott

If the users are coming from a website you have developed do you not know the source IP address that is making the query against your SQL server.

Is it the customer IP addresses or does your web server make the request on their behalf ?

Jon

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 19:55:27 GMT

I stand corrected. It is not a website, but software that is developed. The source addresses will vary. Our developers can make the connection using any port. By using a port other than 1433, and redirecting it, I minimize the attacks.

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 20:00:27 GMT

Okay, just though it might be worth pursuing.

I can probably guess the answer 🙂 but i don't suppose you have any spare public IP addresses ?

Re: Connection issue

sgoethals1 — Wed, 15 Aug 2007 20:01:43 GMT

What did you have in mind?

Re: Connection issue

Jon Marshall — Wed, 15 Aug 2007 20:07:55 GMT

Scott

Actually was about to edit last post saying scrap that. I just need to log on to a pix at work in our lab and test something.

Jon

Re: Connection issue

Jon Marshall — Thu, 16 Aug 2007 07:49:32 GMT

Scott

After much messing around i managed to get some version of this working :).

The setup i had was

Server on inside of pix - 10.231.224.50

static (inside,outside) tcp 10.15.1.10 5000 10.231.224.50 80

So to connect to the web service on 10.231.224.50 user would use url http://10.15.1.10:5000

I also had nat and global setup for hosts to get out to Internet ie.

nat (inside) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface

The outside interface address was 10.15.1.2

I found with this setup i could connect from the 10.231.224.50 server to a router on the outside with telnet and it created this dynamic translation

PAT Global 10.15.1.2(1031) Local 10.231.224.50(41347)

With this translation in the xlate table i then tried to connect from outside on port 5000 to 10.15.1.10 and it worked fine. It added the following to the xlate table

PAT Global 10.15.1.10(5000) Local 10.231.224.50(80)

Both the xlate entries exist at the same time.

This was all tested on v6.3 and it needs a bit more testing as it does not exactly match your test case and you would need a spare public IP address.

If i get time i will do some more testing but unfortunately i have a day job 🙂 so i thought i'd let you know where i was in case you want to test it.

Jon

Re: Connection issue

sgoethals1 — Fri, 17 Aug 2007 12:15:36 GMT

Jon,

Sorry for the delay in getting back. I had to be out of the office yesterday. I appreciate the testing you did. I will take a deeper look at it and see where I go.

I may end up calling Cisco on this one. If I do, I will let you know what I find out.

Scott

Re: Connection issue

sgoethals1 — Fri, 17 Aug 2007 14:03:51 GMT

Jon,

Here's what I found of from Cisco...

Static NAT where we mapped one IP to another. ie. x.x.x.109 -> 192.168.0.109 is bidirectional.

Static PAT (port redirection) is unidirectional and only works for outside to inside connections. Connections initiated from the inside will either use an address from my dynamic pool, or the address of the outside interface of the firewall.

To force it to use the address that I want, I had to create another dynamic pool (containing 1 address), and use a nat statement to tell it to use it. So, all I had to do was add the following statements.

global (outside) 2 x.x.x.109

nat (inside) 2 192.168.0.109 255.255.255.255

Once I did this, it works fine.

Thanks again for all of your help. I appreciate it.