I would like to ping SFOS to detect if it is connected to the network. However, I am unable to ping the device. I understand that it is a firewall issue and SFOS doesn’t permit incoming pings. Therefore, I assume that it is a security issue. How can I enable pings from a specific local IP address only to go through the firewall?
1 Like
Show us how exactly it fails.
There are other ways to list devices on the LAN, if that’s all you want.
According to this arp-scan and nmap are common solutions.
When I ping it from the same network all packets are lost. When I ping from SFOS to computer all packets are received so SFOS must block them. I am not sure if there is any output that I can produce that may be interesting apart from that.
nmap showed that the host is down, but after adding -Pn it finds the device. So that may be an option, but if there is an easy way of letting pings through the firewall, it will be easier for me to work with as the script that I want to use, processes ping output so I would need to somehow accommodate it for nmap output otherwise. Or are there security risks of permitting incoming pings?
@ohnonot I just realised that VPN was messing up with the results. However, after disabling it, I am still not able to ping SFOS. I get: Destination Host Unreachable.
I tried to process nmap output as it turned out to be pretty easy. Unfortunately, I found out that -Pn trates all ips as if they had hosts present so I cannot actually use it to find if SFOS is online or not. Standard nmap is blocked by SFOS firewall similarly to pings.
I still maintain it would be helpful if you show us what ping actually says, preferably with a verbose switch.
Full command as entered, full output.
It’s not necessarily the firewall:
Ping is a ICMP Echo Request (i.e. ICMP Type 8, Code 0). Incomimg packets are blocked in /etc/connman/firewall.d/10-block-icmp-firewall.conf or more precisely, all other ICMP packets are allowed over there, the chain’s policy is DROP:
IPv4.INPUT.RULES = -p icmp -m icmp ! --icmp-type 8/0 -j ACCEPT
5 Likes
If you limit ICMP to your local network, no. Unless you have badly behaving devices 
Input and output to particular host:
iptables -A INPUT -p icmp --icmp-type 8 -s 0/0 -d "192.168.1.10" -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 0 -s "192.168.1.10" -d 0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT
1 Like
Word of warning: you do NOT want to block anything ICMP on ipv6.
That being said:
-A INPUT -p icmp --icmp-type 8/0 -m limit --limit 15/sec --limit-burst 30 -j ACCEPT
-A INPUT -p icmp --icmp-type 8/0 -j DROP
will rate limit bad actors.
2 Likes
and I think rate limiting is about the only defense you need? otherwise you ‘just’ limit snooping a bit?
I did a quick test adding an allow file:
/etc/connman/firewall.d/10-allow-icmp-firewall.conf
with
[General]
IPv4.INPUT.RULES = -p icmp --icmp-type 8 -s 0/0 -d "192.168.178.xxx" -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
IPv4.OUTPUT.RULES = -p icmp --icmp-type 0 -s "192.168.178.xxx" -d 0/0 -m state --state ESTABLISHED,RELATED -j ACCEPT
But that rule doesn’t seem to get picked up?
I tried the proposed rules to no avail. Similarly to @poetaster neither adding 10-allow-icmp-firewall.conf nor commenting relevant lines in 10-block-icmp-firewall.conf changed the outcome.
@ohnonot the output of ping with -v is the same as without it. There is nothing displayed at all until I cancel the process and then get:
— XXX.XXX.XX.XX ping statistics —
171 packets transmitted, 0 received, 100% packet loss, time 172254ms
An astute reader posted me this: https://jolla.zendesk.com/hc/en-us/articles/360017800813-Firewall-in-Sailfish-OS which I had been unaware of.
I moved the file to 99, just in case order (allow before block?) was an issue but needed to reboot. I simplified the rules, too:
IPv4.INPUT.RULES = -p icmp -m icmp --icmp-type 8/0 -j DROP
IPv4.INPUT.RULES = -s 192.168.178.xxx -p icmp -m icmp --icmp-type 8/0 -j ACCEPT
Reboot and iptables shows:
ACCEPT icmp -- x121e.router.name anywhere icmptype 8 code 0
And the phone can be pinged from that one host.
2 Likes
Thanks for sending these. It solved my problem. I also realised that you have to create the file with touch instead of nano as otherwise the rules were not picked.
One more question. Is this rule
IPv4.INPUT.RULES = -p icmp -m icmp --icmp-type 8/0 -j DROP
really needed as I understand icmp type 8/0 is already blocked by being omitted in this rule?
IPv4.INPUT.RULES = -p icmp -m icmp ! --icmp-type 8/0 -j ACCEPT
Yeah, if the original, 10-block, file is active, then 99-allow with the source address should be all that’s needed.
I see. Thank you for the clarification.
Create with touch: I don’t think so. I suggest your network changed inbetween and that triggered a reload of the rules by connman…
You are right. I tried several times to create that file using nano and it was not working, then when I used touch it worked right away so I concluded that using nano was an issue. However, something else must have occurred in the meantime. When I created the file using nano now, and reloaded and restarted conman the rules were picked up correctly.