Firewall on the our self-managed server

Hello,

I use authorize.net as a payment module on my shopping site and am encountering a problem with firewall setting.

If I block outgoing ports larger than 40000, it blocks the website from communicating with authorize.net service. Is there any particular port that I need to open for using authorize.net?

I got the following error message on the database.

• Comm results: 7 couldn't connect to host

Everything works fine if I open all the ports on the firewall. Please advise me if anybody knows which port to open.

Thanks in advance!

Authorize.net works over port 443, or maybe port 80 if you don't properly have SSL set up.

DrByte,

Thank you for your quick response.

I do have both 443 and 80 open on my firewall. What's interesting is the transaction does not go through when I close ports larger than 40000, and does work if I open them. Is this only my issue with the firewall or there is something going on during the transaction?

meetsek:

What's interesting is the transaction does not go through when I close ports larger than 40000, and does work if I open them. Is this only my issue with the firewall or there is something going on during the transaction?

It's a firewall configuration issue.

There are three main filters govern what happens to an IP packet when it reaches a firewall, these are the INPUT, OUTPUT & FOWARDING rules. Each are to be configured seperately.

When a request is made from your server to an external server, such as Authorize.net the destination packets are sent TO port 80/443, but the source of the packets (and therefore the reply from Authorize.net) are sent using a semi-random port typically in the 30000 to 60000 range. So if you've blocked these ports via the OUTPUT/FOWARDING rules the packets will never reach the server (couldn't connect to host). As for the reply packets, these are sent from authorize.net TO your server using the same port number that it was sent from. A correctly configured firewall uses a method called 'connection tracking' that records the destination address & port of the outgoing packets so that the reply packets get automatically accepted by the INPUT/FOWARD rules, therefore you don't need to manually configure the rules to allow these packets.

Now, having said that, in all my years of frequenting the ZenCart forums, I can't recall any other person that has implied that they've needed to set up or configure their own firewall for there ZenCart operations. How come you apparently have a need? (I'm just really very curious). Also what hardware/software firewall are you using? (Not all are created equally, eg, Cisco Firewalls are a whole different beast to a Linux based FW, and BSD is similar but not quite the same as a LInux based one).

Cheers
Rod

Thanks a lot for your detailed explanations, Rod.

We usually put an ecommerce websites on one of our shared servers and certainly don't want intruders coming in to the servers. We are trying to harden the security as much as we can but sometimes misconfigurations like this make websites not functioning.

We use Juniper Networks SSG5. I'll take a look at the settings and see what I can do.

meetsek:

Thanks a lot for your detailed explanations, Rod.

We usually put an ecommerce websites on one of our shared servers
We use Juniper Networks SSG5

I guess these are your own servers? (I can't see any other reason why you'd be using the SSG5)

meetsek:

I'll take a look at the settings and see what I can do.

Does your network use subnets, or are all hosts on the same network? If all on the same network (and I assume you have your own public IP's) the simplest safe configuration would be to enable all outgoing traffic on all interfaces to any host/port, block all incoming traffic except on the internet connected interface and destined to the hosts and ports you specifically allow, and enable the connection tracking to take care of reply packets.

If you don't have a set of public IP addresses you'll need to rules for NAT translation.
If you are using subnets you'll need to restrict/allow each interface according to the needs of the subnet(s).

Whilst all of this can be done via the GUI, most network admins would favour the CLI to configure these things. It is a lot easier (and quicker) to dump the settings to a text file, make any needed changes using a text editor and then uploading the new file, rather than navigating around all of the different GUI screens. Having said that, if you are 'addicted' to the GUI it is still a good idea to dump the settings to a text file anyway (it'll give a far better idea of what the GUI is actually doing), and these files can be a useful backup/recovery tool for those times that you'll invariably lock yourself out of the device and need to perform a hardware reset :)

Apologies if this goes over (or under) your head, but I have no idea of knowing your skill level with this kind of device. The fact that you have one suggests to me than you probably know more about networks than the average joe, on the other hand, the problem you are having suggests that what you have is an overkill for what you are actually needing, which is where my simple/safe configuration suggestion should prove useful. :)

Cheers
Rod

Thanks Rod!

Yes, these are our own servers and the task is on my lap since nobody else is doing it. I'm having a quite experience in front of the GUI firewall setting screen. Almost punched my computer :P

I really appreciate for your help. I'm not an expert in this field but I think I can figure out the simple configuration you described. All configurations have already been done except for enabling the connection tracking.

It sucks that I can't give you a million points for these answers :)

meetsek,
You may find this useful.

http://www.juniper.net/techpubs/software/screenos/screenos5.1.0/CE_v2.pdf
Chapter 4 Interface Modes
Example: Transparent Mode

Cheers
Rod

I can't really use my time for this configuration right now...I will report back here when I got updates. Thanks!