My first attempt at a brutal honeypot worked to a degree however it did cause some problems. I’m not sure totally how but Amazon Prime Video stopped working (Amazon servers port scanning me??) but I managed to block Amazon which wasn’t the most helpful thing at bedtime when my 4 kids are trying to watch Shaun the Sheep before bed. I’ve had to make some changes to it. The previously stated timeout has now been employed so sources that sniff about are now only timed out for 24 hours rather than permanently and I’ve also added in an extra rule for ICMP traffic as there were a couple of ICMP type packets getting through and the owners not getting blocked.
So far Amazon is working and this combined with a geographic black list in addition to the Joshaven blacklist and I’m now getting towards the place I want to be.
/ip firewall filter add action=drop chain=input comment="DROP Joshaven BL" src-address-list=blacklist add action=add-src-to-address-list address-list=myblocklist address-list-timeout=1d chain=input comment="BL STRAY TCP" in-interface-list=WANs protocol=tcp src-address-list=!routeraccess add action=add-src-to-address-list address-list=myblocklist address-list-timeout=1d chain=input comment="BL STRAY UDP" in-interface-list=WANs protocol=udp src-address-list=!routeraccess add action=add-src-to-address-list address-list=myblocklist address-list-timeout=1d chain=input comment="BL STRAY ICMP" in-interface-list=WANs protocol=icmp src-address-list=!routeraccess add action=drop chain=forward comment="DROP myblocklist outbound" dst-address-list=myblocklist
More to follow up and there will be a full firewall list to follow once I have something I feel is universal enough to distribute.
Using a thread on the MikroTik forums as inspiration, I’ve taken the idea and made my first incarnation of a fairly brutal honeypot & blacklist. This is only the interesting part of the full router script but it’s my baseline for starting.
# SET WHITELIST IF NEEDED # SET IN-INTERFACE /ip firewall address-list add address=220.127.116.11 list=WHITELIST /ip firewall filter add action=accept chain=input comment="ACCEPT ESTABLISHED & RELATED SERVICE" connection-state=established,related in-interface=WAN.INTERFACE add action=accept chain=input comment="ACCEPT WHITELIST" src-address-list=WHITELIST in-interface=WAN.INTERFACE add action=accept chain=input comment="ACCEPT PING" protocol=icmp in-interface=WAN.INTERFACE add action=add-src-to-address-list address-list=honeypot-blacklist address-list-timeout=none-dynamic chain=input comment="BLACKLISTING TCP" in-interface=WAN.INTERFACE protocol=tcp src-address-list=!WHITELIST add action=add-src-to-address-list address-list=honeypot-blacklist address-list-timeout=none-dynamic chain=input comment="BLACKLISTING UDP" in-interface=WAN.INTERFACE protocol=udp src-address-list=!WHITELIST add action=drop chain=input comment="DROP BLACKLISTED INPUT" in-interface=WAN.INTERFACE src-address-list=honeypot-blacklist add action=drop chain=input comment="DROP ALL (SHOULD NOT FILL UP)" in-interface=WAN-INTERFACE log=yes log-prefix=non-bl-dropped-traffic
It’s quite strict in that anything that sniffs at it gets added to the blacklist and then blocked until reboot. As I push it further I will probably time the sniffers out for a few days rather than perma-block.
Recently with a lot of the “news” about MikroTik being that version X.XX has been compromised and then so has X.XX it got me looking a lot closer at security and what I can do to protect my own router and those that I manage.
The easiest answer primarily is don’t allow external access and make sure your firewall is impervious but then what about actual protection from these sources even before they get near your Winbox interface and what about enhancing that to protect client devices as well?
From reading through the MikroTik community I came across a thread by a guy called Dave who is offering brilliant blacklist capabilities for very cheap (when it comes to market) if you don’t mind running his script on your router ( forum thread here ). This consists of running his script on a scheduled basis and creating a firewall rule to block the traffic from the created list as both input & forward, source & destination with combinations thereof.
Dave’s list is brilliant, it takes from known sources of malicious software as well as his own network of honeypot servers so it will actively catch people trying to get at his servers. An advantage of this is it also does not take up much room as an exported RSC file as the script is to fetch a dynamic file which is imported and then deleted so keeping your file size low.
In addition to this I wanted my own form of very basic protection from specific geolocations, to do this I have found a site called mikrotikconfig.com.
There is an option here to generate an address list from selected countries, I simply chose the countries I don’t want with access, edited the file to use “myblocklist” instead of “countryip” and then created firewall rules to drop those also. The downside to doing this is all of the subnets are statically set so it will vastly increase your export RSC size but for mid to higher range devices this shouldn’t be an issue.
More to come as I develop and increase my blacklisting capabilities.
Its been on my mind for a while that the CPU in my CHR wasn’t setting the world on fire, it was great for what it was doing and it was low powered but as I start and do more with my CHR, maybe start to look at a dude server and do some more advanced packet marking and processing I wanted something with more oomph!
I’ve now upgraded from a Xeon E3-1220L to an E3-1270. That’s a boost in base clock from 2.2Ghz to 3.4Ghz and a big step from 2c4t to 4c8t. I managed to do a small amount of testing before and after and whilst the difference from what has been done is negligible at this point, I’m expecting that as I burden the CPU more it will withstand the pressure for longer.
After CPU upgrade, same ESXi settings so this is “just” the core speed improvement;
This is the performance after shutting the machine down and applying the additional CPU cores;
Concluding my testing, a 400Mb increase in pushing traffic to itself from the CPU core speed upgrade, nothing to be sniffed at I guess, the traffic was also a bit more stable at this speed as opposed to the previous CPU.
A quick and free boost for my broadband connection this week. I’d been monitoring my DSL service and was noticing some errors on the downstream and with some quick research Interleaving was a common cause of this. Interleaving in short splits your packets down and reassembles at the far end, it’s great for stability but does increase latency. It’s not great if you use VOIP and if you’re a gamer it can increase that all important response time which you need as low as possible.
A quick webchat with Plusnet support and I’d asked for my service to be put on “fast track” or in other words, having interleaving removed. A 24 hour wait and to my surprise my connection has improved!
The only issue with this is if Interleaving was helping the connection there is a possibility it will wobble and DLM will re-apply it but the service in general is very stable so I am hopeful that the change will last.
Friday 13th was an exciting one in my household! Not only did I kill the internet for everyone for a good 3 hour period whilst I swapped from an Ikea Lack table to a “real” 6U cabinet causing huge disruption when my planned single patch panel turned into 3! I also fired up old faithful and stuck on a fresh copy of the latest (6.42.6) CHR into my VM box.
Now I have my spare ESXi box housed in the attic in a real rack it means I don’t need it screaming away in the cave so I can finally move back to a CHR build and keep it. My rough maths says the CHR unit will have around 4-5 times the performance of the RB3011 which will now get moved to the cave as a dedicated VLAN breakout switch (or maybe sold) but ultimately I can employ some far more complex queues without worrying that I’m running the CPU up too far.
My long term plan is to SFQ my LAN traffic but then pick out particular traffic types from that and SFQ them against each other whilst doing some PFIFO pulling them all together. I’ll try to document as much as I can but in short it will be a huge amount of packet marking so CPU grunt is needed. I’m even now tempted to look at upgrading the CPU so it’s more than a dual core!
Fun times ahead.
I’ve recorded my hAP Mini config video a couple of times so far and still not found a version I like. It is in the pipelines though however I’m thinking that trying to include low powered device optimisation into the same video is a bad thing. Maybe that should be it’s own video?
Either way I’ve configured my new “toy” a couple of times now and have been really amazed by what I was able to push through it. Bearing in mind this is a low powered single core unit out of the box with a handful of firewall rules and NAT it was able to push 94Mb whilst maintaining only 88% of CPU utilisation (minus whatever it was using for me watching Winbox).
Testament to my previous fasttrack learning curve though, once I put a couple of fasttrack rules into the firewall that same 94Mb was achieved on just 22% of CPU utilisation (again whilst I had Winbox open so minus a few % for that.
I seem to be finding 94Mb as a limitation though, this will no doubt be in part due to the unit only being 10/100 and losing some overhead from that but I’m amazed how viable this thing is, even to the point that it would be able to be used for VDSL in the UK with no detriment.
Please keep your eyes peeled for some soon to come videos regarding the hAP mini, potentially a config and then a more broad stroke efficiency ideas.
My most recent tutorial is now online for viewing. Very basic one but an exceptionally easy way to increase your network efficiency and avoid unwanted slow downs.
It involves the use of a Simple SFQ based queue on your WAN interface and full instructions can be found here
Free performance enhancement? Must be a catch….
I’ve recently had to investigate making some lower powered MikroTik devices route at decent speeds, there is a much longer story which I won’t be going in to but in short I had a task of making a CRS112 (low powered 400Mhz single core CPU) able to route 100Mb services.
A little background is the CRS112 is primarily a switch, using hardware offload you can easily switch at line rate (Gigabit) however they don’t really do too well in routing or anything CPU oriented. For example viewing Winbox uses 20% CPU resources as does running FTP, Telnet and WWW services!
For basic NAT masquerade and a simple 12 line firewall rule my initial testing was only yielding speed test results in the 30-40Mb region. The first 2 lines of my firewall were as follows to try and be as efficient as I could be;
/ip firewall filter add action=accept chain=forward comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1 add action=accept chain=input comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1
The goal was to route at least 50Mb through the CRS so I picked up something I left alone a long time ago as then there was no need to use CPU limited products and the cons outweighed the gains.
Fasttrack is a powerful little tool you can use to vastly improve throughputs on CPU limited devices, the plus sides of it are that my CRS112 that was only previously capable of routing 30Mb was now being limited by my PPP account at 150Mb and it still had gas in the tank! The device suddenly becomes a much more viable router however the draw back to this is that fast track effectively allows the packet “through the gates” and then takes no further part in it’s journey. Connection tracking is disabled meaning any further mangling of packets and queues simply do not know about the packets we have just expedited.
In most situations fasttrack is probably going to break more things than you’d like whilst trying to squeeze the last bit out of your router however on heavily CPU limited tasks where you only need a basic router it will certainly help.
The final firewall configuration only needed 2 lines adding (yes I tried without the accept rules and it won’t work);
/ip firewall filter add action=fasttrack-connection chain=forward comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1 add action=fasttrack-connection chain=input comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1 add action=accept chain=forward comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1 add action=accept chain=input comment="ACCEPT ESTABLISHED & RELATED" connection-state=established,related in-interface=pppoe_client1
So to summarise, fasttrack is the devil unless you have a low powered device. Connection tracking is probably more valuable than making your under specced kit last an extra couple of weeks but a very good learning experience.