| View previous topic :: View next topic |
| Author |
Message |
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
 Posted: Sun Jun 12, 2016 3:26 am Post subject: |
 |
|
I rebuilt the new kernel a second time. This time I enabled "X_TABLES LOG" and the error went away and /var/log/messages started logging messages.
I'm marking this solved but I could use help interpreting the messages. The log is filled with entries like these: | Code: | Jun 11 21:23:39 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:25:44 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:27:49 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:29:54 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:31:59 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:34:04 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:36:09 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:38:14 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:40:19 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:42:24 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:44:29 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:46:34 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:48:39 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
Jun 11 21:50:44 X3 kernel: DROP: IN=eth0 OUT= MAC=01:00:5e:00:00:01:00:24:01:70:8a:cf:08:00 SRC=192.168.0.1 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=0 PROTO=2
|
192.168.0.1 is the DLINK router. | Quote: | | 224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every multicast capable host must join that group at start-up on all it's multicast capable interfaces. |
I am dropping these. Should I allow these? Would the rule look like this? | Code: | | iptables -A INPUT -s 192.168.0.1 -j ACCEPT |
Accepting anything that comes from the router or | Code: | | iptables -A INPUT -d 224.0.0.1 -j ACCEPT |
Accepting all multicast packets? Or something else again. I'm not sure why the router sends this message. To see who is out there? |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54850
Location: 56N 3W
|
| Posted: Sun Jun 12, 2016 8:25 am Post subject: |
|
|
Tony0945,
If you are dropping things and it all works, that the test.
I don't know what multicast would be used for on a home network.
To see whos out there, ping the broadcast address. Everything is supposed to reply to that.
To get rid of the logspam you may be able to turn off multicast in your router.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3504
|
| Posted: Sun Jun 12, 2016 9:34 am Post subject: |
|
|
| Quote: | | To see whos out there, ping the broadcast address. Everything is supposed to reply to that. |
Actually I've only seen a few devices that replied to the broadcast ping. All sane systems silently drop those packets to prevent smurf attack - this is aside of routers filtering all broadcasts at the LAN boundary.
Multicast is being used e.g. by zeroconf/avahi. Handy thing. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Sun Jun 12, 2016 9:42 am Post subject: |
|
|
In the past, I've REJECTED those packets, but not from all sources, just from the known source, and just the known packet type.
| Code: | | iptables -A INPUT -p 2 -s 192.168.0.1 -d 224.0.0.1 -j REJECT |
I'd use the same sort of narrow rule if I wanted the firewall to accept those packets. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Jun 12, 2016 12:17 pm Post subject: |
|
|
| cboldt wrote: | In the past, I've REJECTED those packets, but not from all sources, just from the known source, and just the known packet type.
| Code: | | iptables -A INPUT -p 2 -s 192.168.0.1 -d 224.0.0.1 -j REJECT |
I'd use the same sort of narrow rule if I wanted the firewall to accept those packets. |
What I put in last night was: | Code: | #accept router multicast messages
iptables -A INPUT -s 192.168.0.1 -d 224.0.0.1 -j ACCEPT
# and broadcast messages
iptables -A INPUT -s 192.168.0.1 -d 255.255.255.255 -j ACCEPT |
It did seem to work OK with REJECT instead of ACCEPT. I see your form restricted the rule to igmp ptotocol. Yes, I agree, I should reject the messages with the wrong protocol to see if there are any in the log.
This has opened up a whole new world of exploration for me. I might temporarily comment out the DROP of all TV traffic (if any), just to see it logged then dropped. |
|
| Back to top |
|
|
cboldt
Veteran
Joined: 24 Aug 2005
Posts: 1046
|
| Posted: Sun Jun 12, 2016 1:54 pm Post subject: |
|
|
The difference between REJECT and DROP doesn't result in any logging, in results in different means of handling the transaction with the remote computer. On DROP, the packet is just ignored. On REJECT, the sender is informed that the packet was rejected.
If you want to log those, you need to have a logging rule, followed by the rule that dispatches the packet. This is where that "logdrop" subroutine will come in handy! You could make a similar one, "logreject." You'll see below that you can also log then ACCEPT packets. Subroutines "lanaccept" and 'wanaccept", not shown below, do that.
My firewall is technically pretty open, despite a policy of DROP. It is open because any packet that gets through the firewall rules gets to the last two rules, which LOG the packet, then ACCEPT it. My approach has been to observe those logs, and for anything that gets through, make a rule to handle that type of packet without logging it.
I think you'll be glad you undertook to understand the iptables/firewall system. It has many many tools that are useful. I recently (like in the last year or so) ran into "module recent" and use it to track and limit hits on my smtp and sshd ports.
| Code: | sshd_chain() {
# using iptables to regulate hits against $SSHD_PORT
# on third attempt in four minutes, placed into 15 minute timeout
# timeout is restarted for attempts made during timeout
iptables -N sshd-drop
iptables -A sshd-drop -j LOG --log-prefix "$LOG_SSHD_DENY "
iptables -A sshd-drop -m recent --name SSHD-deny --set -j DROP
iptables -N sshd-persist
iptables -A sshd-persist -m limit --limit 1/hour --limit-burst 1 -j LOG --log-prefix "$LOG_SSHD_PERSIST "
iptables -A sshd-persist -j DROP
iptables -N sshd-scan
iptables -A sshd-scan -m recent --name SSHD-deny --update --reap --seconds 900 -j sshd-persist
iptables -A sshd-scan -m recent --name SSHD --update --reap --seconds 240 --hitcount 3 -j sshd-drop
iptables -A sshd-scan -m recent --name SSHD --set -j LOG --log-prefix "$LOG_SSHD_ATTEMPT "
iptables -A sshd-scan -j ACCEPT
iptables -A INPUT -p tcp -d $LAN_NET --dport $SSHD_PORT -m conntrack --ctstate NEW -j sshd-scan
iptables -A INPUT -p udp -d $LAN_NET --dport $SSHD_PORT -m conntrack --ctstate NEW -j sshd-scan
} |
The firewall builder I use has about ten subroutines, which is why the above is presented as a subroutine. After creating the subroutines, the firewall builder runs them in order, like this ...
| Code: | iptables --policy INPUT DROP
iptables --policy OUTPUT ACCEPT
iptables --policy FORWARD DROP
iptables --flush
iptables --delete-chain
make_logging_chains
get_network_details
priority_packet_chain
bad_flag_chain
whitelist_chain
blocked_ip_chain
# syslog_chain
sshd_chain
smtp_chain
port_accept_chain
port_reject_chain
icmp_chain
#---------------------------------------------------------------
# DEBUGGING rule to confirm that logging is working
# This logs and ACCEPTS all NEW packet traffic. Note the "-I INPUT 2"
# which inserts this rule as the SECOND rule, after priority traffic
#---------------------------------------------------------------
# iptables -I INPUT 2 -m conntrack --ctstate NEW -j debugaccept
#---------------------------------------------------------------
# Accept and log all other originating contact (defeats DROP policy)
#---------------------------------------------------------------
iptables -A INPUT -s $LAN_NET -d $LAN_NET -m conntrack --ctstate NEW -j lanaccept
iptables -A INPUT -m conntrack --ctstate NEW -j wanaccept |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
