Paul M Foster wrote:
>
> On Tue, May 15, 2001 at 06:02:10PM -0400, Derek Glidden wrote:
>
> <snip>
>
> > Of course, to effectively use nmap or
> > nessus, you need an offsite system from which to run the scans, which
> > makes it a little less convenient for people with home DSL connections
> > just trying to check their security.
>
> Aside from ipchains/firewall rules, it appears to me that servers don't
> really make a distinction between LAN and internet when it comes to
> ports and services. For example, if you run sendmail on your firewall
> (ignoring firewall rules again), your firewall server doesn't really
> know/care whether port 25 packets come from the LAN or the internet.
> Correct me if I'm wrong here.
Yes and no. See below.
> But if that's the case, would it be worthwhile to run nmap and the
> others from inside your LAN, pointed at your firewall?
>
> The reason I ask is because I have one of those "inconvenient" home DSL
> connections.
Generally speaking, your firewall will (should) have different rules
depending on which "side" of the firewall you are. For a firewall to be
effective, it needs two interfaces: one that faces the inside, protected
network, and one that faces the outside world. Rules will usually apply
to one or the other interface, but rarely both.
Now if you have a server behind that firewall that you want to test for
security, yeah you can easily run nmap or nessus against it and have the
same result just about no matter from where you are scanning. You
*will* probably have different results if you attempt to scan the box
from itself, though, since some services just listen on the loopback
device.
Most services don't bind to a specific address or interface on a
machine, which means that stuff like sendmail in your example, will
listen to port 25 on any interface and any address for which the machine
has been configured, unless you have specified otherwise to that
daemon. However, your firewall rules should be set up to distinguish
whether or not to allow traffic to that service based on from what
source interface and address the traffic is coming. So if you want to
scan your firewall for vulnerable services, you can do it from either
side, but if your firewall is properly set up, you _should not_ get the
same results as to what ports are open and what's listening if you scan
it from the inside as from the outside. If you do, then your firewall
is probably not properly configured!
For example, if you are using your firewall machine as your sendmail
smarthost to relay mail to the outside world, (which is actually a
little silly, in a very strict security sense, since your firewall
shouldn't be doing anything but firewalling. of course, I do understand
that not everyone has spare machine just sitting around to just be a
firewall.) you certainly want to be able to hit port 25 from the inside
network, but you absolutely do _not_ want to be able to hit port 25 from
the outside world! Similarly, ports that you want to allow through from
the protected side of the network should respond to scans from the
inside, but you almost surely do not want those same ports allowing
connections from the outside.
At home, I allow all traffic into my firewall from addresses on my
protected network, as long as they come in through the inside interface;
traffic from any other address on the inside interface, and all traffic
to the outside interface is denied. So scanning my home firewall from
the inside will show a few services listening and available. Scanning
it from outside shows nothing.
The reason I bring up tools like nmap and nessus is that, while Gibson
Research's "Shields Up" website probably does something very similar to
an nmap scan, since you don't have access to the tool itself, you really
can't tell _exactly_ what it's doing. For all you can tell, it might
just be scanning for ports 137, 138, 139, which are the NetBIOS ports on
which all Windows boxes communicate. So on a Linux box, if you're not
running Samba, of course it's going to report that your machine is
"stealthed" and not responding to scans.
And, well, no offense meant, because the guy is clearly very smart, but
Steve Gibson is also something of a loon, and there's no way of telling
what he really _thinks_ he's accomplishing as opposed to what he is in
fact. :)
Since attacks against your home machine are very much more likely to
originate from the outside interface (unless you really irritate someone
at home, like for example, put up a big argument about going to get some
milk) you really should be performing your scans from an "outside
perspective" to understand what an attacker will see.
Although lately, it's not even such a big deal to know your machine
won't present any available services for a potential attacker to try to
exploit, since a lot of the new script-kiddie attacks don't even scan a
system before attempting an exploit. They just go at it regardless and
if it fails, it moves on to the next system. (Even the world of script
kiddies is succumbing to an utter lack of taste nowadays.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/ http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:53:40 EDT