On Sat, 24 Nov 2007 07:54:53 +0100 (CET)
Tom N wrote:

> I'd appreciate it if someone with some experience with iptables
> and firewalls would take a look at this page and let me know
> if it is okay or not:
>
> http://wiki.linuxquestions.org/wiki/..._a_workstation

It's okay if you want the whole world to connect to your ssh port.
There are a few other points that can be discussed but I suggest
you study this writeup:

http://linuxgazette.net/103/odonovan.html

M.

On Sat, 24 Nov 2007 19:10:53 +0300, Mikhail Zotov wrote:

> On Sat, 24 Nov 2007 07:54:53 +0100 (CET) Tom N
> wrote:
>
>> I'd appreciate it if someone with some experience with iptables and
>> firewalls would take a look at this page and let me know if it is okay
>> or not:

ardly, but that'd be an almost "clean" start.

>>
>> http://wiki.linuxquestions.org/wiki/..._a_workstation
>
> It's okay if you want the whole world to connect to your ssh port.

which as fa as we know from the OP might be exactly what was
required :-)

Tom, you'll have to clarify what is it exactly that you want to achieve
with your firewall, there's no possibility for anyone here to know it
better than you, functionnally speaking that is. Then if you can
describe what you want to do in terme of global functionalities some
here, or in more 'sec' oriented ngs may help you to tune your rules
but seriously if you're prepared to install a bunch of rulesets
just "found on the Net" without knowing globally what you're
installing you'd be safer by using no iptables at all :-)

> There
> are a few other points that can be discussed

To say the least :-) There's a dire lack in "ICMP horrors" blocking
and the idea that any outbound is granted is a bit too harsh on
my nerves ;-)

> but I suggest you study
> this writeup:
>
> http://linuxgazette.net/103/odonovan.html

That'd be a good start, I'd also recommend to have this
quite funny and fast reading:
http://security.maruhn.com/

and for later on, when a few things will be cleared
there's of course the source of it all:
http://netfilter.org/documentation/index.html

besides, as we're now in the XXIst century please install iproutes2
if not already present, that'll give you more power, more possibilities
(including QoS) and, of course more reading and headaches ;D)

On 2007-11-24, Mikhail Zotov wrote:
> On Sat, 24 Nov 2007 07:54:53 +0100 (CET)
> Tom N wrote:
>
>> I'd appreciate it if someone with some experience with iptables
>> and firewalls would take a look at this page and let me know
>> if it is okay or not:
>>
>> http://wiki.linuxquestions.org/wiki/..._a_workstation
>
> It's okay if you want the whole world to connect to your ssh port.

No, I don't. Should I just remove that whole line?

> There are a few other points that can be discussed but I suggest
> you study this writeup:
>
> http://linuxgazette.net/103/odonovan.html
>
> M.

Thanks, Mikhail. I wgetted the article and will read it carefully.

Tom

--
simpleman.s43
That would be at gee male

On 2007-11-24, loki harfagr wrote:
> On Sat, 24 Nov 2007 19:10:53 +0300, Mikhail Zotov wrote:
>
>> On Sat, 24 Nov 2007 07:54:53 +0100 (CET) Tom N
>> wrote:
>>
>>> I'd appreciate it if someone with some experience with iptables and
>>> firewalls would take a look at this page and let me know if it is okay
>>> or not:
>
> ardly, but that'd be an almost "clean" start.
>
>>>
>>> http://wiki.linuxquestions.org/wiki/..._a_workstation
>>
>> It's okay if you want the whole world to connect to your ssh port.
>
> which as fa as we know from the OP might be exactly what was
> required :-)

Nope.

>
> Tom, you'll have to clarify what is it exactly that you want to achieve
> with your firewall,

I'd like it to fire a cruise missile at any turkey who tries to send a spyware
popup to my computer.

:-)

> there's no possibility for anyone here to know it
> better than you,i

I'm pretty sure that everyone here knows more about this than I do.

> functionnally speaking that is. Then if you can
> describe what you want to do in terme of global functionalities some
> here, or in more 'sec' oriented ngs may help you to tune your rules
> but seriously if you're prepared to install a bunch of rulesets
> just "found on the Net" without knowing globally what you're
> installing you'd be safer by using no iptables at all :-)

I just want to have the equivalent of a good strong door with a lock
for my computer with respect to the internet.

>
>> There
>> are a few other points that can be discussed
>
> To say the least :-) There's a dire lack in "ICMP horrors" blocking
> and the idea that any outbound is granted is a bit too harsh on
> my nerves ;-)

Be nice if you explained that.

Inter-Continental Mounted Police?

>
>> but I suggest you study
>> this writeup:
>>
>> http://linuxgazette.net/103/odonovan.html
>
> That'd be a good start, I'd also recommend to have this
> quite funny and fast reading:
> http://security.maruhn.com/

I've bookmarked the site and will study it.

>
> and for later on, when a few things will be cleared
> there's of course the source of it all:
> http://netfilter.org/documentation/index.html

My head hurts already. :-)

>
> besides, as we're now in the XXIst century please install iproutes2
> if not already present, that'll give you more power, more possibilities
> (including QoS) and, of course more reading and headaches ;D)

I found the package on my CD and will install it.

Thanks a lot, Loki.

For now, I am planning on removing the SSH line and calling that
script at the end of /etc/rc.d/rc.S and very near the end of
/etc/rc.d/rc.6 right after dhcpcd is shut down and just before
all processes are killed.

That sound right?

Tom

--
simpleman.s43
That would be at gee male

On 2007-11-24, Tom N wrote:
> On 2007-11-24, loki harfagr wrote:

.....

>> but seriously if you're prepared to install a bunch of rulesets
>> just "found on the Net" without knowing globally what you're
>> installing you'd be safer by using no iptables at all :-)

Then why, if I had done a complete, default install of Slackware
12.0 would iptables have been installed and this firewall created:

(from /etc/rc.d/rc.modules)

# EXTERNAL=eth0
# INTERNAL=eth1
# echo 1 > /proc/sys/net/ipv4/ip_forward
# echo "Setting up NAT (Network Address Translation)..."
# # by default, nothing is forwarded.
# iptables -P FORWARD DROP
# # Allow all connections OUT and only related ones IN
# iptables -A FORWARD -i $EXTERNAL -o $INTERNAL -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A FORWARD -i $INTERNAL -o $EXTERNAL -j ACCEPT
# # enable MASQUERADING
# iptables -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE


I would call that installing a bunch of rulesets just found on the
net without knowing globally wat I am installing.

Evidently Patrick V. disagrees with you.

....

>
> For now, I am planning on removing the SSH line and calling that
> script at the end of /etc/rc.d/rc.S and very near the end of
> /etc/rc.d/rc.6 right after dhcpcd is shut down and just before
> all processes are killed.
>

I meant I'd run the script with the argument "start" in rc.S and
argument "stop" in rc.6

Tom


--
simpleman.s43
That would be at gee male

On Sat, 24 Nov 2007 07:54:53 +0100 (CET), Tom N wrote:

>I'd appreciate it if someone with some experience with iptables
>and firewalls would take a look at this page and let me know
>if it is okay or not:
>
>http://wiki.linuxquestions.org/wiki/..._a_workstation

Poor, the flush function doesn't. It's not required anyway, why
would one turn off a firewall?

for example, clear iptables and setup basic protection:
....
MSTATE="--match state --state"
....
iptables -t filter -F # clear iptables
iptables -t filter -X

iptables -P INPUT DROP # set policy
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# accept expected and local traffic
iptables -A INPUT -p all $MSTATE ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p all -i lo -j ACCEPT

At this point iptables allows only desired return traffic to requests
sent out, and local traffic. Any NEW requests from big bad Internet
get dropped as policy.

You may elaborate by adding logging rules and stuff, for example here's
some OUTPUT processing:
....
X_WORLD="ppp0"
LOGGED="LOG --log-level info --log-prefix " # -> /var/log/messages
PREFIX="JLE" # prefix for Junkview Log Entry
MAX_MSS="1392" # empty for path discovery
....
# log outgoing NEW
iptables -A OUTPUT -p all -o $X_WORLD $MSTATE NEW \
-j $LOGGED "$PREFIXut:accept - "

# clamp MTU for new TCP connections to world
if [ -n "$MAX_MSS" ]
then # use preset
iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
-o $X_WORLD -j TCPMSS --set-mss $MAX_MSS
else # use path discovery
iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
-o $X_WORLD -j TCPMSS --clamp-mss-to-pmtu
fi

O'Donovan's article is good, except he writes the rules in iptables-save
format, which I found confusing back when I was learning.


Ruleset with adaptive lockouts for a router/server here, guaranteed to
induce a headache )


Grant.

Hello Grant,
On 2007-11-24, Grant wrote:
> On Sat, 24 Nov 2007 07:54:53 +0100 (CET), Tom N wrote:
>
>>I'd appreciate it if someone with some experience with iptables
>>and firewalls would take a look at this page and let me know
>>if it is okay or not:
>>
>>http://wiki.linuxquestions.org/wiki/..._a_workstation
>
> Poor, the flush function doesn't. It's not required anyway, why
> would one turn off a firewall?

Not even if I'm shutting down the system?

> for example, clear iptables and setup basic protection:
> ...
> MSTATE="--match state --state"
> ...
> iptables -t filter -F # clear iptables
> iptables -t filter -X
>
> iptables -P INPUT DROP # set policy
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
>
> # accept expected and local traffic
> iptables -A INPUT -p all $MSTATE ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -p all -i lo -j ACCEPT
>
> At this point iptables allows only desired return traffic to requests
> sent out, and local traffic. Any NEW requests from big bad Internet
> get dropped as policy.

That sounds like what I want.

>
> You may elaborate by adding logging rules and stuff, for example here's
> some OUTPUT processing:
> ...
> X_WORLD="ppp0"
> LOGGED="LOG --log-level info --log-prefix " # -> /var/log/messages
> PREFIX="JLE" # prefix for Junkview Log Entry
> MAX_MSS="1392" # empty for path discovery
> ...
> # log outgoing NEW
> iptables -A OUTPUT -p all -o $X_WORLD $MSTATE NEW \
> -j $LOGGED "$PREFIXut:accept - "
>
> # clamp MTU for new TCP connections to world
> if [ -n "$MAX_MSS" ]
> then # use preset
> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
> -o $X_WORLD -j TCPMSS --set-mss $MAX_MSS
> else # use path discovery
> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
> -o $X_WORLD -j TCPMSS --clamp-mss-to-pmtu
> fi
>

I can follow, more-or-less, the basic firewall above, but this immediately
above loses me completely.

Aren't packet logs huge? Why the concern with output? Shouldn't it be
input that worries me?


> O'Donovan's article is good, except he writes the rules in iptables-save
> format, which I found confusing back when I was learning.
>
>
> Ruleset with adaptive lockouts for a router/server here, guaranteed to
> induce a headache )
>

I don't have a router or a server, so I don't need to suffer that headache now.

>
> Grant.

Thanks a lot,

Tom


--
simpleman.s43
That would be at gee male

On Sat, 24 Nov 2007 23:10:25 +0100 (CET), Tom N wrote:

>Hello Grant,
>On 2007-11-24, Grant wrote:
>> On Sat, 24 Nov 2007 07:54:53 +0100 (CET), Tom N wrote:
>>
>>>I'd appreciate it if someone with some experience with iptables
>>>and firewalls would take a look at this page and let me know
>>>if it is okay or not:
>>>
>>>http://wiki.linuxquestions.org/wiki/..._a_workstation
>>
>> Poor, the flush function doesn't. It's not required anyway, why
>> would one turn off a firewall?
>
>Not even if I'm shutting down the system?

Hardly matters then does it?
>
>> for example, clear iptables and setup basic protection:
>> ...
>> MSTATE="--match state --state"
>> ...
>> iptables -t filter -F # clear iptables
>> iptables -t filter -X
>>
>> iptables -P INPUT DROP # set policy
>> iptables -P FORWARD DROP
>> iptables -P OUTPUT ACCEPT
>>
>> # accept expected and local traffic
>> iptables -A INPUT -p all $MSTATE ESTABLISHED,RELATED -j ACCEPT
>> iptables -A INPUT -p all -i lo -j ACCEPT
>>
>> At this point iptables allows only desired return traffic to requests
>> sent out, and local traffic. Any NEW requests from big bad Internet
>> get dropped as policy.
>
>That sounds like what I want.

Yes, roughly the basic starter from Rusty Russell's guide. Iptables author

>> You may elaborate by adding logging rules and stuff, for example here's
>> some OUTPUT processing:
>> ...
>> X_WORLD="ppp0"
>> LOGGED="LOG --log-level info --log-prefix " # -> /var/log/messages
>> PREFIX="JLE" # prefix for Junkview Log Entry
>> MAX_MSS="1392" # empty for path discovery
>> ...
>> # log outgoing NEW
>> iptables -A OUTPUT -p all -o $X_WORLD $MSTATE NEW \
>> -j $LOGGED "$PREFIXut:accept - "
>>
>> # clamp MTU for new TCP connections to world
>> if [ -n "$MAX_MSS" ]
>> then # use preset
>> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
>> -o $X_WORLD -j TCPMSS --set-mss $MAX_MSS
>> else # use path discovery
>> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
>> -o $X_WORLD -j TCPMSS --clamp-mss-to-pmtu
>> fi
>>
>
>I can follow, more-or-less, the basic firewall above, but this immediately
>above loses me completely.

Sorry, it's from my router box, I copy/paste just as an example. Usually
one tells ppp (rp-pppoe) to do the TCP MSS clamping, but I chose to put
it in the firewall script because I can then change the MSS value without
restarting the ppp0 connection, I had trouble with my ISP dropping ICMPs.
>
>Aren't packet logs huge? Why the concern with output? Shouldn't it be
>input that worries me?

Problem is if you have some process runaway and spew garbage onto the
'net, idea is to have logs to help resolve the situation. As to size,
I have:

root@deltree:~# ls -l /var/log/messages*
-rw-r----- 1 root root 144561 2007-11-25 10:10 /var/log/messages
-rw-r----- 1 root root 513996 2007-11-25 04:40 /var/log/messages.1.gz
-rw-r----- 1 root root 495439 2007-11-18 04:40 /var/log/messages.2.gz
-rw-r----- 1 root root 598405 2007-11-11 04:40 /var/log/messages.3.gz
-rw-r----- 1 root root 481783 2007-11-04 04:40 /var/log/messages.4.gz
-rw-r----- 1 root root 361312 2007-10-28 04:40 /var/log/messages.5.gz
-rw-r----- 1 root root 379548 2007-10-21 04:40 /var/log/messages.6.gz

Dunno if you think that excessive for logs, but this:

root@deltree:~# tail /var/log/messages |cut -c-80
Nov 25 10:09:11 deltree kernel: JLEut:accept - IN= OUT=ppp0 SRC=123.2.77.8 DST
Nov 25 10:09:11 deltree kernel: JLE:fwd:request egress IN=eth1 OUT=ppp0 SRC=192.
Nov 25 10:10:02 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:10:04 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:11:44 deltree kernel: JLEut:accept - IN= OUT=ppp0 SRC=123.2.77.8 DST
Nov 25 10:11:50 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:11:52 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:12:35 deltree kernel: JLE:inp:drop msft_new IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:12:38 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
Nov 25 10:12:39 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.

gives an indication of the traffic, yes, it's busy One could argue
that one doesn't need to see the dropped traffic, but I'm curious about
the 'background radiation' of the Internet. Curious enough to display
it here:

Grant.

On 2007-11-24, Grant wrote:
> On Sat, 24 Nov 2007 23:10:25 +0100 (CET), Tom N wrote:

....

I ended up, for the nonce, using this script as /etc/rc.d/rc.iptables,
called from /etc/rc.d/rc.S with the argument "start":


#!/bin/sh
set -e

iptables="/usr/sbin/iptables"
modprobe="/sbin/modprobe"

load () {
echo "Loading kernel modules..."
$modprobe ip_tables
$modprobe ip_conntrack
$modprobe iptable_filter
$modprobe ipt_state
echo "Kernel modules loaded."

echo "Loading rules..."
$iptables -t filter -F
$iptables -t filter -X
$iptables -P FORWARD DROP
$iptables -P INPUT DROP
$iptables -P OUTPUT ACCEPT

$iptables -A INPUT -p ALL --match state --state ESTABLISHED,RELATED -j ACCEPT
$iptables -A INPUT -p ALL -s 127.0.0.1 -j ACCEPT
echo "Rules loaded."
}

flush () {
echo "Flushing rules..."
$iptables -P FORWARD ACCEPT
$iptables -F INPUT
$iptables -P INPUT ACCEPT
echo "Rules flushed."
}

case "$1" in
start|restart)
flush
load
;;
stop)
flush
;;
*)
echo "usage: start|stop|restart."
;;
esac
exit 0

Didn't bother putting it in rc.6 because it flushes the rules
and starts over.

iptables -L shows this:

hain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- localhost anywhere

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

>>That sounds like what I want.
>
> Yes, roughly the basic starter from Rusty Russell's guide. Iptables author

Exactly what I needed. Thanks.

>
>>> You may elaborate by adding logging rules and stuff, for example here's
>>> some OUTPUT processing:
>>> ...
>>> X_WORLD="ppp0"
>>> LOGGED="LOG --log-level info --log-prefix " # -> /var/log/messages
>>> PREFIX="JLE" # prefix for Junkview Log Entry
>>> MAX_MSS="1392" # empty for path discovery
>>> ...
>>> # log outgoing NEW
>>> iptables -A OUTPUT -p all -o $X_WORLD $MSTATE NEW \
>>> -j $LOGGED "$PREFIXut:accept - "
>>>
>>> # clamp MTU for new TCP connections to world
>>> if [ -n "$MAX_MSS" ]
>>> then # use preset
>>> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
>>> -o $X_WORLD -j TCPMSS --set-mss $MAX_MSS
>>> else # use path discovery
>>> iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN \
>>> -o $X_WORLD -j TCPMSS --clamp-mss-to-pmtu
>>> fi
>>>
>>
>>I can follow, more-or-less, the basic firewall above, but this immediately
>>above loses me completely.
>
> Sorry, it's from my router box, I copy/paste just as an example. Usually
> one tells ppp (rp-pppoe) to do the TCP MSS clamping, but I chose to put
> it in the firewall script because I can then change the MSS value without
> restarting the ppp0 connection, I had trouble with my ISP dropping ICMPs.
>>
>>Aren't packet logs huge? Why the concern with output? Shouldn't it be
>>input that worries me?
>
> Problem is if you have some process runaway and spew garbage onto the
> 'net, idea is to have logs to help resolve the situation. As to size,

Okay.

> I have:
>
> root@deltree:~# ls -l /var/log/messages*
> -rw-r----- 1 root root 144561 2007-11-25 10:10 /var/log/messages
> -rw-r----- 1 root root 513996 2007-11-25 04:40 /var/log/messages.1.gz
> -rw-r----- 1 root root 495439 2007-11-18 04:40 /var/log/messages.2.gz
> -rw-r----- 1 root root 598405 2007-11-11 04:40 /var/log/messages.3.gz
> -rw-r----- 1 root root 481783 2007-11-04 04:40 /var/log/messages.4.gz
> -rw-r----- 1 root root 361312 2007-10-28 04:40 /var/log/messages.5.gz
> -rw-r----- 1 root root 379548 2007-10-21 04:40 /var/log/messages.6.gz
>
> Dunno if you think that excessive for logs,

Not really.

> but this:
>
> root@deltree:~# tail /var/log/messages |cut -c-80
> Nov 25 10:09:11 deltree kernel: JLEut:accept - IN= OUT=ppp0 SRC=123.2.77.8 DST
> Nov 25 10:09:11 deltree kernel: JLE:fwd:request egress IN=eth1 OUT=ppp0 SRC=192.
> Nov 25 10:10:02 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:10:04 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:11:44 deltree kernel: JLEut:accept - IN= OUT=ppp0 SRC=123.2.77.8 DST
> Nov 25 10:11:50 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:11:52 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:12:35 deltree kernel: JLE:inp:drop msft_new IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:12:38 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
> Nov 25 10:12:39 deltree kernel: JLE:inp:drop msft_rpt IN=ppp0 OUT= MAC= SRC=123.
>
> gives an indication of the traffic, yes, it's busy One could argue
> that one doesn't need to see the dropped traffic, but I'm curious about
> the 'background radiation' of the Internet. Curious enough to display
> it here:

I'll check it out.

It would be interesting to take a look at what's passing my interface. I'll
do some more reading and enable some kind of logging.

Guess putting urls in <> allows newsreaders to open a browser with the
url in it ???

Thanks again, Grant,

Tom

--
simpleman.s43
That would be at gee male

On Sun, 25 Nov 2007 01:16:51 +0100 (CET), Tom N wrote:

>On 2007-11-24, Grant wrote:
>> On Sat, 24 Nov 2007 23:10:25 +0100 (CET), Tom N wrote:
....
>#!/bin/sh
>set -e
>
>iptables="/usr/sbin/iptables"
>modprobe="/sbin/modprobe"
>
>load () {
> echo "Loading kernel modules..."
> $modprobe ip_tables
> $modprobe ip_conntrack
> $modprobe iptable_filter
> $modprobe ipt_state
> echo "Kernel modules loaded."
>
> echo "Loading rules..."
> $iptables -t filter -F
> $iptables -t filter -X
> $iptables -P FORWARD DROP
> $iptables -P INPUT DROP
> $iptables -P OUTPUT ACCEPT
>
> $iptables -A INPUT -p ALL --match state --state ESTABLISHED,RELATED -j ACCEPT
> $iptables -A INPUT -p ALL -s 127.0.0.1 -j ACCEPT
^^^^^^^^^^^^--> don't like this, try:

$iptables -A INPUT -p all -i lo -j ACCEPT

instead?
....
>Guess putting urls in <> allows newsreaders to open a browser with the
>url in it ???

It's a standard for plaintext URLs. Habit

Grant.

On 2007-11-25, Grant wrote:
> On Sun, 25 Nov 2007 01:16:51 +0100 (CET), Tom N wrote:
>
>>On 2007-11-24, Grant wrote:
>>> On Sat, 24 Nov 2007 23:10:25 +0100 (CET), Tom N wrote:
> ...
>>#!/bin/sh
>>set -e
>>
>>iptables="/usr/sbin/iptables"
>>modprobe="/sbin/modprobe"
>>
>>load () {
>> echo "Loading kernel modules..."
>> $modprobe ip_tables
>> $modprobe ip_conntrack
>> $modprobe iptable_filter
>> $modprobe ipt_state
>> echo "Kernel modules loaded."
>>
>> echo "Loading rules..."
>> $iptables -t filter -F
>> $iptables -t filter -X
>> $iptables -P FORWARD DROP
>> $iptables -P INPUT DROP
>> $iptables -P OUTPUT ACCEPT
>>
>> $iptables -A INPUT -p ALL --match state --state ESTABLISHED,RELATED -j ACCEPT
>> $iptables -A INPUT -p ALL -s 127.0.0.1 -j ACCEPT
> ^^^^^^^^^^^^--> don't like this, try:
>
> $iptables -A INPUT -p all -i lo -j ACCEPT

Now iptables -L reads:

Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere


## ^^^^^^^^ that doesn't look right

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


>
> instead?
> ...
>>Guess putting urls in <> allows newsreaders to open a browser with the
>>url in it ???
>
> It's a standard for plaintext URLs. Habit

Oh. Does make them stand out, but doesn't make cutting and pasting easier.

Tom

--
simpleman.s43
That would be at gee male

On Sun, 25 Nov 2007 02:08:25 +0100 (CET), Tom N wrote:

>On 2007-11-25, Grant wrote:
>> On Sun, 25 Nov 2007 01:16:51 +0100 (CET), Tom N wrote:
>>
>>>On 2007-11-24, Grant wrote:
>>>> On Sat, 24 Nov 2007 23:10:25 +0100 (CET), Tom N wrote:
>> ...
>>>#!/bin/sh
>>>set -e
>>>
>>>iptables="/usr/sbin/iptables"
>>>modprobe="/sbin/modprobe"
>>>
>>>load () {
>>> echo "Loading kernel modules..."
>>> $modprobe ip_tables
>>> $modprobe ip_conntrack
>>> $modprobe iptable_filter
>>> $modprobe ipt_state
>>> echo "Kernel modules loaded."
>>>
>>> echo "Loading rules..."
>>> $iptables -t filter -F
>>> $iptables -t filter -X
>>> $iptables -P FORWARD DROP
>>> $iptables -P INPUT DROP
>>> $iptables -P OUTPUT ACCEPT
>>>
>>> $iptables -A INPUT -p ALL --match state --state ESTABLISHED,RELATED -j ACCEPT
>>> $iptables -A INPUT -p ALL -s 127.0.0.1 -j ACCEPT
>> ^^^^^^^^^^^^--> don't like this, try:
>>
>> $iptables -A INPUT -p all -i lo -j ACCEPT
>
>Now iptables -L reads:
>
>Chain INPUT (policy DROP)
>target prot opt source destination
>ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
>ACCEPT all -- anywhere anywhere
>
>
>## ^^^^^^^^ that doesn't look right

But if you do an 'iptables-save', you'll see:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT

for those two lines. Or use 'iptables -vL' instead, as it will
display the interfaces (as well as other info).

Grant.

On 2007-11-25, Grant wrote:
> On Sun, 25 Nov 2007 02:08:25 +0100 (CET), Tom N wrote:

>>>> $iptables -A INPUT -p ALL --match state --state ESTABLISHED,RELATED -j ACCEPT
>>>> $iptables -A INPUT -p ALL -s 127.0.0.1 -j ACCEPT
>>> ^^^^^^^^^^^^--> don't like this, try:
>>>
>>> $iptables -A INPUT -p all -i lo -j ACCEPT
>>
>>Now iptables -L reads:
>>
>>Chain INPUT (policy DROP)
>>target prot opt source destination
>>ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
>>ACCEPT all -- anywhere anywhere
>>
>>
>>## ^^^^^^^^ that doesn't look right
>
> But if you do an 'iptables-save', you'll see:
>
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i lo -j ACCEPT
>
> for those two lines. Or use 'iptables -vL' instead, as it will
> display the interfaces (as well as other info).

Got it. Thanks for your patience.

Funny thing is, ifconfig -a shows lo configured but doesn't
list any IP. Notably, there's no 127.0.0.1 there.

I have a hunch that this is relevant here.

Tom

--
simpleman.s43
That would be at gee male

On Sat, 24 Nov 2007 20:47:57 +0100, Tom N wrote:

> On 2007-11-24, Tom N wrote:
>> On 2007-11-24, loki harfagr wrote:
>
> ....
>
>>> but seriously if you're prepared to install a bunch of rulesets just
>>> "found on the Net" without knowing globally what you're installing
>>> you'd be safer by using no iptables at all :-)
>
> Then why, if I had done a complete, default install of Slackware 12.0
> would iptables have been installed and this firewall created:
>
> (from /etc/rc.d/rc.modules)
>
> # EXTERNAL=eth0
> # INTERNAL=eth1
> # echo 1 > /proc/sys/net/ipv4/ip_forward # echo "Setting up NAT
> (Network Address Translation)..." # # by default, nothing is forwarded.
> # iptables -P FORWARD DROP
> # # Allow all connections OUT and only related ones IN # iptables -A
> FORWARD -i $EXTERNAL -o $INTERNAL -m state --state ESTABLISHED,RELATED
> -j ACCEPT # iptables -A FORWARD -i $INTERNAL -o $EXTERNAL -j ACCEPT #
> # enable MASQUERADING
> # iptables -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE
>
>
> I would call that installing a bunch of rulesets just found on the net
> without knowing globally wat I am installing.

Please read back again the portion off rc.modules you
just quoted, take the time to notice it's all prefixed
by small chars looking like a sharp (for musicians) or
octothorpe or a corridor (for nethackers ;-): #

Please read back a few lines and see what the author put
those *commented* lines here for...-)

>
> Evidently Patrick V. disagrees with you.

Now you read it all I believe you may like to scratch off
the three letters 'dis' in the word 'agrees' :-)
(I'm just joking, no need to make that part of the thread any longer,
you now have had good advice from different other posters)

On Sat, 24 Nov 2007 20:25:55 +0100, Tom N wrote:

> On 2007-11-24, Mikhail Zotov wrote:
>> On Sat, 24 Nov 2007 07:54:53 +0100 (CET)
>> Tom N wrote:

>>
>> It's okay if you want the whole world to connect to your ssh port.
>
> No, I don't. Should I just remove that whole line?
>
>> There are a few other points that can be discussed but I suggest
>> you study this writeup:
>>
>> http://linuxgazette.net/103/odonovan.html
>>
>> M.
>
> Thanks, Mikhail. I wgetted the article and will read it carefully.
>
> Tom
>
I didn't read your firewall code, but I want to add these comments about
protecting ssh. Be aware that ssh is under constant attack. Apparently,
the bad guys would like ssh access to your box. ssh is also a key tool for
system administration and can used safely if it has been properly secured.

IMO, ssh is best protected by using one or more of the following:


1. ssh service has been moved off port 22 to avoid common attack.
2. ssh service is subject to firewall rule which limits logins to a list
of known "good" addresses.
3. ssh service subject to rate-limited firewall rule for unknown
addresses.
4. ssh access allowed by certificate authentication only
"PasswordAuthentication no"

If you are going to allow "anyone from anywhere" to attempt to connect to
ssh, then all four steps should be used, IMO.

BTW, there are a lot of tutorials online which show how to use
certificate authentication for ssh. It is easiest to make sure that
certificate authentication is working locally before exposing the ssh
service globally, etc.

--
Douglas Mayne

On Sun, 25 Nov 2007 08:11:17 -0700, Douglas Mayne wrote:

> On Sat, 24 Nov 2007 20:25:55 +0100, Tom N wrote:
>
>> On 2007-11-24, Mikhail Zotov wrote:
>>> On Sat, 24 Nov 2007 07:54:53 +0100 (CET) Tom N
>>> wrote:
>
>>>
>>> It's okay if you want the whole world to connect to your ssh port.
>>
>> No, I don't. Should I just remove that whole line?
>>
>>> There are a few other points that can be discussed but I suggest you
>>> study this writeup:
>>>
>>> http://linuxgazette.net/103/odonovan.html
>>>
>>> M.
>>
>> Thanks, Mikhail. I wgetted the article and will read it carefully.
>>
>> Tom
>>
> I didn't read your firewall code, but I want to add these comments about
> protecting ssh. Be aware that ssh is under constant attack. Apparently,
> the bad guys would like ssh access to your box. ssh is also a key tool
> for system administration and can used safely if it has been properly
> secured.
>
> IMO, ssh is best protected by using one or more of the following:
>
>
> 1. ssh service has been moved off port 22 to avoid common attack.
> 2. ssh service is subject to firewall rule which limits logins to a list of
> known "good" addresses.
> 3. ssh service subject to rate-limited firewall rule for unknown
> addresses.
> 4. ssh access allowed by certificate authentication only
> "PasswordAuthentication no"
>
> If you are going to allow "anyone from anywhere" to attempt to connect
> to ssh, then all four steps should be used, IMO.

I'd personally add a 5th protection, control the opening and closing
the ssh port(s) by port-knocking rules but I reckon that it may seem a bit
überparanoïd for a simple desktop of a simple user, most of the attackers
able to pass the 4 previous filters are probably not after you, they
certainly have better targets on :-)

> BTW, there are a lot of tutorials online which show how to use
> certificate authentication for ssh. It is easiest to make sure that
> certificate authentication is working locally before exposing the ssh
> service globally, etc.

Yes, and, anyway you protect your access please also mind to protect
your data, anything you don't want to be read, even by mistake, must
be encrypted.
Everything that belongs to work has to be protected by the solutions
given by people responsible of it at your work *and* locally protected
on your machines.

On 2007-11-25, loki harfagr wrote:
> On Sat, 24 Nov 2007 20:47:57 +0100, Tom N wrote:
>
>> On 2007-11-24, Tom N wrote:
>>> On 2007-11-24, loki harfagr wrote:
>>
>> ....
>>
>>>> but seriously if you're prepared to install a bunch of rulesets just
>>>> "found on the Net" without knowing globally what you're installing
>>>> you'd be safer by using no iptables at all :-)
>>
>> Then why, if I had done a complete, default install of Slackware 12.0
>> would iptables have been installed and this firewall created:
>>
>> (from /etc/rc.d/rc.modules)
>>
>> # EXTERNAL=eth0
>> # INTERNAL=eth1
>> # echo 1 > /proc/sys/net/ipv4/ip_forward # echo "Setting up NAT
>> (Network Address Translation)..." # # by default, nothing is forwarded.
>> # iptables -P FORWARD DROP
>> # # Allow all connections OUT and only related ones IN # iptables -A
>> FORWARD -i $EXTERNAL -o $INTERNAL -m state --state ESTABLISHED,RELATED
>> -j ACCEPT # iptables -A FORWARD -i $INTERNAL -o $EXTERNAL -j ACCEPT #
>> # enable MASQUERADING
>> # iptables -t nat -A POSTROUTING -o $EXTERNAL -j MASQUERADE
>>
>>
>> I would call that installing a bunch of rulesets just found on the net
>> without knowing globally wat I am installing.
>
> Please read back again the portion off rc.modules you
> just quoted, take the time to notice it's all prefixed
> by small chars looking like a sharp (for musicians) or
> octothorpe or a corridor (for nethackers ;-): #
>
> Please read back a few lines and see what the author put
> those *commented* lines here for...-)

So you are trying to tell me that the stock install of Slackware
12 included iptables but no default firewall using it?

I don't think so.

It may not be that ruleset, but there is _a_ ruleset.

Which serves my point as well as that one.

Nor was I, as you said in that post, 'arbitrarily downloading
rulesets from the internet'.

I was posting one here and asking for advice about it, and it
wasn't 'arbitrary'. The description that came with it fit
my needs.

I asked for advice on a ruleset, and all I have received
from you on the subjecet is bull**** and irrational criticism.

I don't appreciate it.

Tom


















Tom

On 2007-11-25, Douglas Mayne wrote:
> On Sat, 24 Nov 2007 20:25:55 +0100, Tom N wrote:

.....

> I didn't read your firewall code, but I want to add these comments about
> protecting ssh. Be aware that ssh is under constant attack. Apparently,
> the bad guys would like ssh access to your box. ssh is also a key tool for
> system administration and can used safely if it has been properly secured.
>
> IMO, ssh is best protected by using one or more of the following:
>
>
> 1. ssh service has been moved off port 22 to avoid common attack.
> 2. ssh service is subject to firewall rule which limits logins to a list
> of known "good" addresses.
> 3. ssh service subject to rate-limited firewall rule for unknown
> addresses.
> 4. ssh access allowed by certificate authentication only
> "PasswordAuthentication no"
>
> If you are going to allow "anyone from anywhere" to attempt to connect to
> ssh, then all four steps should be used, IMO.
>
> BTW, there are a lot of tutorials online which show how to use
> certificate authentication for ssh. It is easiest to make sure that
> certificate authentication is working locally before exposing the ssh
> service globally, etc.
>

Thanks Douglas. For now, my security measures regarding ssh are more
than adequate: I don't have it installed.

:-)

But I will save your post for future reference.


Tom

--
simpleman.s43
That would be at gee male

On Sun, 25 Nov 2007 19:54:16 +0100, Tom N wrote:

....
>> Please read back a few lines and see what the author put
>> those *commented* lines here for...-)
>
> So you are trying to tell me that the stock install of Slackware 12
> included iptables but no default firewall using it?

Yes.
er. let me think about it...

Yes.

As you seem to be reluctant on reading the script you quoted,
just check it for real and you'll see it too:
Simply boot a fresh Slackware installation and read the
output of the command you already met in your thread:
iptables -vL -n

>
> I don't think so.

You will.

> It may not be that ruleset, but there is _a_ ruleset.

there used to be one at the end of the rainbow but
I just had to borrow it for an emergency case, I swear
it will be back ASAP ;-)
....
>
> I was posting one here and asking for advice about it, and it wasn't
> 'arbitrary'. The description that came with it fit my needs.
>
> I asked for advice on a ruleset, and all I have received from you on the
> subjecet is bull**** and irrational criticism.

You should now know that's not the case

> I don't appreciate it.

And I wouldn't have, but you're just overheating on a small affair
you had between your understanding and my poor english writing,
end of the affair.

Now, can we have real life and enjoy listening to some Alice Cooper ?-)