This thread is a continuation of the Kindle basics of ssh/scp thread at:
http://www.mobileread.com/forums/sho...d.php?t=204942
This thread is also based on materials in the following threads:
Reference:
The *nix command crib-sheet linked to from this thread: http://www.mobileread.com/forums/sho...d.php?t=204534
NOTE: The version of those commands provided by Busybox on the Kindle usually only have a limited sub-set of the command features described in the crib-sheet.
Conditions:
In the prior thread on the basics of ssh/scp on the Kindle, you learned how to remove the banner and do remote exectuted programs via ssh.
In the prior thread on the Linux firewall tables, you found there are no restrictions on the USB0 interface. Your also read about the restrictions present on packets originating on the wlan0 (and 3G) interfaces.
You made note of the sequence required to start/stop USBnetwork, from the spoiler in the USBnetworking thread, which is repeated in the spoiler here:
You may or may not have configured your network automation to automatically bring up the link and set the point-to-point address that you are using on your host PC.
There are a number of network automation things used by the various Linux distributions, refer to your distribution information on how to set up yours (not here, your distro's help forum).
Windows and MacOSx also have provisions for automating the host connection setup.
Crank-up your USB networked Kindle (a Kpw-5.3.3 used here) and be sure things are still working the way we left them (connection details by nickname, no banner from dropbear):
It LIVES!
You can leave that connection up for your own exploring during the rest of this post.
The first thing we discover is that iptables can not be run remotely because of a "not found" condition.
Find out why (check the remote shell environment):
The PATH variable has been a bit "over trimmed" for our liking.
So until that gets a more permanent fix, we will just re-set it in each remote command:
A "funky, shouldn't work" but it does re-setting of the environment PATH.
Get a current listing of how the three primary chains are setup in the kernel:
The "how to read that" thread is here: http://www.mobileread.com/forums/sho...d.php?t=204676
Now lets compare that with the stored system configuration file supplied by lab126 (on Kpw-5.3.3):
Where does a configuration file like that come from?
It is originally created by a utility that snapshots the kernel's firewall rules.
This output would include the secondary and user-defined chains if they where in use.
There is a corresponding iptables-restore utility.
It re-defines the kernel's firewall rules in a single syscall from a stored snapshot file.
You can see that one possible work-flow in defining a custom firewall is to build it up one rule, one chain at a time; test until tired; save it in a file; edit in comments of why you did what you did (which looks like how lab126 did it).
(Does anyone see yet why I patched out that un-welcome banner message? ;) )
The three kernel network control bits of most interest here are:
Translation of all the above:
The Kindle kernel firewall **as shipped** is intended to keep out everything except Amazon by wireless (Wifi & 3G) and the owner if directly wired to the Kindle by the USB cable.
None of the other common IPv4 things are supported, nor is IPv6.
(Don't close this page now, I am not going to add IPv6 support to the Kindles (today) ;) )
More to follow. . . .
http://www.mobileread.com/forums/sho...d.php?t=204942
This thread is also based on materials in the following threads:
- Basics of iptables: http://www.mobileread.com/forums/sho...d.php?t=204676
- USBnetwork package installation under the KUAL launcher: http://www.mobileread.com/forums/sho...d.php?t=204450
- Kpw-5.3.1 -> Kpw-5.3.3 update and installation of the KUAL launcher: http://www.mobileread.com/forums/sho...&postcount=192
Reference:
The *nix command crib-sheet linked to from this thread: http://www.mobileread.com/forums/sho...d.php?t=204534
NOTE: The version of those commands provided by Busybox on the Kindle usually only have a limited sub-set of the command features described in the crib-sheet.
Conditions:
In the prior thread on the basics of ssh/scp on the Kindle, you learned how to remove the banner and do remote exectuted programs via ssh.
In the prior thread on the Linux firewall tables, you found there are no restrictions on the USB0 interface. Your also read about the restrictions present on packets originating on the wlan0 (and 3G) interfaces.
You made note of the sequence required to start/stop USBnetwork, from the spoiler in the USBnetworking thread, which is repeated in the spoiler here:
Spoiler:
You may or may not have configured your network automation to automatically bring up the link and set the point-to-point address that you are using on your host PC.
There are a number of network automation things used by the various Linux distributions, refer to your distribution information on how to set up yours (not here, your distro's help forum).
Windows and MacOSx also have provisions for automating the host connection setup.
Crank-up your USB networked Kindle (a Kpw-5.3.3 used here) and be sure things are still working the way we left them (connection details by nickname, no banner from dropbear):
Code:
core2quad ~ $ ssh kpw
#################################################
# N O T I C E * N O T I C E * N O T I C E #
#################################################
Rootfs is mounted read-only. Invoke mntroot rw to
switch back to a writable rootfs.
#################################################
[root@kindle root]#You can leave that connection up for your own exploring during the rest of this post.
The first thing we discover is that iptables can not be run remotely because of a "not found" condition.
Find out why (check the remote shell environment):
Code:
core2quad ~ $ ssh kpw "set"
HOME='/tmp/root'
IFS='
'
KINDLE_TZ='GMT-06:00'
LANG='en_US.utf8'
LC_ALL='en_US.utf8'
LOGNAME='root'
PATH='/usr/bin:/bin'
PPID='17801'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/var/tmp/root'
SHELL='/bin/sh'
SSH_CONNECTION='192.168.15.201 35635 192.168.15.244 22'
USER='root'So until that gets a more permanent fix, we will just re-set it in each remote command:
Code:
core2quad ~ $ ssh kpw "PATH=$PATH ; set"
HOME='/tmp/root'
IFS='
'
KINDLE_TZ='GMT-06:00'
LANG='en_US.utf8'
LC_ALL='en_US.utf8'
LOGNAME='root'
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games'
PPID='17803'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/var/tmp/root'
SHELL='/bin/sh'
SSH_CONNECTION='192.168.15.201 35636 192.168.15.244 22'
USER='root'Get a current listing of how the three primary chains are setup in the kernel:
Code:
core2quad ~ $ ssh kpw "PATH=$PATH ; iptables -v -L"
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- ppp0 any anywhere anywhere tcp dpt:40317
0 0 ACCEPT tcp -- ppp0 any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- wlan0 any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT udp -- wlan0 any anywhere anywhere state ESTABLISHED
0 0 ACCEPT udp -- ppp0 any anywhere anywhere state ESTABLISHED
0 0 ACCEPT udp -- ppp0 any anywhere anywhere udp spt:40317
0 0 ACCEPT udp -- ppp0 any anywhere anywhere udp spt:49317
0 0 ACCEPT udp -- ppp0 any anywhere anywhere udp spt:33434
5696 32M ACCEPT all -- lo any localhost.localdomain anywhere
10795 832K ACCEPT all -- usb0 any anywhere anywhere
0 0 ACCEPT icmp -- any any anywhere anywhere state RELATED,ESTABLISHED
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 7717 packets, 1300K bytes)
pkts bytes target prot opt in out source destination
5696 32M ACCEPT all -- any lo anywhere localhost.localdomain
core2quad ~ $Now lets compare that with the stored system configuration file supplied by lab126 (on Kpw-5.3.3):
Code:
core2quad ~ $ ssh kpw "PATH=$PATH ; cat /etc/sysconfig/iptables"
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# TCP handling. Allow incoming TCP TPH on WAN
-A INPUT -i ppp0 -p tcp -m tcp --dport 40317 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
# UDP Handling. Only allow device initiated connections.
-A INPUT -i wlan0 -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p udp -m state --state ESTABLISHED -j ACCEPT
# ALLOW UDP PINs ports for TPHv3.0
-A INPUT -i ppp0 -p udp --sport 40317 -j ACCEPT
-A INPUT -i ppp0 -p udp --sport 49317 -j ACCEPT
-A INPUT -i ppp0 -p udp --sport 33434 -j ACCEPT
# Loopback. All traffic allowed.
-A INPUT -i lo -s 127.0.0.1 -j ACCEPT
-A OUTPUT -o lo -d 127.0.0.1 -j ACCEPT
# Usbnet. All traffic allowed.
-A INPUT -i usb0 -j ACCEPT
# ICMP. Allow only responses to local connections
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
core2quad ~ $Code:
core2quad ~ $ ssh kpw "PATH=$PATH ; iptables-save"
# Generated by iptables-save v1.3.8 on Wed Feb 6 13:21:59 2013
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [7981:1338955]
-A INPUT -i ppp0 -p tcp -m tcp --dport 40317 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p udp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p udp -m udp --sport 40317 -j ACCEPT
-A INPUT -i ppp0 -p udp -m udp --sport 49317 -j ACCEPT
-A INPUT -i ppp0 -p udp -m udp --sport 33434 -j ACCEPT
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -i usb0 -j ACCEPT
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -d 127.0.0.1 -o lo -j ACCEPT
COMMIT
# Completed on Wed Feb 6 13:21:59 2013This output would include the secondary and user-defined chains if they where in use.
There is a corresponding iptables-restore utility.
It re-defines the kernel's firewall rules in a single syscall from a stored snapshot file.
You can see that one possible work-flow in defining a custom firewall is to build it up one rule, one chain at a time; test until tired; save it in a file; edit in comments of why you did what you did (which looks like how lab126 did it).
(Does anyone see yet why I patched out that un-welcome banner message? ;) )
The three kernel network control bits of most interest here are:
Code:
# Packet forwarding : 0 == Disable, 1 == Enable
core2quad ~ $ ssh kpw "cat /proc/sys/net/ipv4/ip_forward"
0
# IPv4 dynamic address rewrite : 0 == Disable, 1 == Enable, 2 == Enable&Log
core2quad ~ $ ssh kpw "cat /proc/sys/net/ipv4/ip_dynaddr"
0
# Make multiple, physical paths work as one logical network
# 0 == Disable, 1 == Enable
core2quad ~ $ ssh kpw "cat /proc/sys/net/ipv4/conf/all/proxy_arp"
0The Kindle kernel firewall **as shipped** is intended to keep out everything except Amazon by wireless (Wifi & 3G) and the owner if directly wired to the Kindle by the USB cable.
None of the other common IPv4 things are supported, nor is IPv6.
(Don't close this page now, I am not going to add IPv6 support to the Kindles (today) ;) )
More to follow. . . .