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?

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
>
-
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?

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"
To:
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?

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
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"
> To:
> 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
>
-
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?

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

--Adrian.
-
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?

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
-
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

RH Ent. 3.0 = no support for firewire HD?

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

-
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

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

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


-
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: Best way to enable "guest" access onto Linux fileserver?

On Tue, 22 Mar 2005 14:49:19 -0500, "Eve Atley" 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.

-
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: Best way to enable "guest" access onto Linux fileserver?

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
-
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: Best way to enable "guest" access onto Linux fileserver?

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.

-
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: 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

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

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

-
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