# Securing network computers from Amazon Firestick [SOLVED]

## Tony0945

I have set up iptables to disable login from the Amazon firestick, the two Samsung TV's and the Android Smartphone.  I downloaded VLC onto the Firestick and I note that it can look all over my computer, not just the files served by DLNA (minidlna-1.1.5-r1).

How can I set iptables so that the Firestick's IP address (and the TVs) can only access through the DLNA ports?

I'm kind of paranoid after reading that samsung was listening to conversations through their voice-operated TV's and I really don't trust Amazon, either.Last edited by Tony0945 on Sun Jun 12, 2016 3:28 am; edited 1 time in total

----------

## Hu

What protocol(s) is the Firestick VLC using to browse so extensively?  It sounds like your first problem is that you are running one or more services that allow anonymous access to everything.  Blocking the Firestick is a workaround to prevent it from using those services, but you should instead configure those services not to be so permissive.

Assuming that you have a standard default-drop policy on your firewall (and if you are kind of paranoid, you will  :Smile: ), then the problem you described should not be happening.  The quick fix is to add an ACCEPT rule for the DLNA ports, followed by a DROP rule for any other traffic from that host.  However, I think you may need a more complete audit of your firewall rules.  Please post the output of iptables-save.

----------

## Tony0945

```
X3 tony # iptables-save

# Generated by iptables-save v1.4.21 on Mon Jun  6 21:00:19 2016

*filter

:INPUT ACCEPT [93435648:596403418247]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -s 192.168.0.190/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.191/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.192/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.193/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.194/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.195/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.196/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.197/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.198/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.199/32 -p tcp -m tcp --dport 22 -j DROP

-A INPUT -s 192.168.0.180/32 -j DROP

-A OUTPUT -j ACCEPT

COMMIT

# Completed on Mon Jun  6 21:00:19 2016

```

180 is the phone, 190-199 are reserved for TV's, and other devices like the firestick

The real computers are 100 through 109

Per the wiki: *Quote:*   

> Minidlna uses port 1900 udp & 8200 tcp 

 

----------

## Syl20

If you want a secure firewall, you should avoid accepting all but what you explicitely denied (black list), to switch to a "forbid all but what you explicitely allowed" mode (white list). 

That needs some time to set up, but you won't have to wonder what to block then.  :Wink: 

----------

## NeddySeagoon

Syl20,

Shorewall makes it quite easy to "forbid all but what you explicitly allowed".

Its surprising/scary how many things try to phone home without asking.

----------

## Hu

As I feared, you need a complete audit.  Fortunately, it is very quick.  Those rules are completely unsuitable for your stated intentions.  As I hinted, and later posters mentioned explicitly, you should be using a default-drop policy with specific rules to permit known good traffic.  Currently, you are using a default-allow policy with specific rules to prohibit traffic you have identified as unacceptable.  This allows all unacceptable traffic that you have not yet identified to be accepted.  Unfortunately, we do not yet have enough information to help you write a good set of rules for a default-drop policy.  The core of such a policy is to allow traffic over lo, allow ESTABLISHED traffic, and have a policy of DROP.  The policy is then customized by adding rules to permit allowed connections.  Until you are proficient with firewall rules, I suggest that you perform any such changes from the machine's console.  Linux has no inherent protection against a remote administrator adding rules that promptly ban his traffic.

----------

## NeddySeagoon

Tony0945,

You can just start with  *Hu wrote:*   

> The core of such a policy is to allow traffic over lo, allow ESTABLISHED traffic, and have a policy of DROP. 

 

And log everything that is dropped.  Since nothing works now, its easy to spot things trying to get out.

----------

## Tony0945

Thanks all!  Internet was out for most of the day in Illinois yesterday. Supposedly, someone cut a fiber-optic cable. It was strange having no TV, no internet, no e-mail. got a lot of yard work done.

I will follow these suggestions and present another setup for comment. These rules are tricky, almost as hard to decipher as grub2 configs.

----------

## NeddySeagoon

Tony0945,

Try Shorewall.  Its a little simpler that raw iptables.

There is Shorewall6 for IPv6 too.

If you have more than two zones, you need to do some planning before you think about firewall rules.

Work out what is allowed to initiate connections to where and with which services.

----------

## depontius

One other thing you might consider is subsetting your network.  My network has had separate DMZ and HomeLAN networks almost from the get-go.  I bought a Blue Ray player with streaming, but have not set up its wifi access yet because I don't have wifi on my DMZ.  There's no way I'm allowing it to snoop around on my HomeLAN network.

I'm also considering adding a third subnet, perhaps called Spys, and put untrusted appliances there.  Then egress filtering can be added as desired.

It's also worth noting that I unthinkingly put my HD-HomeRun Prime on HomeLAN, mostly because it predated the spy-device fears.  However at this point moving it to either DMZ or Spy networks would mean pushing a lot of traffic through that route.  On the other hand, it might be nice for the Blue Ray player to see the DNLA of the HDHR.

Breaking apart subnets can be easier to firewall than individual hosts.

----------

## NeddySeagoon

A long time ago, I used to run Smoothwall. Its a firewall network appliance that takes over any PC you care to run the installer on.

About 2011, I consolidated my four home servers into KVMs on a purpose built system.  Power savings paid for that more capable box over about 18 months.

Unfortunately. I couldn't get Smoothwall to run in a KVM.  I looked at iptables and lost the will to live.   Smoothwall had a easy to use GUI, so I had gone soft.

Next up was Shorewall.  There is no GUI but the setup is logical.  Its easy to set up logging to see why things don't work.

Nasties knocking on the front door are DROPped.  They don't even get a reply.

Unknowns trying to phone home are REJECTed. They get an error message and the packets are logged.

I run four zones.  Internet, (RED) semi protected (DMZ) protected wired (GREEN) and protected wireless (BLUE).  The zone names are from Smoothwall.  The only difference between blue and green is that wireless cannot connect to wired.  Well, wireless isn't really secure.

My bluray player is wired but its not allowed to phone home until it says it can't play a new bluray disc because the firmware is too old.

Firmware updates are a very occasional treat for it. 

I'm trying to add in a couple of VPNs too. The hard bit works, that's the encrypted links.  I've not got the hang of the routing yet.

----------

## Tony0945

OK, I altered the suggested script in the Gentoo wiki 

```
X3 ~ # iptables-save

# Generated by iptables-save v1.4.21 on Fri Jun 10 00:47:06 2016

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [6:708]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -i 192.168.0.192 -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -i 192.168.0.192 -p udp -m udp --dport 1900 -j ACCEPT

-A INPUT -i 192.168.0.193 -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -i 192.168.0.193 -p udp -m udp --dport 1900 -j ACCEPT

-A INPUT -i 192.168.0.192 -j DROP

-A INPUT -i 192.168.0.193 -j DROP

-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 113 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset

COMMIT

# Completed on Fri Jun 10 00:47:06 2016

```

I'm not sure (i.e. haven't a clue) what the lines with -m conntrack and -m icmp do.

Also, what the heck is that line with -p tcp doing?

I also did do this over the LAN (on the highwire without a net) and it's still connected but is that just because of that conntrack line?

I did see a more detailed RedHat/Centos script, but wasn't sure if it was applicable to Gentoo.

My goal is that on one set of boxes, the sky is the limit. On the second set of boxes, they are restricted to the two DLNA ports. It's nearly 1:00AM and I haven't checked this yet other than I am still connected to the X3 box from 192.168.0.100    Breaking off because I have a quite peeved spouse to deal with. ("Are you still playing with that damn computer!")

P.S. Yesterday I heard TheGoons "#10 Downing Street is missing" on SiriusXM Comedy channel.

----------

## cboldt

The "-m conntrack RELATED,ESTABLISHED" parameter (and command) causes iptables to accept all packets from computer relationships, that were initiated by the computer the firewall is running on.  This way, the firewall doesn't have to open all the ports for incoming packets, for connections started by that computer.

The "--tcp-flags FIN,SYN,RST,ACK ACK" line is looking for a couple types of malformed network packet, but only for the port (113) that is typically used for the "auth" service.  The "auth" service is a primitive identify mechanism used between computers, it isn't related to system login.  I run a program called `fakeidentd` to answer calls to that port, and it gives up fake identity information to the requester.

The "-p icmp" lines related to network packets of type ICMP (as opposed to type TCP or type UDP).  Type ICMP pakets are called "ping" packets, but that is a little misleading because the "ping" is one of several types of ICMP packet.  At any rate, the firewall you have will accept ping (the outside can ping that computer and get a response) and IIRC, types 11 and 12 have to do with traceroute.

Edit to add that the RH/CentOS script will apply to Gentoo.  Firewall / iptables configuration is generic across distributions, with variations and commands being applicable on an application by application (or port by port) basis.

----------

## Tony0945

Thanks for the explanation, cboldt!   

I have redone the firewall, but after closing the putty connection I can't open another from either side.

```
X3 ~ # iptables-save

# Generated by iptables-save v1.4.21 on Fri Jun 10 10:26:37 2016

*filter

:INPUT DROP [0:0]

:FORWARD DROP [0:0]

:OUTPUT ACCEPT [0:0]

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -p tcp -m tcp --dport 113 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset

-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 8200 -j ACCEPT

-A INPUT -p udp -m udp --dport 1900 -j ACCEPT

-A INPUT -i 192.168.0.192 -j DROP

-A INPUT -i 192.168.0.193 -j DROP

-A INPUT -i 192.168.0.100 -j ACCEPT

-A INPUT -i 192.168.0.102 -j ACCEPT

-A INPUT -i 192.168.0.104 -j ACCEPT

-A INPUT -i 192.168.0.106 -j ACCEPT

-A INPUT -i 192.168.0.108 -j ACCEPT

-A INPUT -i 192.168.0.103 -j ACCEPT

-A INPUT -i 192.168.0.109 -j ACCEPT

COMMIT

# Completed on Fri Jun 10 10:26:37 2016
```

The annotated script that generated these rules is here: http://dpaste.com/09VZFAF

----------

## Tony0945

iptables -L shows the following which is confusing as it seems to ignore source:

```
X3 ~ # iptables -L

Chain INPUT (policy DROP)

target     prot opt source               destination         

ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

ACCEPT     all  --  anywhere             anywhere            

REJECT     tcp  --  anywhere             anywhere             tcp dpt:auth flags:FIN,SYN,RST,ACK/SYN reject-with tcp-reset

ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable

ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded

ACCEPT     icmp --  anywhere             anywhere             icmp parameter-problem

ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:8200

ACCEPT     udp  --  anywhere             anywhere             udp dpt:1900

DROP       all  --  anywhere             anywhere            

DROP       all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

ACCEPT     all  --  anywhere             anywhere            

LOGGING    all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)

target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

Chain LOGGING (1 references)

target     prot opt source               destination         

DROP       all  --  anywhere             anywhere  
```

----------

## cboldt

It's ignoring the source IP because iptables needs that to be presented as "-s $IP_ADDRESS", or in long form, "--source $IP_ADDRESS".  Don't use $IP_ADDRESS literally, I'm using that to indicate some generic IP Addy.

```
-A INPUT -s 192.168.0.192 -j DROP 
```

The "-i" you are using is the interface, which is a hardware name like "etho" or "wlan0" or one of those newfangled names.  You can see your interface names by running `route`, which will show Iface in the last column.  You'll notice one of your firewall rules is allowing everything on interface "lo," which is TCP/IP traffic that runs purely on one machine.

The reason putty can't get in, is that putty is (probably) trying to access your firewalled computer via port 22.  Your firewall rules don't admit packets that are trying to get into port 22.  If you have configured your sshd to use a different port (and putty has been informed of the non-standard port to use), the same situation holds true at the firewall, that port is blocked too.  The only ports you have open to NEW incoming packets are 1900 and 8200.

----------

## Tony0945

 *cboldt wrote:*   

> It's ignoring the source IP because iptables needs that to be presented as "-s $IP_ADDRESS", or in long form, "--source $IP_ADDRESS".  Don't use $IP_ADDRESS literally, I'm using that to indicate some generic IP Addy.
> 
> ```
> -A INPUT -s 192.168.0.192 -j DROP 
> ```
> ...

 

Ooops! Changing  -i to -s fixed putty and ssh. The interface name is the traditional eth0, BTW.

I could use some guidance on logging dropped packets. This code: 

```
iptables -N LOGGING

iptables -A INPUT -j LOGGING

iptables -A LOGGING -m limit --limit 2/min -j LOG

iptables -A LOGGING -j DROP

```

Results in: 

```
X3 ~ # sh firewallscript

iptables: No chain/target/match by that name.

```

----------

## cboldt

First a new rule that has a logging line (which does NOT dispatch the packet), followed by a line that dispatches the packet.

```
iptables -N logdrop

iptables -A logdrop -j LOG --log-prefix DROP:

iptables -A logdrop -j DROP
```

Then you can use "-j logdrop" to log then drop a packet.

```
# This is the last rule in the chain, it logs and drops everything that got through the gauntlet

iptables -A INPUT -m conntrack --ctstate NEW -j logdrop
```

----------

## Tony0945

```
X3 ~ # nano firewallscript

X3 ~ # sh firewallscript

iptables: No chain/target/match by that name.

X3 ~ # 

```

Script is at http://dpaste.com/1XEGE6Z

Maybe I'm missing something in the kernel?   config is here: http://dpaste.com/0H4V69T[/quote]

----------

## cboldt

I don't see any obvious typo or other error.  Stuff in a couple "echo" reports to narrow down where the script is crapping out.

For starters, put in an "echo just before creating logrop" and an "echo after logrop, before last iptables rule"

Edit to add, I don't think there is a missing feature in the iptables/kernel config.  You've had the --conntrack facility in use before, and I didn;t notice any other iptables extension.  Allowed "-j" targets are ACCEPT, REJECT, DROP, and any rules you define (e.g., "logdrop"), and I didn't see any errors in those, no "-j ACCETP" (notice the typo!) for example.

----------

## Tony0945

This is the generating the error:

iptables -A logdrop -j LOG --log-prefix DROP:

If I comment it out, the error goes away.

Maybe the problem is default useflags?

```
X3 ~ # emerge -pv iptables

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] net-firewall/iptables-1.4.21-r1::gentoo  USE="ipv6 -conntrack -netlink -static-libs" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

```

EDIT:  BTW, Samsung Smart TV plays DLNA fine but it takes about ten minutes for the X3:DLNA option to appear on the TV. I surmise that it is doing a lot of other things, retrying, and finally giving up and using plain DLNA. The logs would help a lot.

----------

## cboldt

That's interesting.  I have approximately that line in my iptables builder, but instead of having the prefix set directly, it is set using a variable.  I set numerous logging variables, then create numerous rules that log then handle packets.  The below lines are selected from that bunch, cut and paste ...

```
LOG_DROP=${LOG_DROP:=DROP:}

iptables -N logdrop

iptables -A logdrop -j LOG --log-prefix "$LOG_DROP "

iptables -A logdrop -j DROP
```

Oh, I see the error now, missing quotation makes in the direct setting of the phrase "DROP:"

----------

## Tony0945

```
X3 ~ # sh firewallscript

iptables: No chain/target/match by that name.

X3 ~ #

```

firewallscript: [url] http://dpaste.com/3BRT8EG[/url]   Ooops, no link. wgetpaste seems to have stopped working

relevant excerpt:

```
#including the wireless computers

iptables -A INPUT -s 192.168.0.103 -j ACCEPT

iptables -A INPUT -s 192.168.0.109 -j ACCEPT

LOG_DROP=${LOG_DROP:=DROP:}

iptables -N logdrop

iptables -A logdrop -j LOG --log-prefix "$LOG_DROP "

iptables -A logdrop -j DROP

# This is the last rule in the chain, it logs and drops everything that got thr$

iptables -A INPUT -m conntrack --ctstate NEW -j logdrop

```

----------

## cboldt

The URL works if [url] is stripped from the end.

I think your kernel is missing logging support in nf_tables, CONFIG_NFT_LOG or in Xtables targets, CONFIG_NETFILTER_XT_TARGET_LOG

From the kernel source `make menuconfig`, follow these links ...

Networking support

Networking options

Network packet filtering framework (Netfilter)

Core Netfilter Configuration

* Netfilter nf_tables log module

* LOG target support

Edit to add, after looking at your kernel config, I think you need to set "Netfilter nf_tables support" (CONFIG_NF_TABLES) in order to set CONFIG_NFT_LOG.  Otherwise the "Netfilter nf_tables log module" option won't be visible.  If you compile those items as modules, kernel recompile should be fairly quick, only the new and changed modules are built.

----------

## Tony0945

The following were unchecked:

```
CONFIG_NETFILTER_NETLINK_LOG:                                           │  

  │                                                                         │  

  │ If this option is enabled, the kernel will include support              │  

  │ for logging packets via NFNETLINK.                                      │  

  │                                                                         │  

  │ This obsoletes the existing ipt_ULOG and ebg_ulog mechanisms,           │  

  │ and is also scheduled to replace the old syslog-based ipt_LOG           │  

  │ and ip6t_LOG modules.

CONFIG_NF_TABLES:                                                                                                            │  

  │                                                                                                                              │  

  │ nftables is the new packet classification framework that intends to                                                          │  

  │ replace the existing {ip,ip6,arp,eb}_tables infrastructure. It                                                               │  

  │ provides a pseudo-state machine with an extensible instruction-set                                                           │  

  │ (also known as expressions) that the userspace 'nft' utility                                                                 │  

  │ (http://www.netfilter.org/projects/nftables) uses to build the                                                               │  

  │ rule-set. It also comes with the generic set infrastructure that                                                             │  

  │ allows you to construct mappings between matchings and actions                                                               │  

  │ for performance lookups.                                                                                                     │  

  │                                                                                                                              │  

  │ To compile it as a module, choose M here.  
```

A new kernel was available after syncing, so I made these changes there. Also enabled IPV6 logging. There were a ton of new logging and tracking options in this new kernel 4.6.4, I marked them as modules, the above missing ones as builtin.

----------

## Tony0945

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:

```
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?

```
iptables -A INPUT -s 192.168.0.1  -j ACCEPT
```

Accepting anything that comes from the router or

```
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?

----------

## NeddySeagoon

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.

----------

## szatox

 *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.

----------

## cboldt

In the past, I've REJECTED those packets, but not from all sources, just from the known source, and just the known packet type.

```
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.

----------

## Tony0945

 *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.
> 
> ```
> iptables -A INPUT  -p 2   -s 192.168.0.1  -d 224.0.0.1 -j REJECT
> ```
> ...

 

What I put in last night was:

```
#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.

----------

## cboldt

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.

```
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 ...

```
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
```

----------

