/var/tmp/ppp.details.wan
PPP_IFACE=${PPP_IFACE}
PPP_TTY=$PPP_TTY
PPP_SPEED=$PPP_SPEED
PPP_LOCAL=$PPP_LOCAL
PPP_REMOTE=$PPP_REMOTE
PPP_IPPARAM=$PPP_IPPARAM
PPP_TTYNAME=$PPP_TTYNAME
EOF_VAR
# From Robert Ziegler's first edition (p.67-68):
EXTERNAL_INTERFACE=${PPP_IFACE}
LOOPBACK_INTERFACE='lo'
IPADDR=${PPP_LOCAL}
ANYWHERE='any/0'
MY_ISP='my.isp.address.range'
LOOPBACK='127.0.0.0/8'
CLASS_A='10.0.0.0/8'
CLASS_B='172.16.0.0/12'
CLASS_C='192.168.0.0/16'
CLASS_D_MULTICAST='224.0.0.0/4'
CLASS_E_RESERVED_NET='240.0.0.0/5'
BROADCAST_SRC='0.0.0.0'
BROADCAST_DEST='255.255.255.255'
PRIVPORTS='0:1023'
UNPRIVPORTS='1024:65535'
# END From Robert Ziegler's first edition.
# --------------------------------------------------
# 29 Feb. 2003 - from IPTables documentation:
# 5. Rusty's Really Quick Guide To Packet Filtering
#
# Most people just have a single PPP connection to the Internet, and
# don't want anyone coming back into their network, or the firewall:
## Insert connection-tracking modules (not needed if built into kernel).
$INSMOD ip_conntrack
$INSMOD ip_conntrack_ftp
$INSMOD ip_conntrack_irc
## Create chain which blocks new connections, except if coming from inside.
$IPTABLES -N block
$IPTABLES -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A block -m state --state NEW -i ! $EXTERNAL_INTERFACE -j ACCEPT
$IPTABLES -A block -j DROP
## Jump to that chain from INPUT and FORWARD chains.
$IPTABLES -A INPUT -j block
$IPTABLES -A FORWARD -j block
# --------------------------------------------------
# from the masquarading part of the IPTables documentation:
# 9. Mixing NAT and Packet Filtering
#
# It's common to want to do Network Address Translation (see the NAT
# HOWTO) and packet filtering. The good news is that they mix extremely
# well.
#
# You design your packet filtering completely ignoring any NAT you are
# doing. The sources and destinations seen by the packet filter will be
# the `real' sources and destinations. For example, if you are doing
# DNAT to send any connections to 1.2.3.4 port 80 through to 10.1.1.1
# port 8080, the packet filter would see packets going to 10.1.1.1 port
# 8080 (the real destination), not 1.2.3.4 port 80. Similarly, you can
# ignore masquerading: packets will seem to come from their real
# internal IP addresses (say 10.1.1.1), and replies will seem to go back
# there.
#
# You can use the `state' match extension without making the packet
# filter do any extra work, since NAT requires connection tracking
# anyway. To enhance the simple masquerading example in the NAT HOWTO to
# disallow any new connections from coming in the ppp0 interface, you
# would do this:
# Masquerade out ppp0
$IPTABLES -t nat -A POSTROUTING -o $EXTERNAL_INTERFACE -j MASQUERADE
# Disallow NEW and INVALID incoming or forwarded packets from ppp0.
$IPTABLES -A INPUT -i $EXTERNAL_INTERFACE -m state --state NEW,INVALID -j DROP
$IPTABLES -A FORWARD -i $EXTERNAL_INTERFACE -m state --state NEW,INVALID -j DROP
# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# --------------------------------------------------
# Turn off ping response (see the notes in this script):
/usr/local/bin/pingdown
# p. 204:
# turning off source routing
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# choices are .../conf/(all | default | lo | eth0 )/accept_source_route
This last bit is from "Building Linux and OpenBSD Firewalls" by
Sonnenreich and Yates.
It turns off accepting packages which specify a particular
route to their objective, something which seems to be a 'source'
of abuse.
Within the last year or two, the person who controlled the 'ipfilter'
software used with OpenBSD's firewall (described in the above book)
withdrew it from general use with OpenBSD, so they have moved over to
another statefull watching system that has been written from
scratch. I believe it is called 'if'.
Check http://www.openbsd.org,
and maybe also
http://www.microbsd.org.
The Open BSD people probably spend more time
doing code reviews than any other
project I'm aware of,
and find too many potential bugs to
report all of them to the original authors.
I realize that this doesn't fit some models of
'efficiency', but they have other priorities.
Some of the complications in my script above are due
to using 3 ISP's, and probable needs to tweak for each.
On line at http://www.linuxjournal.com,
check the archives for "Taming the Wild Netfilter" by
David A. Bandel, in the Sept. 2001 issue,
at htt://www.linux-mag.com, Sept. 2001,
"Packet Filtering in the 2.4 Kernel" by Paul "Rusty" Young
(the person most responsible for the code).
I think also at http://www.sysadminmag.com,
you can find an article "Halted Firewalls" by
Mike Murphy in the archives for the Jan. 2002 issue.
(They don't put all their articles on line, so maybe not.)
There are a bunch of special purpose 'mini-distributions' of
Linux and various BSDs, some of which are specificly for
use as firewall/NAT (Network Address Translation)/Router
machines.
Some of these don't assume you are creating the floppies
or what ever from a Linux environment, and provide
you with a floppy disk image and some tools to work with
the image, Freesco and floppyfw come to mind.
They usually provide the open source rawrite.exe DOS tool
to write the image file onto a floppy, creating everything
needed on the (probably bootable) floppy in one fell swoop.
Rather than rewriting the rawrite.exe program to run
from OS/2, I investigated the relations between the image
files generated by various programs and present the following
Rexx script to adapt them for use with the IBM
employee written programs loaddskf.exe, makedskf.exe and
some options of savedskf.exe. Sometimes if the floppy is
not full, they will trim it to save space, but the
IBM functions expect the size of a full floppy, with every byte
represented in the image file.
Also, I looked at the DR DOS diskcopy.exe program, which
can also generate image files, and determined that it
has trailing bytes (~417), which include information on the program
and possibly some type of hash/checksum which seems to be repeated.
DR DOS expert Matthias Paul would probably be the person who'd
possibly know what these extra bytes represent.
The method of analysis was simply to
fire up REXXTRY.CMD, use the standard library charin
function to read the entire functions into variables and parse
the larger value with the smaller, save the parts in variables
to examine further.
/* ReXX */
PARSE ARG file diskette
image = CharIn( file, 1, 1500000 ) ;
CALL Stream file, 'C', 'CLOSE' ;
image = Left( image, 1474560, '00'x ) ;
/* This will trim DR DOS disk images to
1474560 bytes long, or pad
those generated with the Unix 'dd',
or DOS rawrite.exe commands, which have
blank space trimmed, out to the
length that Loaddskf, Makedskf,
and some options of Savedskf expect.
*/
'@del rxwrite.img 2> nul:' ;
CALL CharOut 'rxwrite.img', image, 1 ;
image = '' ;
CALL Stream 'rxwrite.img', 'C', 'CLOSE' ;
'Loaddskf rxwrite.img 'diskette' /y /q /c' ;
'@del rxwrite.img' ;
Regards,
Dallas E. Legan II / leganii@surfree.com / dallasii@kincyb.com
Powered by......Lynx, the Internet at hyperkinetic speed.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 26 |
February |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
