[SOLVED] Router commands: from objects to commands and back again?

[BigChimp]

Hi all,

I've been thinking on and off about a pet project of mine: generating/manipulating router/firewall/NAT configs with a Lazarus-programmed GUI (and sending them to the router - in this case a single Vyatta router - but the concept may be extended).

This router has commands like:

set firewall name DMZ-INBOUND rule 5 action 'accept'
set firewall name DMZ-INBOUND rule 5 description 'Allow access to router'
set firewall name DMZ-INBOUND rule 5 destination address '192.168.13.1'
set firewall name DMZ-INBOUND rule 5 log 'disable'
set firewall name DMZ-INBOUND rule 5 protocol 'all'
set firewall name DMZ-INBOUND rule 5 source address '192.168.13.0/8'

... and it allows command completion in its bash shell (i.e. type set, <tab>, get a list of options, type firew<tab>, get firewall etc).
A way of working with commands would be in the Microsoft Windows diskpart utility.

Thanks to ludob for helping me with fpcup... He implemented a state machine to process commands.

I was thinking you could probably write a state machine to interpret the commands mentioned above and convert them to objects which you could display on a GUI and manipulate.
Can you then do the same in reverse: e.g. go from objects to commands?
One thing that worries me a bit is that e.g. a firewall and NAT setting will interrelate and interact with one or multiple physical or virtual network adapters/NICs... so the modelling of the objects might be quite tricky.

I'd like your input and ideas: am I on the right track? Are there perhaps comparable situations/programs I can look at?

Thanks,
BigChimp

[KpjComp]

I'm not 100% sure what your trying to do here.

But I'm assuming you talk to your router via telnet.

If I'm reading you right, then the answer depends on what command your router has.
The first command that would be required would be something that fetched your firewalls current status, and then with this you could update your GUI objects, and changes on your GUI objects could then be sent back to the router, and all this could yes be done using some Winsock programming.

[BigChimp]

Thanks for answering KpjComp. I realize I'm being a bit vague.

Communication with the router is another issue (I have a choice between SSH, telnet, and SNMP; perhaps I'll start with SSH as that will also be useful when doing similar things on Linux etc).

What I'm having trouble with is the representation of objects, the way to translate them, and what GUI to show to the user.
Example: user wants to forward a port to a server in the DMZ.
Suppose the program GUI shows the router, the WAN and LAN connections, and their status (green=up, red=down), as well as the servers/machines connected to the other ends.
In the program GUI, he might click on the WAN connection and drag it to a server. The program will ask him if he wants to forward a port; he says yes, selects port 80, TCP.

The program will now know it has to create a NAT rule to forwrd from e.g. WAN interface eth0 to LAN interface eth2, IP destination address=the address of the server.
At the same time, the GUI will need to create a firewall rule to allow traffic to port 80.
Then, it will need to output this in a similar format to my first post.... and e.g. send it via SSH, but that's a separate discussion.

Now imagine the user wants to modify this port forward to also allow UDP=>the program will need to read in the NAT+firewall rules and rewrite them.

So I will probably have various objects on different levels of abstraction: the high level user/GUI view (e.g. a port forward, a desktop with a DHCP assigned address and DNS name) and a representation of the commands/settings in the router (e.g. DHCP setup/assignments, DNS rules, NAT rules, firewall rules, DNS setup/assignments, static routing tables).

As far as the GUI is concerned: I might need to have a high level view as described above, but it may also make sense to allow click through to lists of the objects with rules mentioned above (e.g. from a port forward to the NAT, and firewall rules)... or perhaps not.

Oh, I'm going to release it as open source (probably dual MIT and LGPL with linking exception licensed, so you're free to do anything you like with it).

Hope this clarifies things,

thanks,
BigChimp

[KpjComp]

Communication with the router is another issue

It's an issue your best deciding up front, as this may have an effect on your design later.  There is of course HTML, most routers nowadays have a WebPage front ends.  Here is my take on the pro & cons of each.

SNMP:  Pro: It's a standard protocol for routers etc, so your program is more likely to work with other brands.  Con: Like any strict protocol, if the router has feature that don't fit the glove your not going to be able to represent them.

TELNET: Pro: This protocol should basically give you access to everything.  Con: The command/interface are going to be different from make to make.

SSH: Should be the same as Telnet, just more secure.

HTML: Pro: Your application is less likely to be blocked by firewall & be proxy friendly.  Con:  Parsing HTML is not that easy, and like Telnet it's not standard between makes/models.

Whatever protocol you use, my suggestion is to implement a registration system.  eg. Like Delphi/Lazarus does with it's components.

[BigChimp]

It's going to be SSH: I can perhaps extend the program to e.g. Linux, OSX, even Windows machines that won't have SNMP.
Also to telnet to ADSL modems etc.
Re your HTML remark: well... being blocked by firewalls shouldn't be a problem because the program is meant to manage the firewall

My idea right now is to have 3 layers and some translation mechanisms :
- GUI layer: objects the user interacts with
- logical layer: has objects like NAT, firewall. Can perhaps be platform agnostic
- device layer: the commands to be sent/that are read from the device (SSH/Telnet), or converted into SNMP instructions (if support for SNMP is added)

Note: this will be difficult enough for me as-is; I'm thinking of a layered model so I can fairly easily adapt this to another router model etc, but I realize I'll first have to program it and work with it to see how it goes. This means that a rewrite is necessary later on to properly separate things.
What I want to avoid is to start with the wrong assumptions, so that's why I'm asking

[KpjComp]

being blocked by firewalls shouldn't be a problem because the program is meant to manage the firewall

Not your firewall.  But say you wanted to maintain your router remotely, HTML is less likely to be blocked by a firewall, eg. Say you wanted to check your router from an Airport for example.  SSH might be blocked, but HTML certainly won't, no amount of changes to your router will help here, unless you put SSH on port 80, but even then the Airport might be using a proxy.  Of course HTML on port 80 isn't secure, but most routers also implement HTTPS too on port 443, and again this less likely to be blocked, otherwise people at airports wouldn't be able to check there bank details.

Like I said, use a registration system.  You could even have different registration systems for different Make/Models.  This would be like a database that grows as more routers are added.

[KpjComp]

Oh, also interfaces are a nice construct for dynamic objects like these.

eg. you could then have constructs like ->

Code: [Select]

if supports(baserouterObj, INatForwarding) then
  AddNatForwardingObj( (baserouterObj as INatForwarding).GetNatForwarding );
 

[ludob]

My idea right now is to have 3 layers and some translation mechanisms :
- GUI layer: objects the user interacts with
- logical layer: has objects like NAT, firewall. Can perhaps be platform agnostic
- device layer: the commands to be sent/that are read from the device (SSH/Telnet), or converted into SNMP instructions (if support for SNMP is added)

Conceptually that is the right thing to do. Make a router object model with a gui on top and a device interface below.
Regarding the title of the post, you could start with the assumption that the router is configured only through your tool, store the router config at the object model level (XML,json,...) and only implement the writing part in the device interface. Storing router configs at object model level is a must for such a tool in any case as it allows for easy migration and cloning between different makes of routers.

Note: this will be difficult enough for me as-is; I'm thinking of a layered model so I can fairly easily adapt this to another router model etc, but I realize I'll first have to program it and work with it to see how it goes. This means that a rewrite is necessary later on to properly separate things.

I would advice you to start with the layered model right from the beginning. You can ease things by not starting with self-registering device modules but a simple hard coded router object to device interface (write to device only) and by creating a very basic GUI. But thinking over and design correctly your router object model is very important as it is going to be the basis for all further development.

[BigChimp]

Edit: small error
Thanks Ludo, glad I'm on the wrong right track.

Yes, I do intend to start with the layered model but realize I might need to clean it up/cater for device specific anomalies that may have crept in as I start with one router model.

Writing out the entire config is indeed the easiest thing to do... which at least Vyatta and probably Cisco etc also support: you load the config and then activate it.

Thanks,
BigChimp

[BigChimp]

being blocked by firewalls shouldn't be a problem because the program is meant to manage the firewall

Not your firewall.  But say you wanted to maintain your router remotely, HTML is less likely to be blocked by a firewall, eg. Say you wanted to check your router from an Airport for example.  SSH might be blocked, but HTML certainly won't, no amount of changes to your router will help here, unless you put SSH on port 80, but even then the Airport might be using a proxy.  Of course HTML on port 80 isn't secure, but most routers also implement HTTPS too on port 443, and again this less likely to be blocked, otherwise people at airports wouldn't be able to check there bank details.

Thanks KpjComp, point taken, but I'd rather stay away from HTTP(S) interfaces for now if it means scraping HTML etc. as long as I have alternatives. Of course, if there is no choice, there is no choice
I can always let my router's SSH or VPN server listen on port 443;)

Like I said, use a registration system.  You could even have different registration systems for different Make/Models.  This would be like a database that grows as more routers are added.

Thanks, I'll probably start very basic as Ludo suggested (probably only specific functionality such as DHCP/DNS), then add full functionality, then another router/device in order to test the model.
At that time a registration seems indeed like a good plan.

Thanks for thinking along; further tips and hints of course welcome: e.g. on how to layout the GUI: are there examples for drawing e.g. objects - servers & networks - programmatically? How can I detect interaction with these objects etc).
Also: suppose I'm using SNMP and only want to send over the differences (e.g. new DNS+DHCP registration) => I'll need to detect and track changes between objects, perhaps compare them=>perhaps write out some state machine script as the properties get changes - yes, I've discovered state machines now - or is there another way of doing this?

Anyway, once I get started I'll surely come back with more questions (still have some FPC+Lazarus database stuff brewing along)...

[KpjComp]

I can always let my router's SSH or VPN server listen on port 443;)

But it still won't proxy, but anyway that was just a pro for HTML.  I'd personally go SSH too, as it's going to be easer to parse.

how to layout the GUI, How can I detect interaction with these objects etc)

Well with out of the box Lazarus component, you could descend from a TGraphicControl, or if you have got complex controls on them a TWinControl, with this you get all your interaction events too.  I designed a Referential Integrity designer this way, worked really well.  Here my Fields were just placed on a descended TPanel, and my links were just TGraphicControls.  I just then used standard Drag & Drop for creating the links between fields.

More graphical options might be either Graphic32, or you could even use GLScene for a 3D GUI.  CodeTypon has some very nifty controls too called Lava, I'd say they look better than firemonkey.

[BigChimp]

Thanks, Kpjcomp!

[IPguy]

Misc thoughts on the above, as an ex-network engineer / architect for the last 15 years.

My thoughts pertain to managing devices within a company / enterprise, not across the public internet.

- While it varies by company, in general http is disabled on network devices where possible.  https might be permitted.
- Telnet should not be used (Security can see the passwords)
- SSH should always be used
- I've used expect/tcl quite a bit when I wrote scripts to change router settings, especially easy stuff like snmp string, passwords, logon banners, etc ...

You will probably want to maintain a state config of each network device
  - capture the config as a baseline, parse it down into the various attributes and objects and timestamp it.
  - when you touch the device again, grab the current running config and create a diff table and stash the diff'd section in your object repository.
  - as you make changes, update your object repository.    That way, you can always walk backwards.
  - probably want to have an impact flag / description for each object, so you have an idea of what will / might happen when the change is applied.

You will also need to do an audit on the config-let you are pushing to make sure it is legal.

There are subtle and not so subtle configuration differences between Cisco's, Avaya(Nortel), Extreme, Juniper, HP, HP-3Com, HP-Huawei, Arista, etc ... as well as between the various Cisco models.  (Cisco Nexus vs IOS vs CatOS, routers vs switches vs WAP, etc...)

[BigChimp]

Thanks, much appreciated, IPGuy, that makes sense.. I'll surely start posting again when I've started work on this..