Port scan from Apache?

Hi everyone,

today I got an e-mail from a company claiming that my server
is doing 
port scans on their firewall machine. I found that hard to
believe so I 
started checking the box.

The company rep told me that the scan was originating at
port 80 with 
destination port 8254 on their machine. I couldn't find any
hints as to 
why that computer was subject to the alleged port scans.
Searching in 
logs and crontab entries did not reveal the domain name or
IP address of 
the machine except for my web mailer. It seems that someone
from the 
company's network is accessing the web mailer in 10-15
minute intervals 
which is absolutely believable since one of my users works
for the 
company and checks his mail via the web mailer. The strange
part is that 
the company rep said these scans started some time on
Sunday, while my 
user definitely was not using the company's hardware.

Apparently, the company uses NetScreen hardware and/or
software for such 
intrusion detection / prevention mechanisms and the log he
provided read:

[Root]system-alert-00016: Port scan! From $my-server-ip:80
to 
$their-server-ip:8254, proto TCP (zone Untrust, int
ethernet1). Occurred 
1 times.

My questions are:
1. Can this be malicious code on my side? Both port 80 and
443 are bound 
to Apache's httpd so they shouldn't be available to other
processes, right?

2. I'm using ipfw as a firewall where everything is denied
except for a 
rather tight permitting ruleset that (of course) allows
communication 
to/from port 80/443 on my machine but not to the destination
port 8254. 
If the firewall prohibits access to a remote port 8254,
processes on my 
side shouldn't be able to initiate a connection to that
port. If there 
is a connection to that port, it had to be established
earlier by the 
remote machine. Am I correct?

3. Does anyone know when the NetScreen hardware / software
labels 
something "port scan"?

As far as I can tell, the server is free of malicious code,
I especially 
looked for PHP (and similar) files belonging to freely
available port 
scanners etc.; everything seems to be alright. While I was 
investigating, no one but me was logged in.

Any help is greatly appreciated!
Clemens
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On  0, Clemens Renner <claimrinux.net> wrote:
> Hi everyone,
> 
> today I got an e-mail from a company claiming that my
server is doing 
> port scans on their firewall machine. I found that hard
to believe so I 
> started checking the box.
> 
> The company rep told me that the scan was originating
at port 80 with 
> destination port 8254 on their machine. I couldn't
find any hints as to 
> why that computer was subject to the alleged port
scans. Searching in 
> logs and crontab entries did not reveal the domain name
or IP address of 
> the machine except for my web mailer. It seems that
someone from the 
> company's network is accessing the web mailer in 10-15
minute intervals 
> which is absolutely believable since one of my users
works for the 
> company and checks his mail via the web mailer. The
strange part is that 
> the company rep said these scans started some time on
Sunday, while my 
> user definitely was not using the company's hardware.
> 
> Apparently, the company uses NetScreen hardware and/or
software for such 
> intrusion detection / prevention mechanisms and the log
he provided read:
> 
> [Root]system-alert-00016: Port scan! From
$my-server-ip:80 to 
> $their-server-ip:8254, proto TCP (zone Untrust, int
ethernet1). Occurred 
> 1 times.
> 
> My questions are:
> 1. Can this be malicious code on my side? Both port 80
and 443 are bound 
> to Apache's httpd so they shouldn't be available to
other processes, right?
> 
> 2. I'm using ipfw as a firewall where everything is
denied except for a 
> rather tight permitting ruleset that (of course) allows
communication 
> to/from port 80/443 on my machine but not to the
destination port 8254. 
> If the firewall prohibits access to a remote port 8254,
processes on my 
> side shouldn't be able to initiate a connection to
that port. If there 
> is a connection to that port, it had to be established
earlier by the 
> remote machine. Am I correct?
> 
> 3. Does anyone know when the NetScreen hardware /
software labels 
> something "port scan"?
> 
> As far as I can tell, the server is free of malicious
code, I especially 
> looked for PHP (and similar) files belonging to freely
available port 
> scanners etc.; everything seems to be alright. While I
was 
> investigating, no one but me was logged in.
> 
> Any help is greatly appreciated!
> Clemens

Ask them for a packet capture of the incident(s). It may
well be that
they have a false positive case on their hands. Portscan
detection is
very much prone to false positives, many things can appear
to be
portscans when they really aren't.

A log message like the one they gave you is nowhere near
enough
information to determine if the attempt was a real portscan
or not.

+-----------------------------------------------------------
---------+
     Nigel Houghton      Research Engineer       Sourcefire
Inc.
                   Vulnerability Research Team

         There is no theory of evolution, just a list
            of creatures Vin Diesel allows to live.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Clemens Renner wrote:

> Hi everyone,
>
> today I got an e-mail from a company claiming that my
server is doing 
> port scans on their firewall machine. I found that hard
to believe so 
> I started checking the box.
>
> The company rep told me that the scan was originating
at port 80 with 
> destination port 8254 on their machine. I couldn't
find any hints as 
> to why that computer was subject to the alleged port
scans. Searching 
> in logs and crontab entries did not reveal the domain
name or IP 
> address of the machine except for my web mailer. It
seems that someone 
> from the company's network is accessing the web mailer
in 10-15 minute 
> intervals which is absolutely believable since one of
my users works 
> for the company and checks his mail via the web mailer.
The strange 
> part is that the company rep said these scans started
some time on 
> Sunday, while my user definitely was not using the
company's hardware.
>
> Apparently, the company uses NetScreen hardware and/or
software for 
> such intrusion detection / prevention mechanisms and
the log he 
> provided read:
>
> [Root]system-alert-00016: Port scan! From
$my-server-ip:80 to 
> $their-server-ip:8254, proto TCP (zone Untrust, int
ethernet1). 
> Occurred 1 times.



some of their clients accessed your machine a few times and
had 
sequential port numbers on their side.. then netscreen got
confused.
(probably)

on the safe side, run snort on your outside interface for a
while.

>
> My questions are:
> 1. Can this be malicious code on my side? Both port 80
and 443 are 
> bound to Apache's httpd so they shouldn't be
available to other 
> processes, right?
>
> 2. I'm using ipfw as a firewall where everything is
denied except for 
> a rather tight permitting ruleset that (of course)
allows 
> communication to/from port 80/443 on my machine but not
to the 
> destination port 8254. If the firewall prohibits access
to a remote 
> port 8254, processes on my side shouldn't be able to
initiate a 
> connection to that port. If there is a connection to
that port, it had 
> to be established earlier by the remote machine. Am I
correct?
>
> 3. Does anyone know when the NetScreen hardware /
software labels 
> something "port scan"?
>
> As far as I can tell, the server is free of malicious
code, I 
> especially looked for PHP (and similar) files belonging
to freely 
> available port scanners etc.; everything seems to be
alright. While I 
> was investigating, no one but me was logged in.
>
> Any help is greatly appreciated!
> Clemens
> _______________________________________________
> freebsd-securityfreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
> To unsubscribe, send any mail to 
> "freebsd-security-unsubscribefreebsd.org"

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Tuesday, 2006-07-18 at 18:11:50 +0200, Clemens Renner
wrote:

> [Root]system-alert-00016: Port scan! From
$my-server-ip:80 to 
> $their-server-ip:8254, proto TCP (zone Untrust, int
ethernet1). Occurred 
> 1 times.

With IPFilter, I often see "dangling FINs" in
the log. These occur when
the TCP connection has been shut down but an additional FIN
is still
travelling. IPFilter will have abandoned the state for the
connection,
so for it these FIN are not associated to a connection.

Since the message they gave you is of the "Danger,
Will Robinson" kind,
this could be the case. They can't prove it wrong.

To me, this is a case of stupid until proven intelligent.

HTH,
Lupe Christoph

PS: I thought a port scan means somebody is probing many
ports. How can
    one packet be considered a port scan?!?
-- 
| You know we're sitting on four million pounds of fuel,
one nuclear     |
| weapon and a thing that has 270,000 moving parts built by
the lowest   |
| bidder. Makes you feel good, doesn't it?                 
             |
| Rockhound in "Armageddon", 1998, about the
Space Shuttle               |
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Tue, Jul 18, 2006, Clemens Renner wrote:

> today I got an e-mail from a company claiming that my
server is doing 
> port scans on their firewall machine. I found that hard
to believe so I 
> started checking the box.

Do you have mod_proxy or other modules with proxy
functionality in your
web server?

-cs

_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Clemens Renner wrote:
> Hi everyone,
> 
> today I got an e-mail from a company claiming that my
server is doing 
> port scans on their firewall machine. I found that hard
to believe so I 
> started checking the box.
> 
> The company rep told me that the scan was originating
at port 80 with 
> destination port 8254 on their machine. I couldn't
find any hints as to 
> why that computer was subject to the alleged port
scans. Searching in 
> logs and crontab entries did not reveal the domain name
or IP address of 
> the machine except for my web mailer. It seems that
someone from the 
> company's network is accessing the web mailer in 10-15
minute intervals 
> which is absolutely believable since one of my users
works for the 
> company and checks his mail via the web mailer. The
strange part is that 
> the company rep said these scans started some time on
Sunday, while my 
> user definitely was not using the company's hardware.
> 
> Apparently, the company uses NetScreen hardware and/or
software for such 
> intrusion detection / prevention mechanisms and the log
he provided read:

Almost definitely a false alarm.

Firewalls (not just Netscreen) keep track of active TCP
connections 
passing through them.  If they stay idle for too long, the
firewall 
assumes the other end died and drops it from its tracking
table.

Someone behind their firewall viewed your website.  If you
have, say, 6 
images on it, then 7 connections get maintained in the
firewall's state 
table, probably from sequential source port numbers.

If you have Apache's keepalives on, then those 7 HTTP
connections get 
held open for a while in case they request more pages/images
from you.

The problem is when Apache's keepalive interval is longer
than the 
firewall's idle connection retention interval.  If the
firewall is 
configured to forget about idle connections after 5 minutes
and Apache's 
keeping connections alive for 8 minutes, then two minutes
after the 
firewall forgets about it, it will log Apache's attempt to
close the 
connection as a FIN scan from 7 different ports.

Find out what that TCP interval is on their Netscreen and
adjust your 
Apache keepalive to be less than that.  I think we went all
the way down 
to 2 minutes before the dumber firewall admins stopped
emailing us.

This isn't limited to Netscreen either...  Sonicwalls were
overly 
sensitive to this a while back but I think they put out a
firmware 
update to shut up some of the false alarms.  PIX firewalls
tend to have 
longer defaults so you don't run into that as much.

If you're an ISP, every now and then you'll get similar
complaints from 
your customers complaining that your nameserver is attacking
them.  Same 
story -- a slow DNS lookup that takes longer than their
firewall is 
willing to wait on a UDP response, and they assume that
every single 
thing a firewall logs is from an OMG WTF DDOS script
kiddie... 



-- 
Mike Andrews  *  mandrewsbit0.com  *  http://www.bit0.com
It's not news, it's Fark.com.                  Carpe cavy!
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Hi Mike,

thank you for your sympathy and your thorough comments.  I had that

specific feeling when I read the mail for the first time.
I'll try 
reducing the keepalive time to get rid of further
complaints.

The question is: Why do the "port scans" still
come in on their machine? 
Should I advise them to restart their
"we-take-care-don't-you-worry" 
hardware?

Regards
Clemens
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Hello.

The version of a user (behind their firewall) visiting your
site, and
badly configured stateful firewall timeout can be checked:
just look at
the logs of your Apache.
But if it turns out that none of their users had touched
your website at
that time, then I think one more reason is quite possible.
Think of a TCP packet with a source address of a complaining
firewall
and SYN-flag set, but sent to you, Clemens, from some other
guy (just
spoofed src-addr). Sure, your webserver tries to establish
connection
with the source address, which didn't want to establish a
connection.
This version can also be checked - just try to ask them for
details
about packets, that come from you. If they are SYN+ACK, then
this
version becomes more probable. If they have RST, this is
also possible.
This can be done simply: for example, someone was scanning
your ports,
Clemens. And he was doing it from some spoofed source
addresses and his
real one (you wouldn't want to check them all, would you? -
that's why
multiple source addresses are used). And another example -
someone was
just playing  with
HPing, for example 
If this is annoying, it is possible to try to trace the
route of the
packets, that come to you (if they really do) and to their
firewall.


BTW, isn't it impossible for Apache (if it's running from
non-root) to
make connections from his port 80?



Clemens Renner ?????:
> Hi Mike,
>
> thank you for your sympathy and your thorough comments.
 I had
that 
> specific feeling when I read the mail for the first
time. I'll try 
> reducing the keepalive time to get rid of further
complaints.
>
> The question is: Why do the "port scans"
still come in on their 
> machine? Should I advise them to restart their 
> "we-take-care-don't-you-worry" hardware?
>
> Regards
> Clemens
> _______________________________________________
> freebsd-securityfreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
> To unsubscribe, send any mail to 
> "freebsd-security-unsubscribefreebsd.org"
>





-- 
Best regards,
Danil V. Gerun.


_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Danil V. Gerun <danilsochiwater.ru> wrote:
 > BTW, isn't it impossible for Apache (if it's running
from non-root)
 > to make connections from his port 80?

Normally Apache doesn't make connections (unless you use
mod_proxy, and in that case it doesn't use port 80 as the
source port).  It rather accepts connections to its port
80.

However, the process of bind(2)ing to port 80 in order to
accept connections to it is -- by default -- limited to
processes with root privileges.  There are several ways
that can be accomplished without actually running the
Apache server processes as root:

1. Usually you start Apache as root, then it bind(2)s to
   port 80, then it changes its UID to some other, non-
   privileged user (retaining the binding to port 80),
   and then it uses listen(2)/accept(2) to accept connec-
   tions.  That's the default setup, so most people use
   it.

2. You can start Apache as non-root right from the start
   and have it listen to some non-privileged port, e.g.
   8080.  If you don't want to force all users to enter
   that port number in the URLs all the time, you can use
   NAT to rewrite ports, and/or install a local forwarding
   rule (e.g. using IPFW) to forward packets destined for
   port 80 to port 8080.

3. FreeBSD offers the ability to change the range of ports
   that are considered privileged, using two sysctls.  See
   the ip(4) manpage for details (and warnings).  That way
   you can allow non-root processes to bind to ports below
   1024 (e.g. 80), if you're willing to accept the risks.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29,
85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd

Any opinions expressed in this message may be personal to
the author
and may not necessarily reflect the opinions of secnetix in
any way.

"Python is an experiment in how much freedom
programmers need.
Too much freedom and nobody can read another's code; too
little
and expressiveness is endangered."
        -- Guido van Rossum
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Danil V. Gerun <danilsochiwater.ru> wrote:
 > BTW, isn't it impossible for Apache (if it's running
from non-root)
 > to make connections from his port 80?

Normally Apache doesn't make connections (unless you use
mod_proxy, and in that case it doesn't use port 80 as the
source port).  It rather accepts connections to its port
80.

However, the process of bind(2)ing to port 80 in order to
accept connections to it is -- by default -- limited to
processes with root privileges.  There are several ways
that can be accomplished without actually running the
Apache server processes as root:

1. Usually you start Apache as root, then it bind(2)s to
   port 80, then it changes its UID to some other, non-
   privileged user (retaining the binding to port 80),
   and then it uses listen(2)/accept(2) to accept connec-
   tions.  That's the default setup, so most people use
   it.

2. You can start Apache as non-root right from the start
   and have it listen to some non-privileged port, e.g.
   8080.  If you don't want to force all users to enter
   that port number in the URLs all the time, you can use
   NAT to rewrite ports, and/or install a local forwarding
   rule (e.g. using IPFW) to forward packets destined for
   port 80 to port 8080.

3. FreeBSD offers the ability to change the range of ports
   that are considered privileged, using two sysctls.  See
   the ip(4) manpage for details (and warnings).  That way
   you can allow non-root processes to bind to ports below
   1024 (e.g. 80), if you're willing to accept the risks.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29,
85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd

Any opinions expressed in this message may be personal to
the author
and may not necessarily reflect the opinions of secnetix in
any way.

"Python is an experiment in how much freedom
programmers need.
Too much freedom and nobody can read another's code; too
little
and expressiveness is endangered."
        -- Guido van Rossum
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"