MAC addresses

MAC addresses

[Darren Kirby]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Hello netfilter list,

I have a fairly good knowledge of iptables etc...but there is one point I 
would like some clarification on.

This is from the iptables tutorial located here:
http://iptables-tutorial.frozentux.net

"6.4.3.2. MAC match
The MAC (Ethernet Media Access Control) match can be used to match packets 
based on their MAC source address. As of writing this documentation, this 
match is a little bit limited, however, in the future this may be more 
evolved and may be more useful. This match can be used to match packets on 
the source MAC address only as previously said"

Are MAC addresses unique for all ethernet cards? What I would like to know is 
could I use this rule to allow ssh connections ONLY from my notebook no 
matter what its current IP address happens to be, and drop all other 
connection requests?

Thanks for any insight...

-d

-- 
Part of the problem since 1976
http://badcomputer.no-ip.com
Get my public key from 
http://keyserver.linux.it/pks/lookup?op=index&search=bulliver
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: MAC addresses

[active]

On "Sat 11 of September 2004" Darren Kirby wrote:

> Are MAC addresses unique for all ethernet cards? What I would like to
> know is could I use this rule to allow ssh connections ONLY from my
> notebook no matter what its current IP address happens to be, and drop
> all other connection requests?

Yes. MAC addresses are set in the card by the manufacturer. This is a
good method to control input traffic.

For more info: http://www.webopedia.com/TERM/M/MAC_address.html

Re: MAC addresses

[Frank Gruellich]

* Darren Kirby <bulliver@badcomputer.no-ip.com> 11. Sep 04:
> Hello netfilter list,

Hi,

> "6.4.3.2. MAC match
> 
> Are MAC addresses unique for all ethernet cards?

Beside some broken cards: yes.

> What I would like to know is could I use this rule to allow ssh
> connections ONLY from my notebook no matter what its current IP
> address happens to be, and drop all other connection requests?

If your notebook is in the same network: yes.  AFAIK you get the MAC
from the next hop.  BTW: MACs can be changed.  You still need a good
password.

HTH,
 regards, Frank.
-- 
Sigmentation fault

Re: MAC addresses

[Jason Opperisano]

On Sat, 2004-09-11 at 14:50, Darren Kirby wrote:
> Are MAC addresses unique for all ethernet cards? 

theoretically, yes.

> What I would like to know is 
> could I use this rule to allow ssh connections ONLY from my notebook no 
> matter what its current IP address happens to be, and drop all other 
> connection requests?

yes--as long as "notebook" and "ssh server" are on the same network.

keep in mind--nothing prevents "badguy" from configuring his NIC to have
the same MAC as your "notebook"

if you're worried about security of "ssh server"--disable
PasswordAuthentication and only allow RSAAuthentication and/or
PubkeyAuthentication.

stealing your IP and MAC is much more likely than someone stealing your
private key (hopefully).

you could also create a reservation for your MAC in the DHCP server, and
filter based upon your (now) fixed IP.

-j

-- 
Jason Opperisano <opie@817west.com>

Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

Hi Group:

I've tested for open ports from all the LAN clients behind my linux
box router/gateway/firewall and all of them come up with the same
results: port 21, 23, and 80 are open according to the results of the
Steve Gibson Shields Up test.

I can't figure out how this can be happening.
I've run a full nmap -P0 (that's a zero) on all my local ip addresses
- 192.168.169.*

You'll see below that the only ports open according to nmap on all the
clients is Port 139.  This is appropriate as the box on 192.168.169.2
is running a Samba server that all the clients connect to.

The box on 192.168.169.2 has Port 80 open because I run Apache as an
intranet webserver.  It cannot be accessed from outside the firewall. 
Port 631 is open because that's the port that receives print jobs via
the CUPS printserver.  The LAN clients send print jobs to the
printserver via port 631.  Lastly, I had the X window system up and
running when I ran nmap so you can see a port open for that.

But none of the clients, nor the gateway address on the routerbox
(192.168.169.1) show port 21, 23, and 80 as open.

So, I'm left with some questions:

A) Is the Gibson test accurate or am I misunderstanding the results?
B) Do I need to do another kind of diagnostic test using nmap?

Thank you for reading the long post.
I appreciate the time and help.

Mike

                                                                      
                                                                      
                                                                      
                                          Starting nmap 3.55 (
http://www.insecure.org/nmap/ ) at 2004-09-09 10:21 EDT
All 1660 scanned ports on 192.168.169.0 are: filtered

All 1660 scanned ports on 192.168.169.1 are: filtered

Interesting ports on primary.us (192.168.169.2):
(The 1655 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
80/tcp   open  http
139/tcp  open  netbios-ssn
631/tcp  open  ipp
6000/tcp open  X11

Interesting ports on 192.168.169.3:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXX (Intel)

Interesting ports on 192.168.169.4:
(The 1658 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
135/tcp open  msrpc
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXX (3com)

Interesting ports on 192.168.169.5:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXXX (Netgear)

Interesting ports on 192.168.169.6:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXX (The Linksys Group)

Interesting ports on 192.168.169.7:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXX (3com)

All 1660 scanned ports on 192.168.169.8 are: filtered

Interesting ports on 192.168.169.9:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXX (Hsing TECH. Enterprise CO.)

Interesting ports on 192.168.169.10:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXXX (Hsing TECH. Enterprise CO.)

All 1660 scanned ports on 192.168.169.11 are: filtered

All 1660 scanned ports on 192.168.169.12 are: filtered

Interesting ports on 192.168.169.13:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXX (Micro-star International CO.)

Interesting ports on 192.168.169.14:
(The 1658 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
135/tcp open  msrpc
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXXXX (The Linksys Group)

Interesting ports on 192.168.169.15:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXX (Intel - Hf1-06)

Interesting ports on 192.168.169.16:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXX (Micro-star International CO.)

Interesting ports on 192.168.169.17:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXX (Micro-star International CO.)

Interesting ports on 192.168.169.18:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXXXXXXX (Micro-star International CO.)

Interesting ports on 192.168.169.19:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXX (Micro-star International CO.)

Interesting ports on 192.168.169.20:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXXXXX (Micro-star International CO.)

All 1660 scanned ports on 192.168.169.21 are: filtered

Interesting ports on 192.168.169.22:
(The 1659 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
139/tcp open  netbios-ssn
MAC Address: XXXXXXXXXXXX (Micro-star International CO.)

All 1660 scanned ports on 192.168.169.23 are: filtered

All 1660 scanned ports on 192.168.169.24 are: filtered

-----------<<<snip>>>-------------------------

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[George Alexandru Dragoi]

Maybe insecure.org has theyr own 192.168.0.0 private LAN :)


On Sat, 11 Sep 2004 19:09:11 -0400, Mike <1100100@gmail.com> wrote:
> Hi Group:
> 
> I've tested for open ports from all the LAN clients behind my linux
> box router/gateway/firewall and all of them come up with the same
> results: port 21, 23, and 80 are open according to the results of the
> Steve Gibson Shields Up test.
> 
> I can't figure out how this can be happening.
> I've run a full nmap -P0 (that's a zero) on all my local ip addresses
> - 192.168.169.*
> 
> You'll see below that the only ports open according to nmap on all the
> clients is Port 139.  This is appropriate as the box on 192.168.169.2
> is running a Samba server that all the clients connect to.
> 
> The box on 192.168.169.2 has Port 80 open because I run Apache as an
> intranet webserver.  It cannot be accessed from outside the firewall.
> Port 631 is open because that's the port that receives print jobs via
> the CUPS printserver.  The LAN clients send print jobs to the
> printserver via port 631.  Lastly, I had the X window system up and
> running when I ran nmap so you can see a port open for that.
> 
> But none of the clients, nor the gateway address on the routerbox
> (192.168.169.1) show port 21, 23, and 80 as open.
> 
> So, I'm left with some questions:
> 
> A) Is the Gibson test accurate or am I misunderstanding the results?
> B) Do I need to do another kind of diagnostic test using nmap?
> 
> Thank you for reading the long post.
> I appreciate the time and help.
> 
> Mike
> 
>                                           Starting nmap 3.55 (
> http://www.insecure.org/nmap/ ) at 2004-09-09 10:21 EDT
> All 1660 scanned ports on 192.168.169.0 are: filtered
> 
> All 1660 scanned ports on 192.168.169.1 are: filtered
> 
> Interesting ports on primary.us (192.168.169.2):
> (The 1655 ports scanned but not shown below are in state: closed)
> PORT     STATE SERVICE
> 80/tcp   open  http
> 139/tcp  open  netbios-ssn
> 631/tcp  open  ipp
> 6000/tcp open  X11
> 
> Interesting ports on 192.168.169.3:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXX (Intel)
> 
> Interesting ports on 192.168.169.4:
> (The 1658 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 135/tcp open  msrpc
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXX (3com)
> 
> Interesting ports on 192.168.169.5:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXXX (Netgear)
> 
> Interesting ports on 192.168.169.6:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXX (The Linksys Group)
> 
> Interesting ports on 192.168.169.7:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXX (3com)
> 
> All 1660 scanned ports on 192.168.169.8 are: filtered
> 
> Interesting ports on 192.168.169.9:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXX (Hsing TECH. Enterprise CO.)
> 
> Interesting ports on 192.168.169.10:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXXX (Hsing TECH. Enterprise CO.)
> 
> All 1660 scanned ports on 192.168.169.11 are: filtered
> 
> All 1660 scanned ports on 192.168.169.12 are: filtered
> 
> Interesting ports on 192.168.169.13:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXX (Micro-star International CO.)
> 
> Interesting ports on 192.168.169.14:
> (The 1658 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 135/tcp open  msrpc
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXXXX (The Linksys Group)
> 
> Interesting ports on 192.168.169.15:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXX (Intel - Hf1-06)
> 
> Interesting ports on 192.168.169.16:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXX (Micro-star International CO.)
> 
> Interesting ports on 192.168.169.17:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXX (Micro-star International CO.)
> 
> Interesting ports on 192.168.169.18:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXXXXXXX (Micro-star International CO.)
> 
> Interesting ports on 192.168.169.19:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXX (Micro-star International CO.)
> 
> Interesting ports on 192.168.169.20:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXXXXX (Micro-star International CO.)
> 
> All 1660 scanned ports on 192.168.169.21 are: filtered
> 
> Interesting ports on 192.168.169.22:
> (The 1659 ports scanned but not shown below are in state: closed)
> PORT    STATE SERVICE
> 139/tcp open  netbios-ssn
> MAC Address: XXXXXXXXXXXX (Micro-star International CO.)
> 
> All 1660 scanned ports on 192.168.169.23 are: filtered
> 
> All 1660 scanned ports on 192.168.169.24 are: filtered
> 
> -----------<<<snip>>>-------------------------
> 
> 



-- 
Bla bla

Re: MAC addresses

[Darren Kirby]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

quoth the Jason Opperisano:
> > What I would like to know is
> > could I use this rule to allow ssh connections ONLY from my notebook no
> > matter what its current IP address happens to be, and drop all other
> > connection requests?
>
> yes--as long as "notebook" and "ssh server" are on the same network.

I guess that won't look for what I want then, perhaps I can explain better: I 
already have ssh access for the notebook from the private interface of the 
server inside the LAN. The server accepts incoming www and smtp connections 
on the public interface, everything else is dropped. What I would like is ssh 
access from the public side, ie, the internet. This is so I could check my 
mail and update my website if I was on the road, from say,  web cafe's or 
somesuch where the IP address would change frequently.

> keep in mind--nothing prevents "badguy" from configuring his NIC to have
> the same MAC as your "notebook"

Good advice, and point taken.

> if you're worried about security of "ssh server"--disable
> PasswordAuthentication and only allow RSAAuthentication and/or
> PubkeyAuthentication.

I will look into this. I assume however that I would need to keep port 23 open 
for everyone on the public side for this to work. I was hoping to drop the 
packets from everyone except my notebook, hence the original question. Is 
there no way to do this?

Thanks Jason and Frank for taking the time to answer my questions,
-d
-- 
Part of the problem since 1976
http://badcomputer.no-ip.com
Get my public key from 
http://keyserver.linux.it/pks/lookup?op=index&search=bulliver
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: MAC addresses

[Jason Opperisano]

On Sat, 2004-09-11 at 20:26, Darren Kirby wrote:
> I will look into this. I assume however that I would need to keep port 23 open 
> for everyone on the public side for this to work. I was hoping to drop the 
> packets from everyone except my notebook, hence the original question. Is 
> there no way to do this?

if you're looking for a secure way to manage your firewall from the
internet without allowing "-s 0/0 --dport 22" type access; you probably
want to setup some sort of VPN access for yourself.

openvpn ( http://openvpn.sourceforge.net/ ) is a very nice option for
this.

-j

-- 
Jason Opperisano <opie@817west.com>

Re: MAC addresses

[Darren Kirby]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

quoth the Jason Opperisano:
> On Sat, 2004-09-11 at 20:26, Darren Kirby wrote:
> > I will look into this. I assume however that I would need to keep port 23
> > open for everyone on the public side for this to work. I was hoping to
> > drop the packets from everyone except my notebook, hence the original
> > question. Is there no way to do this?
>
> if you're looking for a secure way to manage your firewall from the
> internet without allowing "-s 0/0 --dport 22" type access; you probably
> want to setup some sort of VPN access for yourself.
>
> openvpn ( http://openvpn.sourceforge.net/ ) is a very nice option for
> this.
>
> -j

Looks like just the ticket...thanks again,
-d
-- 
Part of the problem since 1976
http://badcomputer.no-ip.com
Get my public key from 
http://keyserver.linux.it/pks/lookup?op=index&search=bulliver
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: MAC addresses

[Chris Brenton]

On Sat, 2004-09-11 at 20:54, Jason Opperisano wrote:
>
> On Sat, 2004-09-11 at 20:26, Darren Kirby wrote:
> > I will look into this. I assume however that I would need to keep port 23 open 
> > for everyone on the public side for this to work. I was hoping to drop the 
> > packets from everyone except my notebook, hence the original question. Is 
> > there no way to do this?
> 
> if you're looking for a secure way to manage your firewall from the
> internet without allowing "-s 0/0 --dport 22" type access; you probably
> want to setup some sort of VPN access for yourself.

A VPN is probably overkill as SSH is already a VPN (strong built in
authentication and encryption. Heck, I'll take Blowfish over 3DES or AES
for privacy any day of the week :). Two other options come to mind:

1) Bind SSH to a non-standard port
Yes someone doing a full port scan can still find it, blah, blah, blah.
I've been running this for years and have yet to receive a single
non-authorized connect to the port that has actually performed an SSH
handshake.

2) Setup port knocking
http://www.linuxjournal.com/article.php?sid=6811
I know a few people that have set this up with great success. Sure its
vulnerable to replay, but since we're talking SSH that's not really a
problem. Great way to expose ports to only certain users.

So with either option you still want to use public/private keys or
strong passwords with SSH. They are designed to simply mask the service
from all the SSH scanning that's running around the Internet.

HTH,
Chris

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

I don't understand this response.

On Sun, 12 Sep 2004 02:14:58 +0300, George Alexandru Dragoi
<waruiinu@gmail.com> wrote:
> Maybe insecure.org has theyr own 192.168.0.0 private LAN :)

Re: MAC addresses

[Darren Kirby]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

quoth the Chris Brenton:
>
> A VPN is probably overkill as SSH is already a VPN (strong built in
> authentication and encryption. Heck, I'll take Blowfish over 3DES or AES
> for privacy any day of the week :). Two other options come to mind:
>
> 1) Bind SSH to a non-standard port
> Yes someone doing a full port scan can still find it, blah, blah, blah.
> I've been running this for years and have yet to receive a single
> non-authorized connect to the port that has actually performed an SSH
> handshake.
>
> 2) Setup port knocking
> http://www.linuxjournal.com/article.php?sid=6811
> I know a few people that have set this up with great success. Sure its
> vulnerable to replay, but since we're talking SSH that's not really a
> problem. Great way to expose ports to only certain users.
>
> So with either option you still want to use public/private keys or
> strong passwords with SSH. They are designed to simply mask the service
> from all the SSH scanning that's running around the Internet.
>
> HTH,
> Chris

Port knocking is some serious black magic. This is very interesting, and seems 
to be ideal for me, because I only need this access for short periods (1-2 
weeks) a couple times a year.

Thanks very much for the tip,
-d

-- 
Part of the problem since 1976
http://badcomputer.no-ip.com
Get my public key from 
http://keyserver.linux.it/pks/lookup?op=index&search=bulliver
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[George Alexandru Dragoi]

Ok, I was tired :)
I thought the Gibson stuff is some sort of web page used to scan, so i
thought you scanned 192.168.0.0/24 from some webpage, that's why my
answer (i was even worse tired, i thought that page is located at
insecure.org, that was actually the result of nmap output). I am
curious how that test explain the manner HOW the ports are opened.
Maybe they are just not filtered.

On Sun, 12 Sep 2004 03:38:48 -0400, Mike <1100100@gmail.com> wrote:
> I don't understand this response.
> 
> 
> 
> On Sun, 12 Sep 2004 02:14:58 +0300, George Alexandru Dragoi
> <waruiinu@gmail.com> wrote:
> > Maybe insecure.org has theyr own 192.168.0.0 private LAN :)
> 



-- 
Bla bla

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

Hi George,

I'm trying to figure this out as well.  The shields up results state,
"one or more of your system's ports actively responded to our
deliberate attempts to establish a connection." I'm trying to figure
out what the active response was and what it means.

I think I'll have to hit up one of the grc.com mailing lists.

Mike 

On Mon, 13 Sep 2004 04:15:22 +0300, George Alexandru Dragoi
<waruiinu@gmail.com> wrote:
> I am
> curious how that test explain the manner HOW the ports are opened.
> Maybe they are just not filtered.
> 
>

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Jason Opperisano]

On Sat, 2004-09-11 at 19:09, Mike wrote:
> Hi Group:
> 
> I've tested for open ports from all the LAN clients behind my linux
> box router/gateway/firewall and all of them come up with the same
> results: port 21, 23, and 80 are open according to the results of the
> Steve Gibson Shields Up test.
> 
> I can't figure out how this can be happening.
> I've run a full nmap -P0 (that's a zero) on all my local ip addresses
> - 192.168.169.*

you need to keep in mind that if your netfilter box is performing
MASQ/SNAT for your LAN machines--the IP being scanned by grc.com is the
public IP of the netfilter box.

unless your doing some DNATs to machines on your LAN--you should focus
your efforts on the netfilter machine itself.

"netstat -lntu" would be a good place to start.

i've always questioned the output of web-based scanners like grc.com;
however, i just went to grc.com and tried it out, and achieved a
*perfect* "TruStealth" rating...which must mean i'm super l33t like
stevie...  :-P

-j

-- 
Jason Opperisano <opie@817west.com>

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

Hi J,

Thanks for the guidance.
There's definitely no DNATing/PREROUTING currently set up in the
iptables firewall.  So, I guess the only thing that could explain port
21 and/or 23 is there must be an ftp daemon using those ports.

As for port 80, I wonder if it's got anything to do with Apache
running the intranet webserver inside the LAN.  I don't believe I've
got apache even installed on the routerbox.

Well, enough guessing.  I'll try some netstat research and see what
percolates to the surface.

Best regards.

Mike


On Mon, 13 Sep 2004 08:53:07 -0400, Jason Opperisano <opie@817west.com> wrote:
> 
> you need to keep in mind that if your netfilter box is performing
> MASQ/SNAT for your LAN machines--the IP being scanned by grc.com is the
> public IP of the netfilter box.
> 
> unless your doing some DNATs to machines on your LAN--you should focus
> your efforts on the netfilter machine itself.
> 
> "netstat -lntu" would be a good place to start.
> 
> i've always questioned the output of web-based scanners like grc.com;
> however, i just went to grc.com and tried it out, and achieved a
> *perfect* "TruStealth" rating...which must mean i'm super l33t like
> stevie...  :-P
> 
> -j
> 
> --
> Jason Opperisano <opie@817west.com>
> 
>

Re: MAC addresses

[Jose Maria Lopez]

El sáb, 11 de 09 de 2004 a las 22:01, active escribió:
> On "Sat 11 of September 2004" Darren Kirby wrote:
> 
> > Are MAC addresses unique for all ethernet cards? What I would like to
> > know is could I use this rule to allow ssh connections ONLY from my
> > notebook no matter what its current IP address happens to be, and drop
> > all other connection requests?
> 
> Yes. MAC addresses are set in the card by the manufacturer. This is a
> good method to control input traffic.
> 
> For more info: http://www.webopedia.com/TERM/M/MAC_address.html

But have in mind that some operating systems let you change the
MAC address of the card. By example, Linux let you do that, and
that can fool some kinds of traffic control.


-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: MAC addresses

[srg]

Also, note that if a router exits between your ssh clientS and your ssh 
server then ALL ssh incoming connections from different clients will be 
seen with the same source mac addr of the router (of course, each of the 
connections will have different src ip (if NO nat is done in the router)).

Jose Maria Lopez wrote:

>El sáb, 11 de 09 de 2004 a las 22:01, active escribió:
>  
>
>>On "Sat 11 of September 2004" Darren Kirby wrote:
>>
>>    
>>
>>>Are MAC addresses unique for all ethernet cards? What I would like to
>>>know is could I use this rule to allow ssh connections ONLY from my
>>>notebook no matter what its current IP address happens to be, and drop
>>>all other connection requests?
>>>      
>>>
>>Yes. MAC addresses are set in the card by the manufacturer. This is a
>>good method to control input traffic.
>>
>>For more info: http://www.webopedia.com/TERM/M/MAC_address.html
>>    
>>
>
>But have in mind that some operating systems let you change the
>MAC address of the card. By example, Linux let you do that, and
>that can fool some kinds of traffic control.
>
>
>  
>

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[James B. Hiller]

Hi.

> On Sat, 2004-09-11 at 19:09, Mike wrote:
> > Hi Group:
> > 
> > I've tested for open ports from all the LAN clients behind my linux
> > box router/gateway/firewall and all of them come up with the same
> > results: port 21, 23, and 80 are open according to the results of the
> > Steve Gibson Shields Up test.
> > 
> > I can't figure out how this can be happening.
> > I've run a full nmap -P0 (that's a zero) on all my local ip addresses
> > - 192.168.169.*
> 
> you need to keep in mind that if your netfilter box is performing
> MASQ/SNAT for your LAN machines--the IP being scanned by grc.com is the
> public IP of the netfilter box.
> 
> unless your doing some DNATs to machines on your LAN--you should focus
> your efforts on the netfilter machine itself.
> 
> "netstat -lntu" would be a good place to start.
> 
> i've always questioned the output of web-based scanners like grc.com;
> however, i just went to grc.com and tried it out, and achieved a
> *perfect* "TruStealth" rating...which must mean i'm super l33t like
> stevie...  :-P

For whatever it may be worth:  I have linux 2.6.0 running on my firewall
machine, and 2.6.9-rc1 running on a machine behind it, and I get (and
have always gotten) a *perfect* TruStealth result relative to both
machines.

jbh

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

Hi James,

Thanks for your reply, but I'm fairly certain this is not a kernel issue.


On Mon, 13 Sep 2004 17:22:01 -0400 (EDT), James B. Hiller
<jhiller@visi.net> wrote:
> Hi.
> 
> 
> 
> > On Sat, 2004-09-11 at 19:09, Mike wrote:
> > > Hi Group:
> > >
> > > I've tested for open ports from all the LAN clients behind my linux
> > > box router/gateway/firewall and all of them come up with the same
> > > results: port 21, 23, and 80 are open according to the results of the
> > > Steve Gibson Shields Up test.
> > >
> > > I can't figure out how this can be happening.
> > > I've run a full nmap -P0 (that's a zero) on all my local ip addresses
> > > - 192.168.169.*
> >
> > you need to keep in mind that if your netfilter box is performing
> > MASQ/SNAT for your LAN machines--the IP being scanned by grc.com is the
> > public IP of the netfilter box.
> >
> > unless your doing some DNATs to machines on your LAN--you should focus
> > your efforts on the netfilter machine itself.
> >
> > "netstat -lntu" would be a good place to start.
> >
> > i've always questioned the output of web-based scanners like grc.com;
> > however, i just went to grc.com and tried it out, and achieved a
> > *perfect* "TruStealth" rating...which must mean i'm super l33t like
> > stevie...  :-P
> 
> For whatever it may be worth:  I have linux 2.6.0 running on my firewall
> machine, and 2.6.9-rc1 running on a machine behind it, and I get (and
> have always gotten) a *perfect* TruStealth result relative to both
> machines.
> 
> jbh
> 
>

Re: <SOLVED>Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

This is pretty embarassing but I will go ahead and post it so that it
is forever archived under the "silly noobs on routers" directory.

1.  I've been too lazy to get the roaring penguin dsl client working
on my routerbox.  Historically, I've had trouble with making the right
data packet sizes and providing headroom for packet headers, etc.

2.  So, I'm still using a simple $50 Netgear cable/dsl router to act
as my LAN's DHCP server.

3.  The LAN diagram looks like:  Internet --> Netgear Router --> Linux
firewall/router/gateway --> LAN clients.

4.  A while back I needed to set up some video conferencing for my
boss.  I wanted to make sure there were no issues with the Netgear
router so I simply turned it into a DMZ that let everything through to
the Linux routerbox.

5.  Forgetful as I am, I modified the linux firewall back to its
original state once the video conferencing was completed, but never
turned off the DMZ settings on the Netgear router.  That was the
entire problem.  The netgear was responding and opening ports as it is
designed to do while set on DMZ.

Long story, short.  I tested the linux box on its own with no Netgear
in front of it, and then also tested it with the Netgear set up as the
DHCP server, but no longer set up as a DMZ.  Both tests yielded
results of complete stealth.

Where's the beer.

Mike

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Nick Drage]

On Mon, Sep 13, 2004 at 08:35:53AM -0400, Mike wrote:
> Hi George,
> 
> I'm trying to figure this out as well.  The shields up results state,
> "one or more of your system's ports actively responded to our
> deliberate attempts to establish a connection." I'm trying to figure
> out what the active response was and what it means.

Which ports?

-- 
mors omnia vincit

Re: Port 21, 23, and 80 are open according to Shields Up at grc.com

[Mike]

SOLVED.

This is pretty embarassing but I will go ahead and post it so that it
is forever archived under the "silly noobs on routers" directory.

1.  I've been too lazy to get the roaring penguin dsl client working
on my routerbox.  Historically, I've had trouble with making the right
data packet sizes and providing headroom for packet headers, etc.

2.  So, I'm still using a simple $50 Netgear cable/dsl router to act
as my LAN's DHCP server.

3.  The LAN diagram looks like:  Internet --> Netgear Router --> Linux
firewall/router/gateway --> LAN clients.

4.  A while back I needed to set up some video conferencing for my
boss.  I wanted to make sure there were no issues with the Netgear
router so I simply turned it into a DMZ that let everything through to
the Linux routerbox.

5.  Forgetful as I am, I modified the linux firewall back to its
original state once the video conferencing was completed, but never
turned off the DMZ settings on the Netgear router.  That was the
entire problem.  The netgear was responding and opening ports as it is
designed to do while set on DMZ.

Long story, short.  I tested the linux box on its own with no Netgear
in front of it, and then also tested it with the Netgear set up as the
DHCP server, but no longer set up as a DMZ.  Both tests yielded
results of complete stealth.

Where's the beer.

Mike