error in nf tables when using ct state : Protocol wrong type for socket - linux-kernel

I'm struggling to configure my nf tables rules on my distro. I'm using nft 1.0.4 and Linux 4.9.
When I am using the ct state instruction, nft throw the following error:
nftables.cfg:25:17-43: Error: Could not process rule: Protocol wrong type for socket
ct state established accept
^^^^^^^^^^^^^^^^^^^^^^^^^^^
My Kernel config contains the following parameters
# enable nftables support
CONFIG_NF_TABLES=y
CONFIG_NF_TABLES_INET=y # inet allows IPv4 and IPv6 config in single rule
CONFIG_NF_TABLES_NETDEV=y
CONFIG_NF_CONNTRACK=y # for NAT support
CONFIG_NF_NAT=y # for NAT support
CONFIG_NF_TABLES_SET=y # to use brackets (sets)
CONFIG_NFT_EXTHDR=y
CONFIG_NFT_META=y
CONFIG_NFT_CT=y
CONFIG_NFT_RBTREE=y
CONFIG_NFT_HASH=y
CONFIG_NFT_COUNTER=y
CONFIG_NFT_LOG=y
CONFIG_NFT_LIMIT=y
CONFIG_NFT_MASQ=y
CONFIG_NFT_REDIR=y
CONFIG_NFT_NAT=y
CONFIG_NFT_QUEUE=y
CONFIG_NFT_REJECT=y
CONFIG_NFT_REJECT_INET=y
CONFIG_NFT_COMPAT=y
CONFIG_NFT_CHAIN_ROUTE_IPV4=y
CONFIG_NFT_REJECT_IPV4=y
CONFIG_NFT_CHAIN_NAT_IPV4=y
CONFIG_NFT_MASQ_IPV4=y
# CONFIG_NFT_REDIR_IPV4 is not set
CONFIG_NFT_CHAIN_ROUTE_IPV6=y
CONFIG_NFT_REJECT_IPV6=y
CONFIG_NFT_CHAIN_NAT_IPV6=y
CONFIG_NFT_MASQ_IPV6=y
# CONFIG_NFT_REDIR_IPV6 is not set
CONFIG_NFT_BRIDGE_META=y
CONFIG_NFT_BRIDGE_REJECT=y
my ruleset is something like
#!/sbin/nft -f
flush ruleset
table inet myfilter {
chain myinput {
type filter hook input priority 0; policy drop;
ct state established,related accept
tcp dport ssh accept
tcp dport 53 accept
udp dport 53 accept
ip protocol icmp accept
iif "lo" accept
tcp dport 2181 accept
tcp dport 9092 accept
}
chain myoutput {
type filter hook output priority 0; policy drop;
ct state established accept
tcp dport ssh accept
tcp dport 53 accept
udp dport 53 accept
udp dport snmp accept
tcp dport http accept
tcp dport https accept
ip protocol icmp accept
}
chain forward {
type filter hook forward priority 0; policy drop;
}
}
Do you have any idea how to fix this?

Actually the error come from the version of the kernel I am using: 4.9.
nftables needs at least v4.10 to fully support ct states as stated in debian documentation here https://packages.debian.org/stretch/nftables
A Linux kernel >= 3.13 is required. However, >= 4.10 is recommended.

Related

Linux firewalld discards local UDP packet although ACCEPT rule is hit

On a RHEL8 system, I'm receiving UDP packet for destination port 2152 (gtp-user) from an external interface and they are not reaching the application listening on the UDP socket opened for that port. I see packets reaching the application fine if I stop firewalld. As soon as firewalld is started, packets get discarded.
I added a rule to explicitly accept these packets and I see my ACCEPT rule is now being hit with counter matching exactly the number of packets generated (1987 packets in dump below)
iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6755 4273K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
1 28 ACCEPT icmp -- any any anywhere anywhere
150 10358 ACCEPT all -- lo any anywhere anywhere
0 0 ACCEPT tcp -- any any anywhere anywhere state NEW tcp dpt:ssh
1987 1492K ACCEPT udp -- any any anywhere anywhere udp dpt:gtp-user
11 3849 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- any any anywhere anywhere reject-with icmp-host-prohibited
Still packets are not reaching the application and when enabling log-denied=all I see in /var/log/messages a FINAL_REJECT entry for each packet sent while firewalld is running
kernel: FINAL_REJECT: IN=ens161 OUT= MAC=00:50:56:8a:de:55:00:50:56:8a:93:57:08:00 SRC=168.168.31.201 DST=168.168.31.31 LEN=751 TOS=0x18 PREC=0x60 TTL=100 ID=3109 DF PROTO=UDP SPT=2152 DPT=2152
Any ideas of why firewalld would reject these UDP packets after hitting the ACCEPT rule ?

Can not connect with a simple http server(tcp connection) on oracle compute instance(oci), ssh connection works well

I am using oracle cloud to create a http server for learning , so I am new on this. Thank you for your any help!
Instance information
Image: Canonical-Ubuntu-20.04-2022.02.15-0
Shape: VM.Standard.E2.1.Micro
Have added ingress rule on subnet(7500 port):
Picture of subnet
Source IP Protocol Source Port Range Destination Port Range Allows
0.0.0.0/0 TCP All 7500 TCP traffic for ports: 7500
Using python to create a http server:
python3 -m http.server 7500 &
It was showing:
ubuntu#tcp-server:~$ Serving HTTP on 0.0.0.0 port 7500 (http://0.0.0.0:7500/) ...
Calling lsof -i returns
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3 1806 root 3u IPv4 33281 0t0 TCP *:7500 (LISTEN)
Allowed 7500 port on ufw:
ufw Status: active
To Action From
7500 ALLOW Anywhere
7500 (v6) ALLOW Anywhere (v6)
But I can not visit public_Ip_address:7500.
Using telnet:
sudo telnet 152.69.123.118 7500
Returns:
Trying 152.69.123.118...
and does not connect
Thank you in advance!
The reason is from iptables setting:
sudo nano /etc/iptables/rules.v4
add this sentence:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 7500 -j ACCEPT
then:
sudo su
iptables-restore < /etc/iptables/rules.v4
Done!
ubuntu image from oci has been modified by oracle, the default setting has limitted ports accepted.
Therefor we have to open the port manually.
There are some important attributes you need to be aware of when using a fresh ubuntu image on oci. For the sake of this discussion firewall and iptables are synonymous
By default
there are 4 chains standard INPUT, FORWARD, OUTPUT and InstanceServices
OUTPUT will have 1 rule
InstanceServices all -- * * 0.0.0.0/0 169.254.0.0/16
InstanceServices destination 169.254.XXX.YYY point to oci services like bootvolume ect ...
FORWARD rejects all
Your default INPUT chain will look like
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
6 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
this allows ssh and udp port 123 for NTP only
create a rule for port 7500 and place it with the existing tcp rule for ssh
sudo iptables -I INPUT 6 -p tcp -m tcp --dport 7500 -j ACCEPT
now INPUT chain is
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:123
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:7500
7 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
as long as we have the correct VCN route table entries, Security list entries or network security group entries for tcp 7500 you can get thru the instance firewall to destination port 7500
Notes
Its really import not to delete the InstanceServices rule in the OUTPUT chain AND not to delete the InstanceServices chain
This can happen if you are new to iptables and you do something like
iptables -F
iptables -X
Its worth it to learn iptables however firewalld is easier.
Oci does not recommend ufw
Your iptable rules will not survive a reboot unless you persist them
these issues are well documented here under subheading Essential Firewall Rules

Fluentbit creates TCP connections

Fluentbit creates TCP connections to itself?
What are these used for?
fluent.conf file:
[SERVICE]
Flush 5
Daemon Off
Log_Level debug
[INPUT]
Name tail
Tag format.logging
path C:\Logs\*main.log
DB C:\Logs\main_logs.db
[OUTPUT]
Name stdout
Match *
This seems to boil down to an implementation detail where it uses unix sockets on Linux for its event loop, but on Windows it has opted to using localhost-connections.
Comment from https://github.com/fluent/fluent-bit/blob/37aa680d32384c1179f02ee08a5bef4cd278513e/lib/monkey/mk_core/deps/libevent/include/event2/util.h#L380
/** Create two new sockets that are connected to each other.
On Unix, this simply calls socketpair(). On Windows, it uses the
loopback network interface on 127.0.0.1, and only
AF_INET,SOCK_STREAM are supported.
(This may fail on some Windows hosts where firewall software has cleverly
decided to keep 127.0.0.1 from talking to itself.)
Parameters and return values are as for socketpair()
*/
The actual implementation is here: https://github.com/fluent/fluent-bit/blob/37aa680d32384c1179f02ee08a5bef4cd278513e/lib/monkey/mk_core/deps/libevent/evutil.c#L207
It matches the pattern when looking at the netstat output:
netstat -anop tcp | findstr <fluentbit pid>
TCP 127.0.0.1:54645 127.0.0.1:54646 ESTABLISHED 12012 \
TCP 127.0.0.1:54646 127.0.0.1:54645 ESTABLISHED 12012 ´` Pair
TCP 127.0.0.1:54647 127.0.0.1:54648 ESTABLISHED 12012 \
TCP 127.0.0.1:54648 127.0.0.1:54647 ESTABLISHED 12012 ´` Pair

Simulate Network Latency mac Sierra

I am trying to simulate network latency for all traffic to a certain ip/url. I tried using a proxy through Charles but the traffic is going through HTTP or SOCKS. I found some information online but it does not seem to work for me. Can anyone see what is wrong with my commands?
#enable pf
pfctl -E
#add a temporary extra ruleset (called "anchor") named "deeelay
(cat /etc/pf.conf && echo "dummynet-anchor \"deeelay\"" && echo "anchor
\"deeelay\"") | sudo pfctl -f -
#add a rule to the deeelay set to send any traffic to endpoint through new rule
echo "dummynet out proto tcp from any to myurl.com pipe 1" |
sudo pfctl -a deeelay -f -
#Add a rule to dummynet pipe 1 to delay every packet by 500ms
sudo dnctl pipe 1 config delay 500
I see this warning when I run the commands:
No ALTQ support in kernel
ALTQ related functions disabled
Is that the issue?
The problem was the proto parameter. The application is not using tcp, it is using another protocol. You can either supply all the protocols you want as a list like so:
proto { tcp udp icmp ipv6 tlsp smp }
Or you can just remove the proto parameter altogether and it will do all protocols.

amazon ec2, cannot ping internal host

In amazon ec2, I have 2 instances in a placement group. First node is 172.31.12.76/20, second, 172.31.12.77/20 I can ssh both nodes from my pc. They share the same security group that has got these 2 rules:
Inbound rules:
Type Protocol Port Range Source
SSH TCP 22 0.0.0.0/0
All IMCP All N/A 0.0.0.0/0
(no outbound rules)
Both nodes see to each other in L2:
root#ip-172-31-12-76:~# arp
[...]
ip-172-31-12-77.eu-west ether 0a:ad:5e:e4:12:de C eth0
[...]
root#ip-172-31-12-77:~# arp
[...]
ip-172-31-12-76.eu-west ether 0a:34:a1:17:57:28 C eth0
[...]
iptables are empty on both nodes.
But ping does not work between each other
I have already checked a previous post:
EC2 instances not responding to internal ping
but it does not address the issue. It looks like there are no other similar posts.
Any idea? Thank you very much!
I got the answer; I need to also allow outbound icmp on each host in order to be able to ping both external and internal IPs.

Resources