Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Securing network computers from Amazon Firestick [SOLVED]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2866
Location: Illinois, USA

PostPosted: Sun Jun 12, 2016 3:26 am    Post subject: Reply with quote

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
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 42558
Location: 56N 3W

PostPosted: Sun Jun 12, 2016 8:25 am    Post subject: Reply with quote

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
View user's profile Send private message
szatox
Veteran
Veteran


Joined: 27 Aug 2013
Posts: 1717

PostPosted: Sun Jun 12, 2016 9:34 am    Post subject: Reply with quote

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
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Sun Jun 12, 2016 9:42 am    Post subject: Reply with quote

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
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2866
Location: Illinois, USA

PostPosted: Sun Jun 12, 2016 12:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
cboldt
l33t
l33t


Joined: 24 Aug 2005
Posts: 829

PostPosted: Sun Jun 12, 2016 1:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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