REGISTER  


Port 80 Open
This thread belongs to expert.forumgeeks.net


2007-10-27 19:50 GMT   |   #1
 
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?
2007-10-27 20:40 GMT   |   #2
 
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)

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.
2007-10-27 21:20 GMT   |   #3
 
I got from the check at grc.com. that leaving port 80 open is a security violation.

What do you mean by not quite stealth? Ansgar said the same thing. Now I'm
feeling like a dummy.
And no I don't provide SMTP and HTTPS , but I now understand what you're saying.

Here is the output of iptables-save:
# 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.
2007-10-27 21:20 GMT   |   #4
 
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.

Telly Williams wrote:
....
> -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


  -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.
2007-10-28 22:40 GMT   |   #5
 
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"?

Thanks for the suggestions.
2007-10-29 05:00 GMT   |   #6
 
  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? Wink
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)' Wink

  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.
2007-10-29 07:40 GMT   |   #7
 
Hello,

  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 ?

  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.


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.

  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.
2007-10-29 07:40 GMT   |   #8
 
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.

  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

  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.