Iptstate add-on suggestion

Hi,
Does anyone know if any consideration has ever been given to integrate the Iptstate tool as an add-on to IPFire ? Because this tool actually allows for an easy viewing of traffic states, sources and destinations in real-time. It is a GREAT and highly recommended tool for troubleshooting application connectivity, analysing suspicious traffic, viewing the effectiveness of firewall rules, and basic live security monitoring etc.

https://linux.die.net/man/8/iptstate
https://pkgs.org/download/iptstate

### Building: prerequisites:
Make sure you have some version of curses installed (for most users this is probably ncurses). Note that if you are using vendor packages you will most likely need the packaged with ā€˜-dev’ on the end of of it (i.e. ncurses-dev).

Starting with version 2.2.0, you also need libnetfilter_conntrack version 0.0.50 or later. These libraries also require nf_conntrack_netlink and nfnetlink support in your kernel. You will also need pkg-config at build-time.

Some firewall rules involving the -m conntrack or --ctstate options are often necessary to obtain a top display.

I would also note that the netstat command could be equally important for traffic logging purposes via command line. Needless to mention that good detective measures are tremendously important to help optimize preventative measures, for those who understand and care about network security.

Hello.

I’m speaking from a lack of knowledge of the add-on you’re referring to, but there is one available called iftop.

Bye.

There are several similar tools out there including iftop and iptraf-ng etc.
But they do not display the traffic information in the same manner for network traffic analysis like iptstate that makes it very quickly and easily understandable for humans. What is very important at the very minimum is:
The transport layer protocol: TCP, UDP, IGMP, ICMP, etc.
Then the connection information happening on the network layer, including:
the IP source/destination the Port source/destination
and the connection state, TTL, etc.

So, iptstate gives us a good and nicely displayed summary of what’s happening on Layer 3 and 4 in real-time..

I would also note that the netstat command could be equally important for traffic logging purposes via command line. Needless to mention that good detective measures are tremendously important to help optimize preventative measures, for those who understand and care about network security.

Perhaps you are looking for more granular data, but I use the WUI ā€œStatusā€ ā€œConnectionsā€.

4 Likes

There is a lot of that already installed. Its just asseembling things in a nice way inside the webgui.

But that particular one (ipstate) can be used to create a botnet as its been used in botnet scripts that was shared to Linux network security analysts. So I would definitely not have that installed on a machine.

Edit: Since @bonnietwin already told @pokspeter not to post this question again, he might get sent to the dog house and be put in time out.

This post is fine. It was having the same content in another post that is not fine as you then have a duplicate post which ends up with some replies on one and some on the other.
For one topic just have one post thread.

3 Likes

Hi,
If you can assemble real-time traffic data for viewing on a web GUI interface in a fast and similar way iptstate does, that should be fine in my view. Please note that iptstate runs on a terminal and has no GUI of its own, and I personally run it on every linux system I use not only to spot potential bad actors trying to connect to my network, but also to make sure I have no malware or compromised apps on my system that might be establishing connections to remote resources. So if you really care about running a clean Linux OS of any distro or making sure there are currently no spyware or malware creating suspicious remote connections in your product, iptstate can only be your friend in my view, and can help you investigate and clean that up..
That being said, I’m very puzzled, unaware and curious about the story of iptstate being used in a botnet script. Could somebody share more light or evidence with some urls supporting such allegations?

On the other hand, there’s another interesting software called ntopng currently used in products like OPNsense and PFsence. After tryning it in Ubuntu, I found ntopng to be more sophisticated, certainly slower than iptsate and could not display the information that really matters to me in real-time. But feel free to check it out below as well.

Also bear in mind that a web GUI of any kind alone could add an additional attack surface to any system hosting it. That’s why minimal installations of any servers do not depend on GUIs of any kind. Even Microsoft has learned that lesson several years ago from Linux, by introducing minimal versions of the Windows Server. So at the end of the day, I think IPFire already has good enough and necessary GUI to help easily manage the Router, Firewall and Add-ons etc. So it could make good sense in my view, to prioritize additional Add-ons that run from the terminal rather than overloading the Main Router management interface.

(post deleted by author)

1 Like

Hi,
Are your script examples referring to ipState or IPTState?
Please note that IPTState means IPTables State Top. So this is a package that scans the conntrack tables and displays connection results in real-time on a terminal window. Basically every (TCP, UDP, ICMP, IGMP, etc) connection from the entire linux kernel going through IPTables is tracked and displayed.
Just so you understand what I’m talking about here…

1 Like

Well, it looks like somebody should apologize for confusing ipstate with iptstate.
What do you think?

I’m very confident that if you successfully install and use iptstate in IPFire, you’ll end up discovering at least a few strange things about IPFire in its current state and other currently installed software in it, including the impact of a browser itself.

After all necessary clean ups are made, there will be a better focus on threats from external sources, and this could provide a solid reason (proof) to brag about IPFire running in a very clean environment as opposed to other competitive products. Security threats and vulnerabilities mostly rely on some blindness in order to remain hidden and make their desired impact. That should change, and awareness has to be raised about the importance of GOOD real-time traffic visibility and understanding…

I mean it has become very important to understand the nature and purpose of every any connection initiated from a given environment whether it’s malware activity or software checking versions, sharing info, or looking for updates etc. The initiator and purpose of every connection has to be identified, analyzed and understood to achieve a real solid security posture nowadays.

Sorry about that.
Well that one wouldn’t be hard to bring in. Just looks like they didn’t bring it in because the code is a little old or didn’t look like there was someone maintaining it.

Apologies accepted.
As far as the code and maintenance, I can only say that I’ve been using this package since version 2.2.5 that goes back over 10 years ago, but it has now reached version 2.2.7.

So my guess is that although it serves a very good and interesting purpose with relatively simple code, there hasn’t been a huge need to update/upgrade its code very regularly. But I currently have no reason to believe someone is not maintaining it.

If you have more questions about the code or maintenance status, please feel free to contact Phil Dibowitz (phil AT ipom DOT com) directly if necessary.

And please take the time to do a bit of quick online research every now and then, before making some statements. Nice GOOGLE queries can be quickly useful very often.
I have ZERO personal gain in this or any relationship with the maintainer of this package, but I recommended it because as a developer and security professional myself (very long time user of iptstate), I understand how useful this might become for IPFire. And if successfully implemented in IPFire, I wouldn’t be surprised that others follow suit.

One last comment:.
Allowing people to view live traffic information coming in and out of any connected endpoint (from a middle routing position) and considering the way this tool displays information (in a simple but efficient manner), could become very revealing and would help confirm things that a lot of people don’t know about, and some only know in theory…
As they say, the quieter you can become, the more you can hear…

I will check this…

Hi all,
have made a fast build of IPTstate with the following compiler output

ipfire build chroot (x86_64) root:/tmp/iptstate-2.2.8_dev$ make
+------------------------------------------------------------+
| Welcome to IP Tables State by Phil Dibowitz                |
|                                                            |
| PLEASE read the LICENSE and the README for important info. |
|                                                            |
| You may also wish to read the README for install info,     |
| the WISHLIST for upcoming features, BUGS for known bugs    |
| and info on bug reports, and the Changelog to find out     |
| what's new.                                                |
|                                                            |
| Let's compile...                                           |
+------------------------------------------------------------+

g++  -O2 -g0 -pipe -Wall -fexceptions -fPIC -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection -m64 -mtune=generic -fcf-protection=full  iptstate.cc -o iptstate -lncursesw -lnetfilter_conntrack -lnfnetlink
iptstate.cc: In function 'WINDOW* start_curses(flags_t&)':
iptstate.cc:609:7: warning: variable 'y' set but not used [-Wunused-but-set-variable]
  609 |   int y, x;
      |       ^
iptstate.cc: In function 'void switch_scroll(flags_t&, WINDOW*&)':
iptstate.cc:706:10: warning: variable 'y' set but not used [-Wunused-but-set-variable]
  706 |   int x, y;
      |          ^
iptstate.cc: In function 'void get_input(WINDOW*, std::string&, const std::string&, const flags_t&)':
iptstate.cc:753:10: warning: variable 'y' set but not used [-Wunused-but-set-variable]
  753 |   int x, y;
      |          ^
iptstate.cc: In function 'int conntrack_hook(nf_conntrack_msg_type, nf_conntrack*, void*)':
iptstate.cc:1080:31: warning: ':' directive output may be truncated writing 1 byte into a region of size between 0 and 5 [-Wformat-truncation=]
 1080 |   snprintf(ttlc, 11, "%3i:%02i:%02i", hours, minutes, seconds);
      |                               ^
iptstate.cc:1080:22: note: directive argument in the range [-59, 59]
 1080 |   snprintf(ttlc, 11, "%3i:%02i:%02i", hours, minutes, seconds);
      |                      ^~~~~~~~~~~~~~~
In file included from /usr/include/stdio.h:970,
                 from /usr/include/c++/14.2.0/cstdio:42,
                 from /usr/include/c++/14.2.0/ext/string_conversions.h:45,
                 from /usr/include/c++/14.2.0/bits/basic_string.h:4154,
                 from /usr/include/c++/14.2.0/string:54,
                 from /usr/include/c++/14.2.0/bits/locale_classes.h:40,
                 from /usr/include/c++/14.2.0/bits/ios_base.h:41,
                 from /usr/include/c++/14.2.0/ios:44,
                 from /usr/include/c++/14.2.0/istream:40,
                 from /usr/include/c++/14.2.0/fstream:40,
                 from iptstate.cc:49:
In function 'int snprintf(char*, size_t, const char*, ...)',
    inlined from 'int conntrack_hook(nf_conntrack_msg_type, nf_conntrack*, void*)' at iptstate.cc:1080:11:
/usr/include/bits/stdio2.h:68:35: note: '__builtin___snprintf_chk' output between 10 and 16 bytes into a destination of size 11
   68 |   return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   69 |                                    __glibc_objsize (__s), __fmt,
      |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   70 |                                    __va_arg_pack ());
      |                                    ~~~~~~~~~~~~~~~~~

All done. Do 'make install' as root and you should be set to go!

the changelog from 2021 (also last release) lines also the fix of compiler warnings out but with new compilers some more stuff comes up. The ttlcs buffer size can lead to a buffer overflow which should be fixed IMO.
If you use this tool extensiv you can may help the developer by reporting and may fixing these things ?

First idea to fix both problems:

diff -Naur iptstate-2.2.8_dev.orig/iptstate.cc iptstate-2.2.8_dev/iptstate.cc
--- iptstate-2.2.8_dev.orig/iptstate.cc	2025-04-23 10:51:00.484970700 +0000
+++ iptstate-2.2.8_dev/iptstate.cc	2025-04-23 11:10:57.993010120 +0000
@@ -606,7 +606,7 @@
  */
 static WINDOW* start_curses(flags_t &flags)
 {
-  int y, x;
+  int y __attribute__((unused)), x;
   initscr();
   cbreak();
   noecho();
@@ -703,7 +703,7 @@
  */
 void switch_scroll(flags_t &flags, WINDOW *&mainwin)
 {
-  int x, y;
+  int y __attribute__((unused)), x;
   if (flags.noscroll) {
     getmaxyx(stdscr, y, x);
     // remove stuff from the bottom window
@@ -750,7 +750,7 @@
    */
   
   input = "";
-  int x, y;
+  int y __attribute__((unused)), x;
   getmaxyx(stdscr, y, x);
   WINDOW *cmd = subpad(win, 1, x, 0, 0);
   if (!flags.nocolor)
@@ -1035,7 +1035,7 @@
   // some vars
   struct protoent* pe = NULL;
   int seconds, minutes, hours;
-  char ttlc[11];
+  char ttlc[16];
   ostringstream buffer;
 
   /*
@@ -1077,7 +1077,7 @@
   minutes = minutes%60;
   seconds = seconds%60;
   // Format it with snprintf and store it in the table
-  snprintf(ttlc, 11, "%3i:%02i:%02i", hours, minutes, seconds);
+  snprintf(ttlc, 16, "%3i:%02i:%02i", hours, minutes, seconds);
   entry->ttl = ttlc;
 
   entry->family = nfct_get_attr_u8(ct, ATTR_ORIG_L3PROTO);

Have build it with this patch with the following results

iptstate-2.2.8_dev.tar.gz checksum OK
====================================== Installing iptstate-2.2.8_dev ...
Install started; saving file list to /usr/src/lsalr ...
cd /usr/src/iptstate-2.2.8_dev && patch -Np1 < /usr/src/src/patches/iptstate-extend_buffer-mark_unused_var.patch
patching file iptstate.cc
cd /usr/src/iptstate-2.2.8_dev && make -j4
make[1]: Entering directory '/usr/src/iptstate-2.2.8_dev'
+------------------------------------------------------------+
| Welcome to IP Tables State by Phil Dibowitz                |
|                                                            |
| PLEASE read the LICENSE and the README for important info. |
|                                                            |
| You may also wish to read the README for install info,     |
| the WISHLIST for upcoming features, BUGS for known bugs    |
| and info on bug reports, and the Changelog to find out     |
| what's new.                                                |
|                                                            |
| Let's compile...                                           |
+------------------------------------------------------------+

g++  -O2 -g0 -pipe -Wall -fexceptions -fPIC -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -fstack-clash-protection -m64 -mtune=generic -fcf-protection=full  iptstate.cc -o iptstate -lncursesw -lnetfilter_conntrack -lnfnetlink

All done. Do 'make install' as root and you should be set to go!

have tested the patched version a little on IPFire and so far it works.

Apart from that and as mentioned above, connections.cgi makes a similar job, also, the IPTstate project seems to be off or at least outdated but maybe you can help out to (test first and) update it ?

Best,

Erik

P.S.: ntpong is not comparable to IPTstate →

  • iptstate a tool for real-time inspection of the connection state table—good for quick, terminal-based diagnostics on firewalls.
  • ntopng is a extensible network traffic analysis platform, providing deep visibility (nDPI), analytics, and reporting for entire networks.
2 Likes

Hi @pokspeter ,
may not a realtime substitution but may a similar static overview like IPTstate → Search and filtering in connections.cgi ?

Best,

Erik

Hi Eric,
The link you just posted apparently refers to a totally different solution for other potential needs. Not a substitute to IPTState at all in my view. The REAL-TIME visibility makes all the difference in matters of observability, troubleshooting or even security. Sophisticated malicious actors usually manage to find their ways into covering their tracks before you get a chance to see or suspect anything abnormal. So IPTSTate is quite simple but very efficient in displaying the info that really matters in many regards and in real-time, for those who care to understand what they see.

I’m in the meantime, very curious about what REALLY made you come up with such a suggestion after a successful test of IPTState in IPFire as you previously reported:

  • Is it really not possible to integrate both IPTSTate and the new Search and Filtering function into IPFire?
  • Did you run into some new technical issues for which you might need some help?
  • Are you under some pressure to keep IPTSTate away from IPFire so we can all remain blind to suspicious or malicious network activity?

I know how much it is a big deal to have such a simple solution put in place here. So in a way, I’m not very surprised to see some resistance, but I expect you guys to do the right thing if you really care about open source reliability and information security overall.

By the way, I did notice that iptraf-ng is already part of ipfire. So why not just do the same for iptstate?

Again, I think you have a unique opportunity and responsibility here, to show people what’s going on with their network regarding the state of traffic, in a very simple but efficient way. And that could greatly benefit ipfire at least for a while…

Regards.

Hi @pokspeter and thank you for your overview of the code? Did you checked it ? For me it is not a big deal, just an idea to get more close to some other (also your) ideas ? What is your technical issue about all that and whats the difference i can not see it in your opinion nor in your testings :wink: ? I can“t see resistance here at all but development (see above ?!?!?!?) but if you like, help me (ONE that would help) to find out more ?! I am also not very suprised while checking some more and can not find someone who is really interessted in some new ideas but want to have something. Is it realtime only ? Are you good to go by reporting potential bugs to the IPTstats developers (haven“t seen it, but checked it :wink: ) or even to IPFire developments ?

Anyways, thank you for your response.

Best,

Erik

Hi,
No software is ever perfectly built.
So, if the issue about this project has come down to addressing potential bugs or other technical issues, please feel free to be more specific about any potential problems you’re facing and hopefully you might get further assistance here.

And by the way, I already previously shared info about the developer and maintainer of the IPTState package Phil Dibowitz and he seems quite willing to assist with any issues or bugs. So why not contact him directly for help if you’re really technically stuck?

Sure, but what project you are talking about :grinning_face: ?

I’m not sure to follow you with your question.
My understanding was that you’re suddenly having some trouble properly implementing iptstate to ipfire. Is that right or not?