DD-WRT

I spent some time today dissecting DD-WRT, which is an open source operating system used on many routers and embedded devices (that use Wireless technologies, especially 802.x).

Looks like it uses BusyBox for most of the binaries. BusyBox appears to be a single binary that can run many of the GNU / POSIX unix/linux-descended binaries. It's supposed to be more compact. For example, options have been stripped away or replaced on many of the binaries in the name of compact simplified code (lower footprint).  It is open source, so one can download, inspect, compile, etc.

For ssh, it uses something called DropBear. Again, a compact ssh server.

The webserver, httpd, looks to be an in-house developed web server (meaning, written by developers of dd-wrt). Chillispot is the access point controller.  ttraff is used as the traffic counter. dnsmasq is used as the DHCP server on the box.

All in all, the box looked very tight - with 40M used of 256M,

In some ways interesting, in other ways, uninteresting - which is a good thing for embedded devices.

Windows 10 Chatter

I wanted to take some time to do some forensic analysis on my router (this is another blog entirely).

One of the things I noticed, was how busy the router was.

Well, hey. It's a busy house. And the whole family is here this weekend, all streaming NetFlix on phones, laptops, et al.

But - I noticed an inordinate amount of traffic from one PC.

Upon doing some further investigation, using packet sniffing tools, Task Manager, et al. I realized that Microsoft was calling home for a number of reasons.

I should have looked into this more when I bought this PC, but got busy. Shame on me.  I saw all kinds of things, and starting shutting down services, etc. Finally, I after shutting down so many things, and continuing to see packets flowing, I went out to the web and found this link - which is reasonable recent.

http://arstechnica.com/information-technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-microsoft/?comments=1

I also read the comments, and wound up installing DisableWinTracking. I downloaded the source code first (as a tar file), and looked it over. Deciding it looked clean, I went ahead and ran the program, which is a series of powershell scripts that disable the tracking. There's a considerable amount of it. I un-installed all of the Microsoft apps listed, and disabled the services (I did not delete them - just disabled them). You have to be a little worried about shutting off your security updates on Windows 10, which is something I will need to monitor.  But a lot of that crap, I agreed with and decided was not really in my interests at all, and in fact was sucking up bandwidth and tying up an already-busy router.

Now, I'll go back and start looking at traffic again.

Firewall HA with conntrackd and keepalived

As we are doing some keepalived work, and looking at groups of IPs, I came across a couple of links worth mentioning:

This link below shows an approach of using a vrrp_sync group for an internal and external network. This is very much along the lines of what we were thinking we wanted to achieve and it was nice to see reassurance that we might be using a sync group as it is intended to be used (given the dirth of use-case documentation on this).

http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Another link is this one below.

Up to this point I have only been testing the VIP assignment and reassignment by pulling cables and making firewall adjustments (to make sure the VRRP could get through the firewall).

This link below has me concerned that true client testing might (will?) fail. Because indeed, Firewalld and iptables on Linux are, indeed, stateful firewalls. So I may need this link to bail me out.

http://backreference.org/2013/04/03/firewall-ha-with-conntrackd-and-keepalived/

VRRP Testing Round 3

Today, tested the concept of a Synch Group.

Used the configuration (essentially) from this ubuntu manpage.
http://manpages.ubuntu.com/manpages/precise/man5/keepalived.conf.5.html

Worked very well on VirtualBox, where we connected and disconnected virtual cables and watched the IPs move, in tandem.

Using just two instances if you disconnect one interface on each, VRRP considers itself in a complete fault state and neither box gets a virtual IP on either interface - which is what you want if it's a synch group.

Pretty happy with this testing.

BTW...another site I found had some decent comments about some options:
https://linux.die.net/man/5/keepalived.conf

Multicast - Low Level How it Works

http://www.firewall.cx/networking-topics/general-networking/107-network-multicast.html

VRRP Testing Note 2

In doing some extensive testing with VRRP with Keepalived, I was able to put it into Split Brain mode.

I have documented how I did this, and I will need to see if it is repeatable.

Here is one link that discusses troubleshooting for this, although I will need to find others.

https://www.atlantic.net/community/howto/vrrp-keepalived-configuration/

UPDATE: Here is another.

http://serverfault.com/questions/512153/both-servers-running-keepalived-become-master-and-have-a-same-virtual-ip

In his case on this link, here is the solution.

The problem has been resolved.

The problem was from the switch setting. When multicast filter mode is filter-all, the problem happened. The Keepalived runs O.K. when multicast filter mode is forward-all.

In his specific case, unicast could be the answer.

I realize that I do not have that mcast src ip in my file (don't think that is needed but I can add it).

I could also try to use PASS instead of AH. So I can experiment with that as well.

VRRP Testing - Note 1

First problem I ran into was with SeLinux. Apparently when the notify script wanted to write to an output file, SeLinux complained and prevented this. This made it impossible to tell if the script was even working, and therefore made it very hard to tell if VRRP / Keepalived was working.

I got around this by changing SeLinux to permissive in the /etc/selinux/conf file.

With permissive, it still complains, but does not prevent.


Next, I came to realize that the configuration parameters that were being used to start keepalived were in the /etc/sysconfig/keepalived folder.

I changed these parms to use -P -D -d -S 7.

The -P is for VRRP Only option.
-D is for Debug
-d is for dump config
-S is for log level, which is set to 7 for maximum logging.


With these changes, I noticed that BOTH virtual machines had a virtual IP, instead of just one. This surprised me. I expected only one to use the virtual IP and that it would switch back and forth.

But, doing some initial testing by disconnecting adaptors, I could see the state change being logged out to the log file.

VRRP with Unicast

Some good examples of how to do keepalived with unicast:

http://www.linux-admins.net/2015/02/keepalived-using-unicast-track-and.html

VRRP with Keepalived

First, the website for keepalived:

http://www.keepalived.org/

Originally, I read the documentation on their website, which is dated June 13th, 2002.

http://www.keepalived.org/pdf/UserGuide.pdf

Unable to believe that the documentation could not be changed after this many years, I went digging for better more updated documentation, and indeed, I found that here:

https://media.readthedocs.org/pdf/keepalived/latest/keepalived.pdf

WHY DOES THIS NOT LIVE ON THE WEBSITE????

I started reading. This is not simple / trivial.

Keepalived is essentially used mainly for load balancing, and when you read up on it, it is inferred that one needs to have LVS (Linux Virtual Server). There are quite a number of sites discussing how to build a Load Balanced with LVS, like this one below.

http://www.linux-admins.net/2013/01/building-load-balancer-with-lvs-linux.html

But there did (and still does not) seem to be much documentation discussing what you need to do, exactly, to install and run LVS. For instances, does it come by default on systems? Do you need to install it? Compile it?

One article, albeit from 2004, scared me when I started reading about patching the kernel to use it.

http://www.ultramonkey.org/papers/lvs_tutorial/html/

Later, I found this link, which, FINALLY, makes it clear that you need the package ipvsadm (on CentOS, which is the OS I am interested in).

NOTE: Maybe these are different services and packages on other Linux distributions.

https://www.server-world.info/en/note?os=CentOS_7&p=lvs

Next, I started reading further, and realized that, in order to use VRRP, you don't even need to use LVS!!! WHY? Because VRRP is only used to maintain state between Master and Slaves on Load Balancers, so that a) someone is always on top of the load balancing task and b) the Load Balancers know who the master is, and who the slave is. It is also used to prevent Split-Brain mode (multiple masters, etc).

So - why would you be interested in VRRP, without the Load Balancing? That does not seem to make much sense? And that is why these concepts are so intertwined. But in our case, admittedly a rare one, that is our requirement. We just want VRRP for the purpose of making sure a node is always up; we don't need the nodes running VRRP to load balance anything behind them.

So I found these sites below that, rather than address LVS (and using KeepaliveD for LVS and Load Balancing), and instead focus on the VRRP aspects of KeepaliveD.

https://tobrunet.ch/2013/07/keepalived-check-and-notify-scripts/

http://packetpushers.net/vrrp-linux-using-keepalived-2/

This site from Oracle helps provide some guidance on the tracking features of keepalived (scripts, interfaces, et al). It finally explained what interface tracking is for / does.

https://docs.oracle.com/cd/E37670_01/E41138/html/section_hxz_zdw_pr.html

VirtualBox Networking Configuration

VirtualBox has its own way of Networking that is a bit different than other virtualization platforms.

It's important to understand the distinctions between the types and kinds of networks that are out there and available.

VirtualBox Networking Chapter of Manual:
https://www.virtualbox.org/manual/ch06.html

VirtualBox Manual Itself:
http://www.virtualbox.org/manual/

Note: There is a pesky NIC that shows up in "ifconfig", called virbr0. This is a virtual network driver that shows up if you are running libvirtd. You will need to stop and disable libvirtd if this interface is resident, and often times you will need to reboot the box or VM after you do this for the interface to completely disappear from the ifconfig interface listing.

Generating UUID for Network Interfaces

Ever wonder where these came from? How these got generated?

Ever wanted to copy an interface file, and wonder about what happens if you use the same UUID, or - perhaps worse - what happens if you blow it away, or just change it willy nilly?

Well, I came across this and tested it on VirtualBox - because VirtualBox did not generate files or UUIDs for new NAT interfaces I created. I generated new UUIDs, and nothing complained or barked at all. Yay.

I'm sure I will remember this, but I'll post it just in case.

NOTE: The uuidgen utility seemed to be on the box. I did not need to install anything. I don't know what package this utility is a part of, and have not researched. It just seemed to work - for me at least.

http://www.itechlounge.net/2014/03/linux-how-to-generate-uuid-for-network-interface-on-rhelcentos/

Source NAT on Linux

Had a request come in to try and do a source-based NAT.

The reason for this is that the customer had a ISP router that they presumably could not log in and configure to do NAT with. Behind this router, was a Switch - apparently an L3 Switch that had some intelligence, but apparently it could not do NAT. It could have actually been related to change control, also.

I found this website here, which discussed how to do SNAT.

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html

Since websites tend to die an move, I will clip the excerpt of text I was interested in:
----------------------------------------------------------------------------------------------------------
You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.
Source NAT is specified using `-j SNAT', and the `--to-source' option specifies an IP address, a range of IP addresses, and an optional port or range of ports (for UDP and TCP protocols only).

## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

Masquerading

There is a specialized case of Source NAT called masquerading: it should only be used for dynamically-assigned IP addresses, such as standard dialups (for static IP addresses, use SNAT above).
You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

## Masquerade everything out ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

----------------------------------------------------------------------------------------------------------
Since I used FirewallD, I had to put the NAT rule into the direct.xml rule of FirewallD (I considered trying to put it in a zone-based rule, but decided to use direct.xml).

In testing this, I found some very interesting things. I did not have an IP to NAT "to", since I don't run the networks here, and everything is set up for DHCP. But - I did have two NICs on two separate networks, so I decided to SNAT the IPs of NIC A (10.1.x.y) to NIC B (172.31.x.y).

I used tcpdump to examine packets that typically came out of NIC A as 10.1.x.y, to see if they would come out as 172.31.x.y: tcpdump -A -n -i NICA grep "172.31.x.y"

This seemed to work as long as I had ONE rule for ONE Nic. But if I tried to use TWO rules for the TWO Nics, nothing seemed to NAT at all.