Diagnostics: Show States …... WHOIS?

jimp

No real compelling reason why it doesn't at least do block and DNS, just that nobody has bothered to code it yet. Whois is a bit tougher as there isn't a built-in PHP method of doing that, we'd have to do a shell exec, but it could be done.

The page will have to be reworked for 2.2 anyhow since the output format changed from pf, add a feature request ticket.

The only potential problem I can see is that with a huge state table (e.g. a few hundred thousand entries, or over 1M) then any additional controls that get duplicated will greatly increase the size of the page and its ability to be rendered by browsers.

The firewall log displays, at most, 2000-3000 entries (the log can't hold more than that) so that problem doesn't exist there.

jimp

Restricting the controls to only the first X entries, or only showing when using filtering would alleviate some of that problem, but isn't really a perfect/ideal solution either.

Clear-Pixel

The main filtering is being done by Pfsense by using firewall port rules

Home setup Example:
Ports open
53
80
443

Number of States per user
Anywhere from 0 to 300 states

Note: In general there is nothing that will stop a hostel IP from connecting to any port listed above.

Yes, there can be many states and that is all more the reason to give the admin the tools to do common States security task efficiently. Admins need tools in the states table to initiate investigations on an IP. Admins should know what computers and servers are connecting to their network. If admins are not monitoring/investigating the states table on their network they can NOT legitimately say there network is secure.

If I want to know what server connections have been initiated on my network I'm going to look at the States table or Summery table. This should be one of the very first stops to investigate and enforce security on your network. The Admin has to determine what is a legit connection and what is not, there are no tools in the states table to perform this important task. Easily being able to resolve IP's would be a nice start. If admins could see what the IP resolved to by clicking on the IP they could more easily detect doggy connections based on the name …. or easily find connections they wish to permanently block.

How can you call a network secure if you do not have the tools to investigate and enforce rules on the VERY IMPORTANT states table effectively?

Do you know what company and geo location for the IP's below?
117.27.138.148
74.126.177.42
96.47.225.170
110.85.115.226
112.111.184.164
192.157.250.2
216.99.152.122

No, because you cannot resolve them in the Pfsense States table nor the Summery table. Most humans would have no idea just looking at a IP ….. They are all Hostel Servers listed above! ......Another reason why there should be an Option for an IP lookup and to Permanently Block connections that the admin feels is invasive to their network.

If there is a concern about computer resources have it as a (Option ON or OFF) or a package.

I don't understand why this wasn't addressed years ago ::)

jimp

We already agree it is a good idea, no need to keep trying to convince me. :-)
That's why I suggesting adding a feature request ticket for it targeting 2.2

As long as performance concerns are kept in mind, it can be done. Provided someone with the know-how, time and/or funding can code it up.

Rezin

This Greasemonkey script (link) may provide some of what you're after.

Even though I haven't tested it in pfSense 2.1, hopefully the Show States page hasn't changed that much since 2.0.3 to cause issues with the script.

Edit: The links for each IP with blue text shown in the screenshot point to the DNS Lookup page.

![pfSense States DNS Lookup.png](/public/imported_attachments/1/pfSense States DNS Lookup.png)
![pfSense States DNS Lookup.png_thumb](/public/imported_attachments/1/pfSense States DNS Lookup.png_thumb)

Clear-Pixel

Thank you Rezin…

I pasted the code in the diag_dump_states.php file before the tag and got no results. No errors where shown in fireFox so I assume there has been changes in the 2.1 version of Pfsense. I have scanned over your code but will take a bit of time to study the structure to see if I can modify it to work with 2.1

Again thanks.

Rezin

It'd be better if you installed the Greasemonkey add-on for Firefox to run this script, but I guess if you move what you pasted into that PHP file so that it's not before the tag, but before the closing tag, it would work as well.

Also, just tested the script against pfSense '2.1-BETA1 (i386) built on Wed May 22 08:31:50 EDT 2013', and it works fine too.

Clear-Pixel

Moved code before the close of body tag and it is functioning … ;D

I have been looking at the firewall gadget which has the same function but appears in a popup which is rather nice. I have scanned all over the firewall gadget java code looking for all of the key components which hyper links the IP to the whois popup but has alluded me so far which is rather odd because I am rather savvy at this task. Would be nice to add some code to do the same with yours ;)

Again thanks ..... at less by having a quick method in the states table to resolve the IP's connected to my firewall I can investigate ones which seem suspicious or unnecessary and block them..... Now if there was a button which would automatically add them to a block list rather then doing it manually.

Rezin

@Clear-Pixel:

Now if there was a button which would automatically add them to a block list rather then doing it manually.

As the states page stands at the moment, there isn't a way to do that as the interface isn't shown anywhere for the rows - the 'Easy Rule: Add to Block List' link on the firewall log page has a link like this:

/easyrule.php?action=block&int=wan&src=aaa.bbb.ccc.ddd

There may be a way to add the interface name somewhere in the PHP code, but I'm not sure.

Clear-Pixel

@Rezin:

As the states page stands at the moment, there isn't a way to do that as the interface isn't shown anywhere for the rows - the 'Easy Rule: Add to Block List' link on the firewall log page has a link like this:
/easyrule.php?action=block&int=wan&src=aaa.bbb.ccc.ddd

There may be a way to add the interface name somewhere in the PHP code, but I'm not sure.

I will take a look over the next few days and see what I can do …. may end up fruitless as you have said.

By the way, the states filter is a very nice add-on also.... working just fine by inserting the code directly into diag_dump_states.php file. ;)

Clear-Pixel

I got the states page working with Easy Rules, but I dont like the way Easy Rules adds a new Firewall Rule every time you block a IP on the states page. The easy rule in the method I'm using it for should add the new blocked IP with a option to add to the description of why I'm blocking the IP. Or maybe what needs to happen is you have a option to add the new blocked IP to a existing rule.

Easy Rules is easy but makes a unnecessary mess of the Firewall Rules.

Maybe I should rework the code for the states table to work with Pfblocker?

States-with-Easy-Rule-Block_03.png_thumb

jimp

@Clear-Pixel:

I got the states page working with Easy Rules, but I dont like the way Easy Rules adds a new Firewall Rule every time you block a IP on the states page. The easy rule in the method I'm using it for should add the new blocked IP with a option to add to the description of why I'm blocking the IP. Or maybe what needs to happen is you have a option to add the new blocked IP to a existing rule.

Easy Rules is easy but makes a unnecessary mess of the Firewall Rules.

Normally it will make an alias for an interface, and add all IPs to that alias for a given interface. Though on the states page, the interface is not usually known because the states are not bound to an interface. You have to make assumptions or use floating rules or otherwise account for that fact. It's not quite as simple as it is on the firewall rules log where you have every bit of information you need.

@Clear-Pixel:

Maybe I should rework the code for the states table to work with Pfblocker?

pfBlocker is not and never will be in the base OS, so any modifications that make it into pfSense could not rely on it. So if you took that path, the best you could hope for this code is a package that contains the page. That is a perfectly valid way to distribute it, and a great idea if you want to continuously develop the code without being locked to a pfSense release.

Clear-Pixel

With the states not bound to a interface, I just hard coded it to block IP on the WAN interface and relay to Easy Rule alias. It is not perfect as I explained above, will have to see if there are other option that I can code to take care of the odd balled results in the firewall rule duplications for each IP added. There are still a few tweaks I can make before I dump the code here …. it really didn't take but 3 min to mod the code once i figured out the easiest way of going about adding the Easy Rules mod to states table.

I don't believe the limited data available in the Pfsense State is the perfect path to have all available options for analysis as it exist now to paint the entire picture. Part of the problem is I'm not familiar with FreeBSD and there tools available for gathering network information to know what direction to head in unless I dive into it.

I know there are other option such as the dynamic data in PFtop .... etc

I could do it but .... just not sure if I would want to commitment that much time as it would be a rather large task with no financial benefits.

jimp

@Clear-Pixel:

With the states not bound to a interface, I just hard coded it to block IP on the WAN interface and relay to Easy Rule alias. It is not perfect as I explained above, will have to see if there are other option that I can code to take care of the odd balled results in the firewall rule duplications for each IP added. There are still a few tweaks I can make before I dump the code here …. it really didn't take but 3 min to mod the code once i figured out the easiest way of going about adding the Easy Rules mod to states table.

I don't believe the limited data available in the Pfsense State is the perfect path to have all available options for analysis as it exist now to paint the entire picture. Part of the problem is I'm not familiar with FreeBSD and there tools available for gathering network information to know what direction to head in unless I dive into it.

I know there are other option such as the dynamic data in PFtop .... etc

I could do it but .... just not sure if I would want to commitment that much time as it would be a rather large task with no financial benefits.

Doing a firewall rule from there with the limited info is tricky given the assumptions (what about multi-wan? maybe a floating rule to block rather than interface specific?)

But doing DNS at least would be fine, and the existing DNS lookup link/page has links to places to run a whois from there. The firewall rules part was trivial by comparison because everything we needed was already given.

As for the financial part, you could post on the bounties section and see if anyone might be interested in tossing some money your way to help you make the time to do it. If enough other people think it's a good idea and they are willing to donate something to you to get it done, it could at least get you a nice dinner or a book or a new toy. I've done bounties for less. :-)