UFW Question
 

Guys,


need your help again.


I have the following rules in my /etc/ufw/user.rules

But I still get these errors in the UFW.log



How can I allow this ??


Thx

My knowledge of ufw is limited, however it is a front end for iptables so I would drop back to iptables and trace a packet. Get a list of your firewall, assume a packet that should be accepted and then follow it through the list. It appears it is matching log and drop rules before it reaches your accept rules. Of course it could be something in the packets that doesn't match the rules or something else, but manually tracking a packet through the firewall should give you some idea. If you don't know how to get the rules list in iptables, try (in a terminal, of course)
and then list the file 'rules'.

Here the 'rules' file

- removed -

First, posting your rules listing for the whole world to see is not a good idea. Anyone who wants to know now knows exactly how your firewall is set up. It is no great state secret, but why make some bad guy's job easier?

Next, is this something that is actually making a difference or causing a problem to your operation? Does it really need to be worried about? If so you have a good bit of work ahead of you.

Here's what I can see at this point. The packet enters the table in the input chain and matches rule #2 in that chain. Therefore it goes to the ufw-before-input chain. It does not match rule #2 there because it is not accepted, but subsequently logged and (I assume) dropped. Now, it may, and probably does, match rules 3 and 4 in that chain which would create the log entry that has you concerned. Note that if it does not match them, it will continue on and end up entering the ufw-user-input chain. 210,000 matching packets did enter that chain and were accepted by rule #10 there. Note that no packets matched any further rules in that chain, including the last DROP rule. So it appears that the packet in question was logged (and I assume dropped) because it was invalid, it was not NEW, ESTABLISHED, or RELATED. Now the ACK bit was set. This should mean it was the third packet of a tcp handshake. The first should be a SYN, the response would be a SYN-ACK, and the third would be an ACK. An ACK packet without the preceeding two would be INVALID. This could happen if someone were screwing for some reason. It could also be that packet was late and the firewall dismissed the partial handshake before it arrived.

Now, why the question in the first place? Was something not working right and you went to find out why? Or were you just perusing the logs and discovered the dropped packet(s)? How many log entries of this type did you have? Lots, or just a few? You notice rules 3 and 4 of ufw-before-input had 509 matches. Note that there are actually several places that could cause a UFW BLOCK entry but I doubt the others came into play.

If this is not a problem, something that happens for whatever reason and causes no problem, then I would ignore it unless it became a problem. If you think it is a problem you have a couple of choices. First you can modify the firewall rules to better trace what is happening, for example set the log entry labels so you can tell exactly which rule in which chain matched. This would require use of iptables directly. If you are not conversant with iptables there are a number of good tutorials that will help you wade through the man page. It isn't that difficult if you put your mind to it and is a useful skill to have. This is something you need to do yourself, though, so you know what is going on. The other thing you can do is use wireshark to catch the actual packets involved so you see when and why the packets are a problem, what other packets are involved (or not), etc. This would be a job and, again, something you have to do for yourself. At the risk of being repetitive 'there are tutorials . . .'.

My suspicion is, and it is only a suspicion at this point, that it is all rather innocent and is a result of the nature of the tcp protocol and the internet, not something nefarious or problematic.

I hope I have helped.

You certainly have helped.

I don't mind that the rules file is on here, because this is not the router (which also has a Firewall) and the Router has an open port to the 10.0.0.160 PI. (I am btw on DOUBLE NAT) but will remove the Rules file anyway. Thx !

I was looking at the logs after coming back after a week long trip and saw these. There are a couple 100 entries of these in there. Also lots of 224.x.x.x but as you see I have blocked those now.

Thx for the tips will start 'learning' ipTables so really appreciated.

Glad to have helped. Since you had these (according to the list as many as 500) over the period of a week I wouldn't worry too much about it unless something happens to increase your suspicions. The 'couple hundred' is also probably over an unknown period of time. Do you know when the last time the firewall counters were reset? Are they reset hourly, daily, monthly, or just when the firewall restarts? My guess is the latter. If you want to continue to investigate you might zero the counters periodically yourself. To do that, assuming you want to zero only the counters in ufw-before-input chain. in a termnal window:
Of course you can zero the counter for the entire firewall, too. You might consider zeroing the counters in just that chain and then check in 24 hours to see what has happened. You can list just that chain with
Some other tipoffs might be the same ip or set of ips appearing with no obvious reason for the transaction and that sort of thing. If you are interested and have the curiosity you really do have a lot of forensic analysis you can do as you learn iptables (if you choose to).

At any rate, good luck, have fun. One thing to remember in any of your efforts: kernel modules actually do the firewalling. All the other things you hear about (iptables, ufw, etc.) are only front ends to the kernel modules to theoretically make controlling them easier, some easier than others.

Isn't this true only if the firewall rules contain sensitive data like IP addresses, thus disclosing the real location of the router?

FlinchX: Someone who knows what they are doing can accurately assume a lot about a firewall. However, they will not know what extra and specific things a user has put in. That is what they have to work to find out, things like what ports are open, what are closed. Ports there are ways of finding out, it just takes time and some skill. But if someone is using port knocking - well, that is not as secure as we may wish but it would certainly be an unexpected stumbling block. There are other things a person could do to make a break in more difficult. An accurate rules list compromises all of that with or without ips. Not having the ips might be a delay, but that is all. If someone is actually targeting you they probably already have your ip; that's the first thing they would obtain and they wouldn't need a rules list to do it. For example knowing where you live or where your computer is narrows down the possible ips greatly. No place in the world has an infinite number of isps and no isp has an infinite number of addresses available to them.

Let me suggest an exercise if you have not already tried it. If you have a computer or a network facing the internet with a firewall you can control or at least get access to, extract a list of dropped ips over a 24 hour period from it. Now start doing whois searches on the ips. Look at how many are from a single country, China for example. Those are not mistakes on their part. Those are attempts to get information. They don't care what your ip is, they are trying ALL ips. They are trying to find out if they get useful information from that ip which they may or may not follow up on later. So, yes, they find lists of ips useful but not necessary because they are already developing their own. However, information on the firewall they would face and other security factors would be of immense value. You have nothing of value? To the Chinese, perhaps not, but to some script kiddy out there . . . . If s/he can break into your computer, encrypt everything, then they can demand ransom. You don't have thousands of dollars? That's ok, a hundred dollars or even ten dollars might do since it isn't costing them anything and they are getting everything you have. Why make their job easier?