how to protect against peer-to-peer?

how to protect against peer-to-peer?

[Luca Ferrari]

Hi,
in my network users are increasing the amount of peer-to-peer traffic (e-mule, 
winmx), how can I deny the above traffic? I'm using iptables and squid on my 
linux firewall, but I don't know if there's a specific port to lock or 
something else I can use to recognize the "bad" packet in the network 
traffic.

Thanks,
Luca
-- 
Luca Ferrari,
fluca1978@infinito.it

Re: how to protect against peer-to-peer?

[urgrue]

I believe emule uses ports 4661, 4662, 4665, and 4672.
Winmx uses 6699 and 6257. These come from my memory and a quick google
search so they may not be entirely accurate.

You CAN block these ports completely at your firewall BUT:
-people can work around these, the good side is most people dont know how or
dont have the means
-these ports are used by other things too. in general blocking all those
ports will mean that occasionally some connections will try to use these
ports and fail. in general this is not a real problem, but keep it in mind.

google for the ports kazaa uses, its also very popular. 

i have seen many ISPs block these ports, but its "bad practice" in my
opinion. however, if such traffic was clogging up MY network, i wouldnt
hesitate to block them.






On Mon, Nov 22, 2004 at 11:27:53AM +0100, Luca Ferrari wrote:
> Hi,
> in my network users are increasing the amount of peer-to-peer traffic (e-mule, 
> winmx), how can I deny the above traffic? I'm using iptables and squid on my 
> linux firewall, but I don't know if there's a specific port to lock or 
> something else I can use to recognize the "bad" packet in the network 
> traffic.
> 
> Thanks,
> Luca
> -- 
> Luca Ferrari,
> fluca1978@infinito.it
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: how to protect against peer-to-peer?

[Adam Lang]

Two ways to go about it.

First, block ALL outgoing ports and open only those needed to work (port 80
from the Squid machine, etc.)

Second, have management reprimand the people that have these programs
installed on their computers.  If they continue them, management has to take
action.  Also, they should put out a definitive policy on such use first and
then give a "week amnesty period".

The only truly effective way to deal with such programs is through
management.  Put will find out emule isn't so great when it costs them their
jobs.
----- Original Message ----- 
From: "Luca Ferrari" <fluca1978@infinito.it>
To: <linux-admin@vger.kernel.org>
Sent: Monday, November 22, 2004 5:27 AM
Subject: how to protect against peer-to-peer?


> Hi,
> in my network users are increasing the amount of peer-to-peer traffic
(e-mule,
> winmx), how can I deny the above traffic? I'm using iptables and squid on
my
> linux firewall, but I don't know if there's a specific port to lock or
> something else I can use to recognize the "bad" packet in the network
> traffic.
>
> Thanks,
> Luca
> -- 
> Luca Ferrari,
> fluca1978@infinito.it
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: how to protect against peer-to-peer?

[Adrian C.]

This is what i use. It disables torrents, emule, dc++. Kazaa.. don't
know. But this can be used even over port 80 or much simplier over
http tunnel. Be advised that BitComet and Azureus clients use a
different range of ports. You have to look for them yourself. They are
not included here.

--Adrian.

#cutoff emule/torrent
iptables -A FORWARD -p tcp -m multiport --dports
6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT
iptables -A FORWARD -p udp -m multiport --dports
6881,6882,6883,6884,6885,6886,6887,6888,6889,1214 -j REJECT
iptables -A FORWARD -p tcp -m multiport --dports 6346,6347 -j REJECT
iptables -A FORWARD -p udp -m multiport --dports 6346,6347 -j REJECT
iptables -A FORWARD -p tcp -m multiport --dports
4711,4665,4661,4672,4662,8080,9955 -j REJECT
iptables -A FORWARD -p udp -m multiport --dports
4711,4665,4661,4672,4662,8080,9955 -j REJECT
iptables -A FORWARD -p tcp --dport 4242:4299 -j REJECT
iptables -A FORWARD -p udp --dport 4242:4299 -j REJECT
iptables -A FORWARD -p tcp --dport 6881:6999 -j REJECT
iptables -A FORWARD -p udp --dport 6881:6999 -j REJECT



On Mon, 22 Nov 2004 08:39:38 -0500, Adam Lang
<aalang@rutgersinsurance.com> wrote:
> Two ways to go about it.
> 
> First, block ALL outgoing ports and open only those needed to work (port 80
> from the Squid machine, etc.)
> 
> Second, have management reprimand the people that have these programs
> installed on their computers.  If they continue them, management has to take
> action.  Also, they should put out a definitive policy on such use first and
> then give a "week amnesty period".
> 
> The only truly effective way to deal with such programs is through
> management.  Put will find out emule isn't so great when it costs them their
> jobs.
> 
> 
> ----- Original Message -----
> From: "Luca Ferrari" <fluca1978@infinito.it>
> To: <linux-admin@vger.kernel.org>
> Sent: Monday, November 22, 2004 5:27 AM
> Subject: how to protect against peer-to-peer?
> 
> > Hi,
> > in my network users are increasing the amount of peer-to-peer traffic
> (e-mule,
> > winmx), how can I deny the above traffic? I'm using iptables and squid on
> my
> > linux firewall, but I don't know if there's a specific port to lock or
> > something else I can use to recognize the "bad" packet in the network
> > traffic.
> >
> > Thanks,
> > Luca
> > --
> > Luca Ferrari,
> > fluca1978@infinito.it
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: how to protect against peer-to-peer?

[Adrian C.]

One little followup to my previous message.
DC++ uses 411 and 1411 as default. Look for other ports on www.hublist.org.

--Adrian.

RH Ent. 3.0 = no support for firewire HD?

[Eve Atley]

I have been tasked with adding a hot swap drive to our Redhat Linux 9 box as
our backup solution, then upgrading to Linux Enterprise 3.0. I'm researching
how best to format and mount these drives in Redhat 9 before upgrading. Then
I ran across this article:

Using the Granite Digital Firewire Drive Bay with Red Hat Linux
http://www.nber.org/sys-admin/granite-digital-linux.html

..and it states near the bottom,
"(Note added June 13, 2004) I have just "upgraded" our system to Red Hat
Enterprise Linux 3.0, and find that it has no support whatsover for firewire
hard drives. We were able to find some information about adding support at
Dell which seems to work. A recently obtained Fedora does have similar
support to RH9."

Can anyone verify if this is true? (!)

Thanks,
Eve

Best way to enable 'guest' access onto Linux fileserver?

[Eve Atley]

Sorry if my subject is misleading. What I am hoping to do is give 'guest'
access to our 'public' directory (home/shared/public and nothing else) for
consultants who visit us inside the office on a case-by-case basis. This is
to enable consultants to share files across the network when they visit.

Right now, we use Samba credentials (ie. Somebody/password) on our Redhat 9
box, and match their computer logon (Somebody/password) to that so people
don't have to enter a special username/password to connect to our server.
Therefore, all our employees have their own username/password combo on their
computers, as well as their own samba username/password that matches.

So say Joe comes in as a consultant, logged in as joe/computerpassword.
Obviously, when he attempts to access our server, he recieves a prompt
asking him for a username/password, since no joe/computerpassword exists on
our Linux box.

So how would you handle this? By creating a guest/guest account on the Linux
box that allows access to only /home/public, then giving that info to a
consultant on an as-needed basis? Or some other way?

Thanks,
Eve

Re: Best way to enable 'guest' access onto Linux fileserver?

[Grant Coady]

On Tue, 22 Mar 2005 14:49:19 -0500, "Eve Atley" <eatley@wowcorp.com> wrote:

>So how would you handle this? By creating a guest/guest account on the Linux
>box that allows access to only /home/public, then giving that info to a
>consultant on an as-needed basis? Or some other way?

Is the guest read-only access?
Is /home/public also available without physical access? (eg. Internet)

In any case assume consultant rips copy of /home/public/* and took 
it away on their laptop -- how does that make you feel?

Let that guide you how strong the security should be.

"giving that ... as-needed" is security by obscurity?

If it is read-write access then you might need to consider 
what to do with what they've written, each guest sandboxed 
with a copy of /home/public?

So many variables to your query :)

Grant.

Re: Best way to enable 'guest' access onto Linux fileserver?

[Jens Knoell]

Hi Eve

Eve Atley wrote:

>Sorry if my subject is misleading. What I am hoping to do is give 'guest'
>access to our 'public' directory (home/shared/public and nothing else) for
>consultants who visit us inside the office on a case-by-case basis. This is
>to enable consultants to share files across the network when they visit.
>
>Right now, we use Samba credentials (ie. Somebody/password) on our Redhat 9
>box, and match their computer logon (Somebody/password) to that so people
>don't have to enter a special username/password to connect to our server.
>Therefore, all our employees have their own username/password combo on their
>computers, as well as their own samba username/password that matches.
>
>So say Joe comes in as a consultant, logged in as joe/computerpassword.
>Obviously, when he attempts to access our server, he recieves a prompt
>asking him for a username/password, since no joe/computerpassword exists on
>our Linux box.
>
>So how would you handle this? By creating a guest/guest account on the Linux
>box that allows access to only /home/public, then giving that info to a
>consultant on an as-needed basis? Or some other way?
>
>Thanks,
>Eve
>  
>
I think this is what you're looking for:

[everyone]
   comment = Public guest directory
   browseable = yes
   writeable = yes
   path = /home/shared/public
   guest ok = yes
   public = yes
   printable = no
   force create mode = 0777
   force directory mode = 0777
   create mode = 0777
   security mask = 0777

And in the global section:
   map to guest = Bad User

Make sure the permissions for directory /home/shared/public are 0777.

This configuration literally allows everyone to connect with r/w access, 
no matter what username/password they use.

J

RE: Best way to enable 'guest' access onto Linux fileserver?

[Eve Atley]

Thanks everyone who responded to this question. I have tested it, but still
am unable to provide public access, either with or without a password.
Perhaps I have set up something incorrectly. Allow me to present what's
inside the smb.conf file...

[global]
        workgroup = WOWCORP
        netbios name = SERVER
        server string = WOW corp server
        encrypt passwords = Yes
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *New*password* %n\n *Retype*new*password* %n\n
*passwd:*al
l*authentication*tokens*updated*successfully*
        unix password sync = Yes
        log file = /var/log/samba/%m.log
        max log size = 0
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        os level = 70
        dns proxy = No
        hosts allow = 192.168.10. 127.
        printing = lprng
        guest account = samba
        map to guest = Bad User

[home]
        path = /home
        invalid users = root bin linux daemon adm sync shutdown halt mail
news uucp operator
        printable = no
        hide dot files = yes
        hide files = /.*/
        admin user = eve
        writable = yes

[public]
        comment =  Public guest directory
        path = /home/shared/public
        public = yes
        writeable = yes
        browseable = yes
        printable = no
        guest ok = yes
        create mode = 0777
        force create mode = 0777
        force directory mode = 0777
        security mask = 0777
        hide dot files = yes
        hide files = /.*/

Etc.

Re: Best way to enable 'guest' access onto Linux fileserver?

[Jens Knoell]

Eve Atley wrote:

>Thanks everyone who responded to this question. I have tested it, but still
>am unable to provide public access, either with or without a password.
>Perhaps I have set up something incorrectly. Allow me to present what's
>inside the smb.conf file...
>
>[global]
>        workgroup = WOWCORP
>        netbios name = SERVER
>        server string = WOW corp server
>        encrypt passwords = Yes
>        obey pam restrictions = Yes
>        pam password change = Yes
>        passwd program = /usr/bin/passwd %u
>        passwd chat = *New*password* %n\n *Retype*new*password* %n\n
>*passwd:*al
>l*authentication*tokens*updated*successfully*
>        unix password sync = Yes
>        log file = /var/log/samba/%m.log
>        max log size = 0
>        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>        os level = 70
>        dns proxy = No
>        hosts allow = 192.168.10. 127.
>        printing = lprng
>        guest account = samba
>        map to guest = Bad User
>
>[home]
>        path = /home
>        invalid users = root bin linux daemon adm sync shutdown halt mail
>news uucp operator
>        printable = no
>        hide dot files = yes
>        hide files = /.*/
>        admin user = eve
>        writable = yes
>  
>

Which version of samba are you running? If its older than 2.2 you may 
need to add "security = user" to the global section. Also, it may help 
to temporarily set samba to debug mode and see what it tells you when a 
guest connects.

J

Resolved: Best way to enable 'guest' access onto Linux fileserver?

[Eve Atley]

Thanks for everybody's help. For some reason, after coming back over the
holiday weekend, it just worked. Guests are now able to connect.

Thanks!
Eve

-----Original Message-----
From: linux-admin-owner@vger.kernel.org
[mailto:linux-admin-owner@vger.kernel.org] On Behalf Of Jens Knoell
Sent: Wednesday, March 23, 2005 6:02 PM
To: eatley@wowcorp.com
Cc: linux-admin@vger.kernel.org
Subject: Re: Best way to enable 'guest' access onto Linux fileserver?


Eve Atley wrote:

>Thanks everyone who responded to this question. I have tested it, but 
>still am unable to provide public access, either with or without a 
>password. Perhaps I have set up something incorrectly. Allow me to 
>present what's inside the smb.conf file...
>
>[global]
>        workgroup = WOWCORP
>        netbios name = SERVER
>        server string = WOW corp server
>        encrypt passwords = Yes
>        obey pam restrictions = Yes
>        pam password change = Yes
>        passwd program = /usr/bin/passwd %u
>        passwd chat = *New*password* %n\n *Retype*new*password* %n\n 
>*passwd:*al
>l*authentication*tokens*updated*successfully*
>        unix password sync = Yes
>        log file = /var/log/samba/%m.log
>        max log size = 0
>        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
>        os level = 70
>        dns proxy = No
>        hosts allow = 192.168.10. 127.
>        printing = lprng
>        guest account = samba
>        map to guest = Bad User
>
>[home]
>        path = /home
>        invalid users = root bin linux daemon adm sync shutdown halt 
>mail news uucp operator
>        printable = no
>        hide dot files = yes
>        hide files = /.*/
>        admin user = eve
>        writable = yes
>  
>

Which version of samba are you running? If its older than 2.2 you may 
need to add "security = user" to the global section. Also, it may help 
to temporarily set samba to debug mode and see what it tells you when a 
guest connects.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: how to protect against peer-to-peer?

[Jens Knoell]

Luca Ferrari wrote:

>Hi,
>in my network users are increasing the amount of peer-to-peer traffic (e-mule, 
>winmx), how can I deny the above traffic? I'm using iptables and squid on my 
>linux firewall, but I don't know if there's a specific port to lock or 
>something else I can use to recognize the "bad" packet in the network 
>traffic.
>
>Thanks,
>Luca
>  
>
The only sure way to block them is to totally deny inbound connections 
(unless needed for some purpose or another) and restrict outbound 
connections to, say, port 80, 443 (web), depending on your network 
config maybe 25 (smtp), 110 (pop3),  and 53 (DNS).

Personally, I just force everyone through a very restrictive filtering 
proxy and don't allow direct connections at all. Since you do have squid 
on there you can do the same.

The other way, as already mentioned, is a policy change. Here, I gave 
everyone a week to clean up their act, and worked with people to make 
sure their computers are clean. After that... everyone caught 
inappropiately using their machine got fired the same day. Works like a 
charm.

J