Port 80 Open

On 2007-10-27 Telly Williams wrote:
> Maybe I'm not understanding something here. I ran a check on my ports
> to see what's wrong with it. Only port 80 comes up as open, and,
> apparently, is a security violation.

How did you check? nmap? From the inside? From the outside? What were
the actual results? What does netstat show?

> That's chaffing me, because from what I understand, without port i80
> open I'm not able to get on the WWW, so even if you ARE NOT running a
> web server, it still needs to be "open".

Ummm... no? A port needs to be open only if you want to accept incoming
connection attemps (i.e. if you want to run a server). You don't need
any port open if you just want to browse the web.

[...]
> Also, I'm running in stealth (not allowing icmp echo replies or
> requests).

*facepalm*

"Stealth" is braindead marketing babble invented by people who failed to
understand TCP/IP for people who failed to understand TCP/IP.

> Some of my ports (i.e., 25 and 443) are coming up as closed. Why are
> these ports showing up as closed at all?

Probably because your ruleset says so. How 'bout letting us take an
actual look at it? Besides, it doesn't matter at all if they show up, as
long as they're closed.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Forgot to send this via distro:

> > > ports to see what's wrong with it. Only port 80 comes up as
> > > open, and, apparently, is a security violation.
> >
> > why?
>
It's what I got from the check at grc.com.
>
> > > ESTABLISHED,RELATED, the packets being dropped if they don't
> >
> > ... you want just these.
> >
OK, thanks.
>
> > > Also, I'm running in stealth (not allowing icmp echo replies or
> >
> > eh, not quite stealth
>
What do you mean by that? Ansgar said the same thing. Now I'm
feeling like a dummy.
>
> > > requests). Some of my ports (i.e., 25 and 443) are coming up as
> > > closed. Why are these ports showing up as closed at all?
> >
> > why should they be open? are you providing SMTP and HTTPS to the outside?
>
No, but I now understand what you're saying.
>
> > perhaps providing a bit more info would help (eg iptables-save, interfaces)
>
>
# Generated by iptables-save v1.3.6 on Sat Oct 27 17:51:42 2007
*filter
:INPUT DROP [8702:393937]
:FORWARD DROP [0:0]
:OUTPUT DROP [12:1175]
:All_flags - [0:0]
:Fragment - [0:0]
:Invalid - [0:0]
:No_flags - [0:0]
:Spoofs - [0:0]
:allowed - [0:0]
:bad_tcp - [0:0]
:icmp_packets - [0:0]
:tcp_packets - [0:0]
:udp_packets - [0:0]
-A INPUT -p tcp -j bad_tcp
-A INPUT -p tcp -f -j Fragment
-A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.255.255.255 -j Spoofs
-A INPUT -p tcp -m iprange --src-range 172.16.0.0-172.31.255.255 -j Spoofs
-A INPUT -p tcp -m iprange --src-range 192.168.0.0-192.168.255.255 -j Spoofs
-A INPUT -p tcp -m iprange --src-range 169.254.0.0-169.254.255.255 -j Spoofs
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH --rsource -j DROP
-A INPUT -d XX.XXX.XXX.XXX -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -p tcp -j tcp_packets
-A INPUT -i eth1 -p udp -j udp_packets
-A INPUT -i eth1 -p icmp -j icmp_packets
-A INPUT -p tcp -m multiport --sports ! 8002 -m limit --limit 6/min --limit-burst 6 -j LOG --log-prefix "INPUT pkt dead: " --log-level 7
#The above was for xmms. I couldn't get it to work otherwise,
#but I'm still figuring out iptables & tcp/ip.

-A OUTPUT -p tcp -j tcp_packets
-A OUTPUT -s XX.XX.XXX.XXX -j ACCEPT
-A OUTPUT -p tcp -m multiport --dports ! 8002 -m limit --limit 6/min --limit-burst 6 -j LOG --log-prefix "OUTPUT pkt dead: " --log-level 7
# These numbers were arbitrary. I'm still trying to understand
# them enough to put in accurate numbers.

-A All_flags -j LOG --log-prefix "All Flags Set: " --log-level 5
-A All_flags -j DROP
-A Fragment -j LOG --log-prefix "Fragment: " --log-level 5
-A Fragment -j DROP
-A Invalid -j LOG --log-prefix "Packet not ID'd: " --log-level 5
-A Invalid -j DROP
-A No_flags -j LOG --log-prefix "No Flags Set: " --log-level 5
-A No_flags -j DROP
-A Spoofs -j LOG --log-prefix "Spoof: " --log-level 5
-A Spoofs -j DROP
-A allowed -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A allowed -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A allowed -p tcp -j DROP
-A bad_tcp -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j LOG --log-prefix "No SYN/ACK: " --log-level 5
-A bad_tcp -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A bad_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j All_flags
-A bad_tcp -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j No_flags
-A bad_tcp -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j LOG --log-prefix "New not syn: " --log-level 5
-A bad_tcp -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A bad_tcp -p tcp -m state --state INVALID -j Invalid
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j DROP
# With the above two rules, I thought it put me in stealth
# mode(?).

-A tcp_packets -p tcp -m tcp --dport 80 -j allowed
-A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j allowed
-A tcp_packets -p tcp -m tcp --dport 25 -j allowed
-A tcp_packets -p tcp -m tcp --sport 123 -m comment --comment "NTP" -j allowed
-A tcp_packets -p tcp -m tcp --dport 465 -m comment --comment "SMTPS" -j allowed
-A udp_packets -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -m comment --comment "DHCP Purposes" -j ACCEPT
-A udp_packets -p udp -m udp --dport 80 -j ACCEPT
-A udp_packets -p udp -m udp --sport 123 -m comment --comment "NTP" -j ACCEPT
-A udp_packets -p udp -m udp --dport 443 -j ACCEPT
-A udp_packets -p udp -m udp --dport 465 -m comment --comment "SMTPS" -j ACCEPT
-A udp_packets -s XX.XX.XX.XX -p udp -m udp --dport 53 -j ACCEPT
-A udp_packets -s XX.XX.XX.XX -p udp -m udp --dport 53 -j ACCEPT
COMMIT
# Completed on Sat Oct 27 17:51:42 2007

Hope this helps.

--------------------
Telly Williams
"Knowledge Is Power"


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

On Sat, Oct 27, 2007 at 06:15:31PM -0600, Telly Williams wrote:
....
> > > eh, not quite stealth
> >
> What do you mean by that? Ansgar said the same thing. Now I'm
> feeling like a dummy.

that's simply not 'stealth' mode, as soon as you connect to an IP the normal
way (eg http://...) , the other side knows your IP and can map your side -
that's what grc.com did.

> >
> > > > requests). Some of my ports (i.e., 25 and 443) are coming up as
> > > > closed. Why are these ports showing up as closed at all?
> > >
> > > why should they be open? are you providing SMTP and HTTPS to the outside?
> >
> No, but I now understand what you're saying.

....
> -A INPUT -i eth1 -p tcp -j tcp_packets
....
> -A allowed -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
> -A allowed -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A allowed -p tcp -j DROP
....
> -A tcp_packets -p tcp -m tcp --dport 80 -j allowed
> -A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j allowed
....

well, you're expliciting exposing all those ports via the chain
INPUT->*_packets->allowed, assuming eth1 is on internet side


HTH - 'night
--
paolo


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

On 2007-10-27 Telly Williams wrote:
> -A INPUT -p tcp -j bad_tcp
> -A INPUT -p tcp -f -j Fragment
> -A INPUT -p tcp -m iprange --src-range 10.0.0.0-10.255.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 172.16.0.0-172.31.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 192.168.0.0-192.168.255.255 -j Spoofs
> -A INPUT -p tcp -m iprange --src-range 169.254.0.0-169.254.255.255 -j Spoofs

You don't need the iprange module for this, but you most definitely want
these rules to apply to *all* IP packets, not just to TCP.

iptables -A INPUT -s 10.0.0.0/8 -j Spoofs
iptables -A INPUT -s 172.16.0.0/12 -j Spoofs
iptables -A INPUT -s 192.168.0.0/16 -j Spoofs
iptables -A INPUT -s 169.254.0.0/16 -j Spoofs

Depending on your infrastructure you may also want to specify the input
interface here.

> -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
> -A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT

No other source address than 127.0.0.1/8 is supposed to appear at the
loopback interface.

iptables -A INPUT -i lo -s 127.0.0.1/8 -j ACCEPT

[...]
> -A INPUT -d XX.XXX.XXX.XXX -m state --state RELATED,ESTABLISHED -j ACCEPT

It's rather pointless to discriminate this rule by destination IP,
because it's traffic that belongs to an already established connection
(i.e. you already accepted traffic for this). Also you should allow
ESTABLISHED,RELATED traffic in the other chains as well:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

You can omit the last one if you're not forwarding packets.

> -A INPUT -i eth1 -p tcp -j tcp_packets
> -A INPUT -i eth1 -p udp -j udp_packets
> -A INPUT -i eth1 -p icmp -j icmp_packets

Defining one chain per protocol and do all the packet handling there may
work for ICMP, but for TCP and UDP it's probably not the best of ideas,
because with these protocols a packet in the INPUT chain usually needs
other rules than a packet in the OUTPUT (or FORWARD) chain.

> -A INPUT -p tcp -m multiport --sports ! 8002 -m limit --limit 6/min --limit-burst 6 -j LOG --log-prefix "INPUT pkt dead: " --log-level 7

Since you specified only one port you don't need the multiport module
here.

[...]
> -A OUTPUT -s XX.XX.XXX.XXX -j ACCEPT

Why are you ACCEPTing traffic based on the source address? For new
outbound connections you should ACCEPT based on destination and state
NEW, for everything else, you should use an ESTABLISHED,RELATED rule
just like you do in the INPUT chain.

[...]
> -A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
> -A icmp_packets -p icmp -m icmp --icmp-type 11 -j DROP
> # With the above two rules, I thought it put me in stealth
> # mode(?).

Repeating myself: "stealth" is braindead marketing babble invented by
people who failed to understand TCP/IP for people who fail to understand
TCP/IP. Your host doesn't magically become "invisible" just because it
drops packets. TCP/IP doesn't work that way.

Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
is a vital part of IP and required e.g. for troubleshooting connection
problems. Rather do something like this:

iptables -N icmp_packets
# Allow ping, but limit it to 10 requests per second:
iptables -A icmp_packets -p icmp --icmp-type echo-request \
-m state --state NEW -m limit --limit 10/sec -j ACCEPT
# Allow echo replies (pong) for accepted pings:
iptables -A icmp_packets -p icmp --icmp-type echo-reply \
-m state --state ESTABLISHED -j ACCEPT
# Allow troubleshooting messages for all established connections:
iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type source-quench \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type time-exceeded \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
-m state --state RELATED -j ACCEPT
iptables -A icmp_packets -j DROP

I'd also recommend to REJECT packets rather than simply DROP them, so I
usually define a DENY chain and put it at the end of the INPUT, OUTPUT
and FORWARD chains:

iptables -N DENY
iptables -A DENY -p tcp -m limit --limit 10/sec -j REJECT \
--reject-with tcp-reset
iptables -A DENY -p udp -m limit --limit 10/sec -j REJECT \
--reject-with icmp-port-unreachable
iptables -A DENY -j DROP

> -A tcp_packets -p tcp -m tcp --dport 80 -j allowed
> -A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j allowed
> -A tcp_packets -p tcp -m tcp --dport 25 -j allowed
> -A tcp_packets -p tcp -m tcp --sport 123 -m comment --comment "NTP" -j allowed

Why are you ACCEPTing NTP packets based on the source port? Unlike not
being "stealth" this can be an actual security breach in your firewall.
ACCEPT NEW NTP connections in the appropriate chain (depending on
whether you want to allow inbound or outbound NTP), the rest is covered
by your ESTABLISHED,RELATED rules.

[...]
> -A udp_packets -i eth1 -p udp -m udp --sport 67:68 --dport 67:68 -m comment --comment "DHCP Purposes" -j ACCEPT
[...]
> -A udp_packets -p udp -m udp --sport 123 -m comment --comment "NTP" -j ACCEPT

Same with these.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

Ansgar, Paolo, and David,

Thanks for the help. I utilized your ideas and ran nmap and
nothing comes up (I did this from the same host, though). My
logs dropped to nil activity after implementing a combo of the
techniques you three mentioned (also, is it a bad thing if my
logs aren't writing anything now, or is it that my ports can't
be "seen"?). Interestingly (to me), ports 0 and 1 come up as
closed (from grc.com, I assume because of the set limits that
make my firewall "adaptive").

> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> You can omit the last one if you're not forwarding packets.

Only a small minority of people use the forward chain, right? I
read somewhere that not even ISPs use port forwarding
(relaying?).

> Why are you ACCEPTing traffic based on the source address? For new
> outbound connections you should ACCEPT based on destination and state
> NEW, for everything else, you should use an ESTABLISHED,RELATED rule
> just like you do in the INPUT chain.

Currently, I have OUTPUT accepting NEW,ESTABLISHED,RELATED. If
I'm thinking right about what you said Ansgar, the only thing I
need to worry about in OUTPUT is NEW, so I'm about to change it
and see what happens.
>
> Repeating myself: "stealth" is braindead marketing babble invented by
> people who failed to understand TCP/IP for people who fail to understand
> TCP/IP. Your host doesn't magically become "invisible" just because it
> drops packets. TCP/IP doesn't work that way.

Then why does the site http://www.grc.com keep referring to
ports as being under stealth? Are they defining "stealth" in a
different way? What does one have to gain by propogating this
"marketing babble"?

> Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
> is a vital part of IP and required e.g. for troubleshooting connection
> problems. Rather do something like this:
>
> iptables -N icmp_packets
> # Allow ping, but limit it to 10 requests per second:
> iptables -A icmp_packets -p icmp --icmp-type echo-request \
> -m state --state NEW -m limit --limit 10/sec -j ACCEPT
> # Allow echo replies (pong) for accepted pings:
> iptables -A icmp_packets -p icmp --icmp-type echo-reply \
> -m state --state ESTABLISHED -j ACCEPT
> # Allow troubleshooting messages for all established connections:
[...]
> iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
> -m state --state RELATED -j ACCEPT
> iptables -A icmp_packets -j DROP
>
Thanks for this (above).

> I'd also recommend to REJECT packets rather than simply DROP them, so I
> usually define a DENY chain and put it at the end of the INPUT, OUTPUT
> and FORWARD chains:
>
> iptables -N DENY
> iptables -A DENY -p tcp -m limit --limit 10/sec -j REJECT \
> --reject-with tcp-reset
> iptables -A DENY -p udp -m limit --limit 10/sec -j REJECT \
> --reject-with icmp-port-unreachable
> iptables -A DENY -j DROP

Thanks again.

--
Telly Williams
"Knowledge Is Power"


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

On Sun, Oct 28, 2007 at 08:35:30PM -0600, Telly Williams wrote:
> Ansgar, Paolo, and David,
>
> Thanks for the help. I utilized your ideas and ran nmap and
> nothing comes up (I did this from the same host, though). My

er... is your fw supposed to protect you from yourself?
try a remote scanner like grc.com's.

> logs aren't writing anything now, or is it that my ports can't

look at your itables-save, select a chain that goes through LOG, ask grc.com
to strees a port for that chain. See what happens in the logs.

> be "seen"?). Interestingly (to me), ports 0 and 1 come up as
> closed (from grc.com, I assume because of the set limits that
> make my firewall "adaptive").

If by 'adaptive' you mean the -m state on input, yes. Which is btw true for
any other port you did not open explicitly.

>
> Only a small minority of people use the forward chain, right? I

dunno ... you need FORWARD only if your machine routes packets for other
machines, eg your machine sits betweeen the LAN and I'net. Or you've got
some fancy virtual machines / alis iface setup.

> Currently, I have OUTPUT accepting NEW,ESTABLISHED,RELATED. If
> I'm thinking right about what you said Ansgar, the only thing I
> need to worry about in OUTPUT is NEW, so I'm about to change it

you need all 3.

> Then why does the site http://www.grc.com keep referring to
> ports as being under stealth? Are they defining "stealth" in a

I guess (checking their port 113 write up) they just mean what the rule
--state ESTABLISHED,RELATED on INPUT does. ie, in their wording, if you have
such rule in INPUT chain (you do, right?) you can proudly say your machine
if fully 'Stealthy(TM)'

> different way? What does one have to gain by propogating this
> "marketing babble"?

hype behind fw sw market. Just marketing, in other words.

For some tech about 'stealth' mode, 'man nmap' - check for -sS -sF -sX
-sN -sI; also check README and man page for hping2 or hping3 for some other
insights. Good reading.


--
paolo


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Hello,

Ansgar -59cobalt- Wiechers a écrit :
> On 2007-10-27 Telly Williams wrote:
>
>>-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
>>-A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT
>
> No other source address than 127.0.0.1/8 is supposed to appear at the
> loopback interface.

Wrong. Any local address, including the whole range 127.0.0.0/8 and all
addresses and aliases configured on local network interfaces may appear
in traffic involving the loopback interface. Besides, what's the use of
address-based filtering on the loopback interface ?

>>-A icmp_packets -p icmp -m icmp --icmp-type 8 -j DROP
>>-A icmp_packets -p icmp -m icmp --icmp-type 11 -j DROP
>> # With the above two rules, I thought it put me in stealth
>> # mode(?).
>
> Repeating myself: "stealth" is braindead marketing babble invented by
> people who failed to understand TCP/IP for people who fail to understand
> TCP/IP.

Anyway, "stealth" means that your box does not reply to any solicitation
from the outside, not that it only drops some ICMP types.

> Your host doesn't magically become "invisible" just because it
> drops packets.

Agreed.

> Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
> is a vital part of IP and required e.g. for troubleshooting connection
> problems. Rather do something like this:
>
> iptables -N icmp_packets
> # Allow ping, but limit it to 10 requests per second:
> iptables -A icmp_packets -p icmp --icmp-type echo-request \
> -m state --state NEW -m limit --limit 10/sec -j ACCEPT
> # Allow echo replies (pong) for accepted pings:
> iptables -A icmp_packets -p icmp --icmp-type echo-reply \
> -m state --state ESTABLISHED -j ACCEPT
> # Allow troubleshooting messages for all established connections:
> iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \
> -m state --state RELATED -j ACCEPT
> iptables -A icmp_packets -p icmp --icmp-type source-quench \
> -m state --state RELATED -j ACCEPT
> iptables -A icmp_packets -p icmp --icmp-type time-exceeded \
> -m state --state RELATED -j ACCEPT
> iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
> -m state --state RELATED -j ACCEPT
> iptables -A icmp_packets -j DROP

I used to accept source-quench, but not any more after reading that some
DoS attacks were based on it, and I'm not so sure it's really useful. I
acknowledge that destination-unreachable can be abused too, but this one
is really necessary.

>>-A tcp_packets -p tcp -m tcp --dport 80 -j allowed
>>-A tcp_packets -p tcp -m tcp --dport 443 -m comment --comment "HTTPS" -j allowed
>>-A tcp_packets -p tcp -m tcp --dport 25 -j allowed
>>-A tcp_packets -p tcp -m tcp --sport 123 -m comment --comment "NTP" -j allowed
>
> Why are you ACCEPTing NTP packets based on the source port?

Besides, I'm not sure that NTP uses TCP transport. Conversely HTTP(S)
and SMTP(S) don't use UDP transport.

I globally agree with the other comments and suggestions.


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org

Pascal Hambourg said:

>Besides, I'm not sure that NTP uses TCP transport.

NTP uses only port 123/UDP for time service.

Port 123/TCP is currently unused.

--
Steve Kostecke <steve.RemoveThis@debian.org>
Public Key at gopher://kostecke.net or `finger steve.RemoveThis@kostecke.net`


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

On 2007-10-29 Pascal Hambourg wrote:
> Ansgar -59cobalt- Wiechers a écrit :
>> On 2007-10-27 Telly Williams wrote:
>>> -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
>>> -A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT
>>
>> No other source address than 127.0.0.1/8 is supposed to appear at the
>> loopback interface.
>
> Wrong. Any local address, including the whole range 127.0.0.0/8 and all
> addresses and aliases configured on local network interfaces may appear
> in traffic involving the loopback interface. Besides, what's the use of
> address-based filtering on the loopback interface ?

Ah, of course you're right. My bad. Make that:

-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

[...]
>> Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
>> is a vital part of IP and required e.g. for troubleshooting connection
>> problems. Rather do something like this:
>>
>> iptables -N icmp_packets
>> # Allow ping, but limit it to 10 requests per second:
>> iptables -A icmp_packets -p icmp --icmp-type echo-request \
>> -m state --state NEW -m limit --limit 10/sec -j ACCEPT
>> # Allow echo replies (pong) for accepted pings:
>> iptables -A icmp_packets -p icmp --icmp-type echo-reply \
>> -m state --state ESTABLISHED -j ACCEPT
>> # Allow troubleshooting messages for all established connections:
>> iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type source-quench \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type time-exceeded \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -j DROP
>
> I used to accept source-quench, but not any more after reading that
> some DoS attacks were based on it, and I'm not so sure it's really
> useful.

Quoting from RFC 792:

| A gateway may discard internet datagrams if it does not have the
| buffer space needed to queue the datagrams for output to the next
| network on the route to the destination network. If a gateway
| discards a datagram, it may send a source quench message to the
| internet source host of the datagram. A destination host may also
| send a source quench message if datagrams arrive too fast to be
| processed. The source quench message is a request to the host to cut
| back the rate at which it is sending traffic to the internet
| destination. The gateway may send a source quench message for every
| message that it discards. On receipt of a source quench message, the
| source host should cut back the rate at which it is sending traffic to
| the specified destination until it no longer receives source quench
| messages from the gateway. The source host can then gradually
| increase the rate at which it sends traffic to the destination until
| it again receives source quench messages.
|
| The gateway or host may send the source quench message when it
| approaches its capacity limit rather than waiting until the capacity
| is exceeded. This means that the data datagram which triggered the
| source quench message may be delivered.

Long story short: source-quench messages allow two hosts to negotiate
transmission parameters when for some reason the connection turns out to
be sub-optimal.

I too heard that source-quench may be used in DoS attacks, though I'm
not aware of any, but since the above rules allow this message type only
when it's related to already established connections I believe it should
be okay. Someone correct me if I'm wrong here.

Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org