Original Message:
Sent: Tue July 09, 2024 11:25 AM
From: Vincent Greene
Subject: Checking for configured ports on IBMi
I didn't even know that the packet filtering could be used to write journal entries until I saw your post and started experimenting. It is a very nice solution to a situation that I did not think could be easily solved on IBM i. It was the search for the SYN bit mentioned on that page that led me to TCP/STARTING (since that is the function of the SYN bit)
I did not find any definitive syntax reference for the rules, but my experimentation showed that the TCP/STARTING only captured the first packet in the exchange. Using OUTBOUND & TCP/STARING only got me the first packet in the outbound connections, not the SYN/ACK that I would expect from the response to the initiation of a new connection.
For those that don't know, TCP connections use a three way handshake to establish a connection: SYN, SYN-ACK, and ACK
The initiator sends a SYN packet (I want to connect to your port x from my port Y) (SYN Bit is set in the header)
If the port is open and the connection is accepted by the target, it sends a SYN-ACK packet (SYN and ACK bits set in the header) which means "Glad to hear from you - lets talk, starting with this sequence number, etc"
Finally the initiator acknowledges the connection is open by sending a ACK packet ("Thanks for accepting my call") and the connection is open.
I can still picture Professor Synder in the front of the classroom waving his hands and saying "NAK-NAK-NAK" while explaining these kinds of protocols :)
If the port is not open, the target will send a different response (SYN-RST I think) telling the initiator to go away. Different situations result in different sets of responses, such as open ports that don't allow specific addresses. These different response may be manipulated by hackers (not necessarily the bad kind) to probe open ports. The nmap documentation explains the different results pretty well: https://nmap.org/book/scan-methods-null-fin-xmas-scan.html
Internal port scans by security software are not unusual, so if you use this process and see a lot of TCP/STARTING in a journal from different ports from the same IP address, especially if no other addresses use those ports, you can probably trace that to a port scanner. Ask your security team if it is theirs and you'll get some points for detecting them, or send them into a panic that someone else on the network is port scanning you.
In any case, if you use the technique of journaling the INBOUND TCP/STARTING packets, you might see connections that did not complete - if you see connections on ports that are only accessed by one IP, especially if that same IP has lots of ports it tries to access, that is probably not a port that is open -- its just a port scanner.
If you see lots of IPs accessing lots of ports that are not likely open, that probably means you need to have a discussion with your security team about their firewall rules.
------------------------------
Vincent Greene
IT Consultant
Technology Expert labs
IBM
Vincent.Greene@ibm.com
The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Original Message:
Sent: Mon July 08, 2024 11:47 PM
From: Sylvain Manceau
Subject: Checking for configured ports on IBMi
Thank you, Vincent, for your very detailed post! I wasn't aware of the "TCP/STARTING" protocol selector.
Any thought about the "TCP SYN bit" mentioned here: https://www.ibm.com/docs/en/i/7.5?topic=filtering-ip-packet-header ?
------------------------------
Sylvain Manceau
Original Message:
Sent: Mon July 08, 2024 02:13 PM
From: Vincent Greene
Subject: Checking for configured ports on IBMi
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.com
The 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
------------------------------