LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-02-2019, 04:52 AM   #1
iammike2
Member
 
Registered: Oct 2018
Distribution: Raspbian
Posts: 55

Rep: Reputation: 1
UFW Question


Guys,


need your help again.


I have the following rules in my /etc/ufw/user.rules
Code:
### tuple ### allow any 16884 0.0.0.0/0 any 0.0.0.0/0 in
-A ufw-user-input -p tcp --dport 16884 -j ACCEPT
-A ufw-user-input -p udp --dport 16884 -j ACCEPT

### tuple ### allow tcp 16884 10.0.0.160 any 0.0.0.0/0 in
-A ufw-user-input -p tcp -d 10.0.0.160 --dport 16884 -j ACCEPT

But I still get these errors in the UFW.log


Code:
Dec  1 21:26:12 PIMike kernel: [828305.003615] [UFW BLOCK] IN=eth0 OUT= MAC=<mac address> SRC=<outside ip> DST=10.0.0.160 LEN=40 TOS=0x00 PREC=0x00 TTL=112 ID=25700 DF PROTO=TCP SPT=60933 DPT=16884 WINDOW=1025 RES=0x00 ACK URGP=0

How can I allow this ??


Thx
 
Old 12-03-2019, 06:02 PM   #2
agillator
Member
 
Registered: Aug 2016
Distribution: Mint 19.1
Posts: 274

Rep: Reputation: Disabled
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)
Code:
sudo iptables -L -v -n --line-numbers > rules
and then list the file 'rules'.
 
1 members found this post helpful.
Old 12-04-2019, 01:58 AM   #3
iammike2
Member
 
Registered: Oct 2018
Distribution: Raspbian
Posts: 55

Original Poster
Rep: Reputation: 1
Here the 'rules' file

- removed -

Last edited by iammike2; 12-04-2019 at 07:04 PM. Reason: Rules Removed
 
Old 12-04-2019, 05:10 AM   #4
agillator
Member
 
Registered: Aug 2016
Distribution: Mint 19.1
Posts: 274

Rep: Reputation: Disabled
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.
 
1 members found this post helpful.
Old 12-04-2019, 07:03 PM   #5
iammike2
Member
 
Registered: Oct 2018
Distribution: Raspbian
Posts: 55

Original Poster
Rep: Reputation: 1
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 !

Quote:
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.
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.

Last edited by iammike2; 12-04-2019 at 07:06 PM.
 
Old 12-04-2019, 10:02 PM   #6
agillator
Member
 
Registered: Aug 2016
Distribution: Mint 19.1
Posts: 274

Rep: Reputation: Disabled
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:
Code:
sudo iptables -Z ufw-before-input
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
Code:
sudo iptables -L ufw-before-input -v -n --line-numbers
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.
 
1 members found this post helpful.
Old 12-05-2019, 12:46 AM   #7
FlinchX
Member
 
Registered: Nov 2017
Distribution: Slackware Linux
Posts: 398

Rep: Reputation: Disabled
Quote:
Originally Posted by agillator View Post
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?
Isn't this true only if the firewall rules contain sensitive data like IP addresses, thus disclosing the real location of the router?
 
Old 12-05-2019, 03:31 AM   #8
agillator
Member
 
Registered: Aug 2016
Distribution: Mint 19.1
Posts: 274

Rep: Reputation: Disabled
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?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Grepping UFW.LOG question ae4ml Linux - General 11 08-02-2019 01:52 AM
question about firewall ufw marco1965 Linux - Server 4 08-12-2013 09:58 AM
ufw in Slackware mattydee Slackware 2 05-19-2009 03:35 PM
LXer: Gufw - Simple GUI for ufw (Uncomplicated Firewall) in Ubuntu LXer Syndicated Linux News 0 09-30-2008 04:20 AM
Can't access network printer through UFW cornleader Ubuntu 3 09-25-2008 10:46 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 06:20 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration