Now that is a very good answer that points in the right direction to definitively answer the question "what ports are being used on my system".
The Packet Filtering that Sylvain references has the further ability to define rules that limit how much data you are going to journal. In my mind, every packet for every connection is way too much to journal.
If you are interested in which ports are being used, and who is using them, you really only journal the first packet for each connection. Fortunately, for TCP/IP connections, the first packet is a SYN packet that starts the establishment of the connection.
The packet rules allow you to select those specific packets with the TCP/STARTING protocol selector so you'll only log that first packet.
I just tested this with the following ruleset on a lab system:
FILTER SET LogConnections ACTION = PERMIT DIRECTION = INBOUND SRCADDR = * DSTADDR = * PROTOCOL = TCP/STARTING DSTPORT = * SRCPORT = * JRN = FULL
FILTER SET LogConnections ACTION = PERMIT DIRECTION = * SRCADDR = * DSTADDR = * PROTOCOL = * DSTPORT = * SRCPORT = * JRN = OFF
FILTER_INTERFACE IP_ADDRESS = {your interface ip address here} SET = LogConnections
The first rule says to accept all inbound TCP starting connections from anywhere on any port and log it to the journal
The second rule overrides the default deny all rule and accepts all packets on all protocols without logging (basically this is what you get without any rules)
With this rule installed, every TCP connection ATTEMPT gets logged with a M-TF entry in QIPFILTER journal. That is the easiest way you will get a list of all ports being used. Do note that this is connection attempts -- it will log attempts on ports that are not getting listened on also. Ideally, you would log the outbound SYN-ACK that shows a connection was established instead of just the attempts, but that does not appear to be possible.
Run that for a sufficient period to catch your normal traffic and then analyze with an SQL service:
WITH filterlog AS (
SELECT CAST(ENTRY_DATA AS VARCHAR(1000)) AS entry
FROM TABLE (
QSYS2.DISPLAY_JOURNAL('QUSRSYS', 'QIPFILTER', JOURNAL_ENTRY_TYPES => 'TF')
)
)
SELECT SUBSTR(entry, 1, 10) AS line,
SUBSTR(entry, 29, 15) AS Srcip,
SUBSTR(entry, 44, 5) AS Srcport,
SUBSTR(entry, 49, 15) AS DestIP,
SUBSTR(entry, 64, 5) AS DestPort
FROM filterlog
Group BY DestPort;
You can use the same rules to restrict the ports that can be used once you determine what is normal for your environment. That would address the ability to have a program listen on any port. It doesn't matter if they are listening if you block anyone that tries to talk to them.
This only logs TCP traffic. Other protocols, such as UDP and ICMP don't have that handshake that allows easy detection of the start of a conversation, so if you want to track those, you will need different rules.
------------------------------
Vincent Greene
IT Consultant
Technology Expert labs
IBM
Vincent.Greene@ibm.comThe postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
------------------------------
Original Message:
Sent: Thu July 04, 2024 11:21 PM
From: Sylvain Manceau
Subject: Checking for configured ports on IBMi
To get traffic log in a journal, one could use the integrated Packet Filter with an "allow all" filterset and journaling to "Full": https://www.ibm.com/docs/en/i/7.5?topic=mpr-journaling-auditing-packet-rules-actions-by-packet-rules .
------------------------------
Sylvain Manceau
Original Message:
Sent: Tue July 02, 2024 01:29 PM
From: Robert Berendt
Subject: Checking for configured ports on IBMi
There's inbound ports, and there's outbound ports. Inbound ports generally stay active unless you end the service. For example, ftp port 21 stays active unless I ENDTCPSVR SERVER(*FTP).
Outbound ports are a different animal and often can be quite random. For example if I ftp FROM this IBM i to another server might go out on port 9393 (this time, as tested).
I know that firewall/switch personnel like to lock down specific IP addresses and ports. Most of them understand ephemeral ports (like the port 9393 example above). Careful, as they will sometime track a weeks worth of usage and base their decision off of that. Which may cause issues when you only run certain stuff outside of that test period such as SNDPTFORD, SNDSRVRQS. Then there's also the case if your IBM i supports multiple IP addresses, like for multiple web sites, domino servers, H/A software routing, etc and some IP clients don't support "bind specific". For example, if I telnet from an lpar with multiple IP addresses which one am I coming from?
You can do a STRCMNTRC to capture some of this. And it will even generate a pcap file, loved by many a network technician. DMPCMNTRC CFGOBJ(LANLINSYS) CFGTYPE(*LIN) TOSTMF('/home/ROB/myfile.pcap') FORMAT(*PCAP)
I don't believe there are any ways to journal these through journals, qhst, etc.
See also: https://www.ibm.com/docs/en/i/7.5?topic=is-communication-services
------------------------------
Robert Berendt IBMChampion
Original Message:
Sent: Tue July 02, 2024 05:35 AM
From: Thomas Varkey
Subject: Checking for configured ports on IBMi
Hi,
Is there any way to check which ports have been configured for use on IBMi (but not currently active).
NETSTAT *CNN gives the "Active" ports at any point in time and CFGTCP , option 4 gives you any port restrictions.
However, I am looking for an easy way to find out "list of all ports which are configured but NOT CURRENTLY ACTIVE"
Any guidance would be appreciated. Thank you.
------------------------------
Thomas Varkey
------------------------------