I manage several Colo and dedicated servers at various data centers around the world, something we often do is physically place a mikrotik router inside of our Colo d server chassis and power it via a Molex and then connect the servers ethernet to the mikrotik and then the uplink from the data center also through the mikrotik (by the way this is an excellent use of mikrotik router's for various reasons/uses such as: VPN only server management , firewall , IP-based access control and bandwith shaping etc.)

All of the clients on the servers are simply hosting websites either on port 80 or 443 if SSL. An issue we often come across is a clients website will become infected and essentially be used as a proxy or as a machine to launch attacks on other websites such as brute forcing or site / port scanning.

I was thinking that a good way to combat this might be the following, and was looking for input from others (perhaps this idea is already very common or perhaps it's entirely wrong):

The concept is the server is only allowed (based on IP address) to connect to an IP if that IP address first initiates a connection to the server. The idea is A legitimate website visitor will first access the server then their IP address is added to an address list with say a 12 hour time out , and then *only* IP addresses on the address lists are allowed to be connected to from the server - and all other traffic / outbound connections are dropped

Again the idea is to keep the server from connecting to an IP address that has *not* first attempted to connect to the server

(obviously for legitimate out puns connections such as software updates or software installations , those ip addresses will have to be manually added to the address list / white listed or these firewall rules temporarily disabled).

Any input or feedback on this concept? Or is it all perhaps already a very common technique? Or is my logic incorrect?

I'm in the process of setting this up on one server and will post the actual firewall rules once it's functional so that others may see in use this technique on their mikrotik setups.

Thanks

EDIT:
I should also add that this rule / the MT firewall is not the only firewall im running, on the actual servers i run iptables (linux firewall) to handle IP list based access for management ports (since the servers have public IPs).

Ummm - this just sounds like a 1-rule solution:

chain=forward in-interface=serverNet connection-state=new,invalid action=drop

And for good measure, tack a log action onto this same rule so that you can analyze what your server's trying to do whenever it triggers the rule.

Connection state tracking can be used in any direction. Don't forget that routers don't really know what the heck a "wan" interface is, or a "guest" network. They're all just interfaces and the router has no idea what "upstream" means. It just forwards packets in the direction the routing table tells it to, subject to passing the firewall rules.

As for firewall design -
My forward chain heirarchy would follow this logic:

drop blacklisted sources/destinations (use address list as blacklist)
fast-track established,related
allow established,related
allow whitelisted sources/destinations (e.g. your management network - use address list for whitelist)
allow any outbound connections the server might need in order to do its job, e.g. udp 53 if it's a nameserver
drop new,invalid from server side (the rule I suggested above)
allowed tcp ports list (e.g. 80,443 for a webserver, or 25,110,imaps for a mail server, etc)
allowed udp ports list
allow icmp echo requests
drop all

If there are multiple servers behind the same RouterBoard, I'd recommend a custom server-in and server-out chain for each one and jump to those where the "allowed TCP/UDP/icmp" rules are

Thanks for your reply and your firewall example,

Maybe I'm explaining it incorrectly, because you're one single firewall rule would not accomplish what I'm trying to do. For example if there's a virus on the server that is establishing outbound connections from the server to various other websites to scan or brute force them why would your one rule drop those connections ? (They are not invalid connections)

For example let's say the virus that has been placed on my server is coded so that every four hours my server tries 5 random passwords on Bob.com/login.php. (I.e. It's a very slow brute force)- my concept is that since the IP address of Bob.com has not first tried to access my Web server (a inbound port 80 connection, like a normal web surfer would do), it's IP address would not have been auto added to the "firewall white list" and thus the viruses connection from my server would be dropped at the mikrotik (via a fw rule that if IP address is not on white list then action: drop)

Does this make sense or perhaps am I not reading / understanding your reply / one rule properly?

Thanks

I had time to get this working, here are the firewall rules that accomplish what im talking about / trying to describe:

(ignore that my in-interface is infact a BRIDGE, there is a reason specific to my setup that i have to use a bridge, normally on most setups this would be a normal Ethernet interface. )


add action=add-src-to-address-list address-list="Came IN first SO allowed OUT 12h" address-list-timeout=12h chain=forward connection-state=new dst-port=80,443-445 in-interface=HOSTING_VM_bridge1 protocol=tcp

add action=drop chain=forward in-interface=HOSTING_VM_bridge1 src-address-list="!Came IN first SO allowed OUT 12h"

(Note the " ! " on the 2nd rule's src-address-list , it might be easy to overlook in text form)

to recap- the idea is im running a web server, the mikrotik sits between my webserver and my datacenter uplink. "Bob" visits a website hosted on this server, thus he first sends a request to port 80 (so the first firewall rule adds him to an address list with a 12hour timeout). Now my web server needs to reply to Bob's request, with the actual website - which it is able to do since the webservers connection back to bob is NOT dropped by the 2nd rule (bc bob's IP address *is* on the address list).

However, there is a virus on my webserver. This virus not only connects to its command / control server, but it also bruteforces a list of web URLs 5 times a day. The virus will NOT be able to connect to either of these targets as when it tries to makes its out-going connection, the IPs it needs to connect to are *NOT* on the address list thus the mikrotik drops these connections. and the virus fails (for the most part).

Any feedback on this method / firewall rule? (or maybe im "trying to force a square into a round hole" ?)

thanks

Any feedback on this method / firewall rule? (or maybe im "trying to force a square into a round hole" ?)

thanks

What you're doing is eminently possible. Think about it - it's just like a "home" router plugged in backwards; your home router wouldn't allow any traffic in unless it's related to an outbound connection.

What you're doing is eminently possible. Think about it - it's just like a "home" router plugged in backwards; your home router wouldn't allow any traffic in unless it's related to an outbound connection.

I get what your saying, but even with a home router your PC *is* able to outbound connect to any IP it wants to, regardless of if that IP has attempted an incoming connection first. In my Co-located server mikrotik firewall its as if every web visitor is " authenticated for outbound access" by way of their attempt to connect to the servers public IP on port 80 (or 445 for ssl )

I can say this for sure, there was a php (or i think a WordPress) exploit that had been preformed on this server, and it was constantly connecting to other external websites on the internet (my server was being used as a proxy, among other nefarious actions as a result of this exploit).

A client on this particular server of mine had not updated their WordPress install in 4 years (he also didnt have wordpress auto-update enabled) , thus the exploit / vulnerability was un-patched and someone exploited it. I got a few notices of abuse (external websites which had been attacked from my servers public IP sent logs and info to my ISP/data-center which then forwarded those reports to me) This lead me to investigate the exploit and come up with this mikrotik firewall solution, so far it has worked to stop any exploits which i have not cleaned from my server, from being useful in anyway. I even temporarily left a few exploits on the server to test if this mikrotik fw rule successfully blocked them and it has (i then cleaned up those exploits too)

I should also add that this rule / the MT firewall is not the only firewall im running, on the actual servers i run iptables (linux firewall) to handle IP list based access for management ports (since the servers have public IPs).

What you're doing is eminently possible. Think about it - it's just like a "home" router plugged in backwards; your home router wouldn't allow any traffic in unless it's related to an outbound connection.

"What you're doing" should have said "What you're trying to do".

I get what your saying, but even with a home router your PC *is* able to outbound connect to any IP it wants to, regardless of if that IP has attempted an incoming connection first.

I don't think you do get what I'm saying. Put it in backwards, remember? No data gets in to your PC unless it initiated the connection first [or you've forwarded a port to it].

Thanks for your reply,

I do understand your analogy (including the "reverse" part) , however i dont personally agree with it- home routers and NAT mainly deal with port access control (tcp / udp ports) and private IPs, what im doing deals mainly with public IP related access control.

In terms of my firewall rules, i dont understand why more admins (of public IP , internet facing servers) arent running this type of firewall setup (in addition to other rules of-course).

Here is another scenario/example that my firewall setup protects against:

An admin is running a Web hosting or Cpanel server with a public IP, a common target for hackers. Lets say the hacker wants to exploit this admin's server to run a spam (email) script/virus. Once they find a vulnerability in the server's software, they install their software which will send 50,000 emails a day via SMTP direct connections (ie the hacker can make money sending unsolicited emails for his paying customers, think Viagra spam or get rich quick spam).

The hackers spam script or software will require that the compromised server connect to each spam recipients email server on port 25 or 587 (if using ssl smtp) in order to deliver the spam email. My firewall rules will drop all of these nefarious outgoing connections because those email servers (the spam recipients' email server) will *not* have first tried to access the compromised server , and thus will not have been added to the address list.

This is just one example im providing to illustrate a point, im posting all this to hopefully get feedback from others. so far the my firewall rules are working great on my web server.

Thanks

I think perhaps the "backwards router" analogy has outlived it's usefulness. The thing that makes it work is the connection/state tracking. You don't have to use NAT to use state tracking.

My original suggestion does -EXACTLY- what you want. You're re-inventing the wheel. State tracking does what you want automatically.

My original suggestion does -EXACTLY- what you want. You're re-inventing the wheel. State tracking does what you want automatically.

Hi,
I tried your exact rule and it did not accomplish the same as my rule ( for example i was able to ping google from the server with your rule, with my rules im not able to as google's IP has not first tried to connect to my server's public ip on either tcp 80 or 445).

Maybe its because im using a bridge? (i bridge the Ethernet up-link to DC and the Ethernet port going to the server, there are a few reasons why i use a bridge). My rules use the "in-interface" as the bridge.

Thanks

Hi,
I tried your exact rule and it did not accomplish the same as my rule ( for example i was able to ping google from the server with your rule, with my rules im not able to as google's IP has not first tried to connect to my server's public ip on either tcp 80 or 445).

Maybe its because im using a bridge? (i bridge the Ethernet up-link to DC and the Ethernet port going to the server, there are a few reasons why i use a bridge). My rules use the "in-interface" as the bridge.

Thanks

Bridge interface isn't the issue. That's the correct interface in your situation. If you followed my entire recommendation then pings would be allowed but nothing else. I.e. If you opened a browser and tried to go to Google it should fail.

Set it up the way you tried my recommendation and if http works from the server, then post an export of ip firewall so I can double check.

I think the original idea is overcomplicated (for web server). You don't need to add visitor IP's to any list. Replies for incoming connections (from client to server) will be allowed by accept established rule. As for further outgoing connections, there won't be any, http server does not create new connections to clients. Simply block everything outgoing as ZeroByte suggested and you have the same thing.

The problem with this approach is that if you block access to all external resources, you have to manually add exceptions for everything (e.g. php script fetching data from external server). It could work if you don't need any or just a few for yourself. But I can't imagine how it could work with independent client websites hosted on the server, I would hate it both as client and hoster.

There's usually more than one way to accomplish an specific task, but if there's one that follows good practice, is optimized for the task being discussed here, being the simplest one (and thus an ellegant one), is the one ZeroByte shared on his first post.

Sometimes we're so self-convinced something should be done in a certain way after devoting effort to it we cannot see a better, simpler approach just in front of you... these times I take a rest and approach the problem again with fresh eyes.

ZeroByte's rules drops new or invalid connections, so not only invalid connections are going to be dropped, also the first one in the event a webserver phoning home.

That's it, unless on some ROS version the logic isn't new OR invalid, and it's new AND invalid... you said that rule wasn't preventing the internal server to phone home?