Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
Port 80 OpenHi, Maybe I'm not understanding something here. I ran a check on my That's chaffing me, because from what I understand, without port Anything that comes into port 80 on my host automatically hits a Also, I'm running in stealth (not allowing icmp echo replies or -- -- Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
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
--
Port 80 Open
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"
--
Port 80 Open
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
--
Port 80 Open
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
Public Key at gopher://kostecke.net or `finger `
--
Port 80 Open
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
--
Port 80 Open
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"
--
Port 80 Open
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
--
Port 80 Open
On 2007-10-28 Telly Williams wrote:
> Ansgar, Paolo, and David,
>
> Thanks for the help.
You're welcome.
> I utilized your ideas and ran nmap and nothing comes up (I did this
> from the same host, though).
Please don't go and interpret the results by yourself if you expect
anyone here to help. Just post what exactly you did, and what the exact
output/result was. Or don't bother posting at all.
> 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"?).
Whether this is good or bad depends on what should or shouldn't be
logged. How would we know? And it has nothing to do with ports that
"can't be seen".
[...]
>> 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?
Wrong.
> I read somewhere that not even ISPs use port forwarding (relaying?).
Everyone running a linux-based firewalling router uses the FORWARD
chain. Which has nothing at all to do with port forwarding, but with IP
forwarding. Those are two entirely different beasts. And relaying is a
horse of yet another different color (the term is frequently used when
referring to accepting and forwarding e-mail).
The FORWARD chain handles packets that are coming from or going to hosts
behind the firewall (e.g. your LAN). The other chains (INPUT, OUTPUT)
handle those packets that are going to or coming from the firewall host
itself (see e.g. [1]). There are quite a few rather good tutorials on
netfilter.org [2] (particularly the packet filtering HOWTO).
>> 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.
Wrong. You want to accept everything ESTABLISHED,RELATED in the OUTPUT
chain, so that every traffic corresponding to traffic you accept in the
INPUT chain is allowed as well. If you want to allow NEW outbound
connections you need to allow those in the OUTPUT chain.
Examples (assuming that the policies are set to DROP):
- If you run a webserver on your host and want to accept incoming
connections you need these rules:
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
The INPUT rule allows incoming connections to your webserver, the
OUTPUT rule allows your webserver's responses to go back to the hosts
establishing the connection.
- If you want to access websites on other servers you need these rules:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
The OUTPUT rule allows outgoing connections to webservers elsewhere,
the INPUT rule allows those webserver's responses to go back to your
browser.
>> 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"?
No, they're not defining "stealth" differently (they coined the term in
the first place). They just fail to understand TCP/IP. Most of Steve
Gibson's works are at least dubious, if not outright nonsense. There
used to be a site pinpointing that, but it's been down for some time
now. You can, however, still read it on archive.org (e.g. [3]).
What they get out of it? Fame, I suppose. Networking is a complex
matter, so there are a lot of people who are easily deceived by smooth-
talkers like Gibson, because they don't understand the matter well
enough to unmask quacks like him.
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
[2] http://www.netfilter.org/documentation/
[3] http://web.archive.org/web/20060405131413/http://grcsucks.com/
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
--
Port 80 Open
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.
--
Port 80 Open
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
--
Port 80 Open
On Sat, Oct 27, 2007 at 04:43:28PM -0600, Telly Williams wrote:
> ports to see what's wrong with it. Only port 80 comes up as
> open, and, apparently, is a security violation.
why?
> 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".
not at all.
> chain checking the tcp packets for syn and state
you want NEW, syn if you want to serve up something on port 80 else ...
> ESTABLISHED,RELATED, the packets being dropped if they don't
... you want just these.
> Also, I'm running in stealth (not allowing icmp echo replies or
eh, not quite stealth
> 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?
perhaps providing a bit more info would help (eg iptables-save, interfaces)
--
paolo
--
Port 80 Open
----- Original Message -----From: Telly Williams <twilliams001@elp.rr.com>Date: Saturday, October 27, 2007 6:43 pmSubject: Port 80 OpenTo: Debian Firewall <debian-firewall@lists.debian.org>> Hi,> > 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.> > 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".> > Anything that comes into port 80 on my host automatically hits a> chain checking the tcp packets for syn and state> ESTABLISHED,RELATED, the packets being dropped if they don't> have those. How can this still be a security violation?> > Also, I'm running in stealth (not allowing icmp echo replies or> 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?> If you're not running a web server, you do not need to have port 80 open inbound at all. You just need to allow outbound packets destined for port 80 on the remote web server. You also need to allow inbound ESTABLISHED/RELATED packets so the remote web server can send data back.Basically, when you connect to a remote web server, your machine picks a random high-number port (usually >30000) and sends packets out that port. The destination of these packets is port 80 on the remote server. When the remote server replies, it sends packets out from its port 80, back to the same random port on your machine. If you set up LOG rules in iptables or use a packet capture program like Wireshark, you can see what I mean. - Dave