, and a great deal of detail needs to be known to
offer more specific advice on encryption. And would you like to use an
encrypted system without fully understanding what was done?
--
Joe
Unsubscribe
Sent from my mobile. Please excuse the brevity, spelling, and punctuation.
Joe Gray, CISSP-ISSMP, GSNA, GCIH
Founder and Chief Nerd
> On Aug 15, 2016, at 9:42 AM, Salvatore Bonaccorso wrote:
>
> Hi Francisco,
>
>> On Mon, Aug 15, 2016 at 03:36:42PM +0200, f
Unsubscribe
Sent from my mobile. Please excuse the brevity, spelling, and punctuation.
> On Aug 6, 2016, at 4:00 PM, Javier Burón wrote:
>
> unsubscribe
>
>> On 6 August 2016 at 20:53, Salvatore Bonaccorso wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> - ---
OT QUITE . fixed in stable [wheezy]
> and "oldstable-LTS" [squeeze-lts]
>
>
> BUT NOT oldstable [squeeze] it is NOT fixed,
> nor is it still supported. :(
>
But just add the right incantations to sources.list and all will be
well.
--
Joe
--
To UNSU
either, the
first, and the second patches:
https://access.redhat.com/articles/1200223
--
Joe
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140927203808.12db7...@jresid.jretrading.com
S
compromises about. As you are comfortable with wireshark, have a look
at the destination IP addresses of DNS lookups, see if they are what you
expect. Man-in-the-middle attacks are harder than DNS server address
substitution.
--
Joe
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.deb
ally possible, perhaps
involving the outright purchase or intimidation of a few hundred humans,
then the largest organised crime syndicates on the planet (a.k.a.
governments) will do it.
--
Joe
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubsc
I'm going to give Jim Drake a ride to Biddeford to pick up his Jeep which
is getting a new windshield. I expect to be home by 6. It it looks like
we are running late I will call.
Thank you,
Joe Bouchard
Factory Automation Engineer
and Unix Support
CSC/P&W North Berwick, Maine
Phone:
to is only a virtual machine,
not shared with anyone else. Chroot is nowhere near enough.
--
Joe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pat wrote:
I apologize if I have offended anyone with my responses. My initial
post was one mentioning
what I saw to be a problem in an attempt to help the community at
large but some persons took offense.
I don't think so. This is merely a lively discussion. A bit of
philosophy which can be
Pat wrote:
Whose responsibility is it, in the US if you manufacture a defective
product legally it is your responsibility if someone is harmed.
There's a bit of a difference between a defective product and one
incorrectly used. When a driver knocks down a pedestrian, should
the car manufac
l see how well it works. These systems are small data
collection appliances, with no proprietary data, and if one of these gets
hijacked we have taken steps to prevent it from spreading, so the
consequences of a vulnerability are rather small. If you have a public web
server, that's a whole 'no
Patrick wrote:
I have an server running sshd on Sarge. I want all users to be able to
access the computer from within the internal network - but restrict
access from the internet (to users in a particular group). Can this be
achieved by combining the /etc/hosts.allow or /etc/hosts.deny files and
x27;s what the sticker `made for Windows XX'
means, they expect it to be rebooted frequently enough so you don't get to that
point." :-)
At any rate, that story bears some similarity to your situation. That's all
I'll say. You might try to find out if your particular NIC has any sort of
limitation like this.
--
Thank you,
Joe Bouchard
Powered by Debian GNU/Linux
x27;s what the sticker `made for Windows XX'
means, they expect it to be rebooted frequently enough so you don't get to that
point." :-)
At any rate, that story bears some similarity to your situation. That's all
I'll say. You might try to find out if your particular NIC
I am not sure the CVE reference is correct for this issue.
Joe
On Sat, 3 Apr 2004, Matt Zimmerman wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> - --
> Debian Security
I am not sure the CVE reference is correct for this issue.
Joe
On Sat, 3 Apr 2004, Matt Zimmerman wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> - --
> Debian Security
d
accounts."
It should also be owned by root, permissions 1555. It is optional to create
zero-length .rhosts, .shosts, .netrc, etc (-r root)
--Joe
* or something compatible with the FHS.
d
accounts."
It should also be owned by root, permissions 1555. It is optional to create
zero-length .rhosts, .shosts, .netrc, etc (-r root)
--Joe
* or something compatible with the FHS.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> >> * A more important consideration is the location of "bin"'s $HOME.
>> >
>> > What's wrong with the current location?
>>
>> At the moment, nothing. Since writ
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> > There was a case of a buggy pam some time ago which let people login
>> > to
>> > accounts such as "man" and "bin". Changing the shell would have
>> > prevented
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> I guess what I'm saying is that there are just as many ways to get
>> access to UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the
>> /etc/passwd. As there are with "bin:x:2:2:bin:/bin:
/etc/shadow) to
determine:
1) what password is acceptable "proof" of the user's identity
2) what userid to set for the new process that is started on the user's
behalf3) in what directory to start the new process that is started on the
user's
behalf
4) what process to start on the user's behalf.
That's it.
--Joe
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> >> * A more important consideration is the location of "bin"'s $HOME.
>> >
>> > What's wrong with the current location?
>>
>> At the moment, nothing. Since writ
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> > There was a case of a buggy pam some time ago which let people login
>> > to
>> > accounts such as "man" and "bin". Changing the shell would have
>> > prevented
Russell Coker said:
> On Thu, 23 Oct 2003 04:02, Joe Moore wrote:
>> I guess what I'm saying is that there are just as many ways to get
>> access to UID2 with "bin:x:2:2:bin:/bin:/bin/false" in the
>> /etc/passwd. As there are with "bin:x:2:2:bin:/bin:
/etc/shadow) to
determine:
1) what password is acceptable "proof" of the user's identity
2) what userid to set for the new process that is started on the user's
behalf3) in what directory to start the new process that is started on the user's
behalf
4) what process to start
to an account, no?
> And again it is a matter of "not granting priveledges where not
> needed".
The /etc/passwd file does not control granting of priveledges[sic]. It
contains a map of UID <-> username <-> Primary GID, a comment field used by
various system utilities and to set some ulimit defaults), and defaults for
certain variables, such as $HOME and $SHELL. See passwd(5).
--Joe
Russell Coker said:
> On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
>> Russell Coker said:
>> > The idea of giving non-login accounts a shell of /bin/false is
>> > hardly new.
>>
>> Out of curiosity, what security benefit does a shell of /bin/false
>&
to an account, no?
> And again it is a matter of "not granting priveledges where not
> needed".
The /etc/passwd file does not control granting of priveledges[sic]. It
contains a map of UID <-> username <-> Primary GID, a comment field used by
various system utilities a
Russell Coker said:
> On Wed, 22 Oct 2003 20:39, Joe Moore wrote:
>> Russell Coker said:
>> > The idea of giving non-login accounts a shell of /bin/false is
>> > hardly new.
>>
>> Out of curiosity, what security benefit does a shell of /bin/false
>&
similar to the discussion last week on "read-only" /usr mounts.
Setting the shell to /bin/false does not change the security character of
the system.
You'd have to be root to run something as user "bin", and if you're root,
you can change "bin"'s sh
similar to the discussion last week on "read-only" /usr mounts.
Setting the shell to /bin/false does not change the security character of
the system.
You'd have to be root to run something as user "bin", and if you're root,
you can change "bin"'s sh
Jamie Heilman wrote:
> Joe Moore wrote:
>> As to your later message:
>> setgroups() and initgroups() are not necessary. Already UID telnetd
>> is able to write to /var/run/utmp because of its membership in GID
>> utmp.
>
> Huh?
Telnetd does not run as root.
Nick Boyce wrote:
> On Thu, 29 Aug 2002 08:37:15 -0600 (MDT), Joe Moore wrote:
>>Another option would be to create a group, for example called
>>"tcpwrap". Add
>>tcpwrap:x:150:telnetd, sshd, irc, identd
>>(This list is based on the users in /etc/passwd which a
irc, identd
(This list is based on the users in /etc/passwd which appear to be for
services that would benefit from tcpwrap. Adjust as appropriate.)
Set /etc/hosts.allow to mod 0640 and ownership root:tcpwrap
When tcpd is running as UID telnetd, it will also have group equivalence to
GID tcpwrap, so it will be able to read /etc/hosts.allow
--Joe
Want to make a million bucks this year?
Me too but it's probably not going happen!
However if your looking for the opportunity to
make a couple thousand a week,
working form home, with your pc, we need to talk.
If you're over 18 and a US resident,
Just Click REPLY
Send me your Name, Stat
one is telnetting in as
root. By default in testing, in.telnetd runs as user "telnetd" (uid 103)
rather than root.
--Joe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
one is telnetting in as
root. By default in testing, in.telnetd runs as user "telnetd" (uid 103)
rather than root.
--Joe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ou to decide that. It's a
long process, and can get very ugly. It comes down to you and what you
want to do.
Use this against script kiddies? It depends on what happened to your
system from them, again, YOUR decision.
Joe Seanor
http://www.cibir.net
--
To UNSUBSCRIBE, email to [EMAIL PROTE
ou to decide that. It's a
long process, and can get very ugly. It comes down to you and what you
want to do.
Use this against script kiddies? It depends on what happened to your
system from them, again, YOUR decision.
Joe Seanor
http://www.cibir.net
--
To UNSUBSCRIBE, email to [EMAIL PROTE
suits are so much easier to handle then trying to get
the Feds interested in attacks against your system. Unless, you have
suffered at least $50,000 worth of damage.
Just my experience, and two cents.
Joe Seanor
http://www.cibir.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
suits are so much easier to handle then trying to get
the Feds interested in attacks against your system. Unless, you have
suffered at least $50,000 worth of damage.
Just my experience, and two cents.
Joe Seanor
http://www.cibir.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
ate
--state ESTABLISHED -j ACCEPT
#iptables -A INPUT -i $IFACE -p udp -s $NAMESERVER_3 --sport 53 -m state
--state ESTABLISHED -j ACCEPT
# Allow UDP packets to DNS servers from client.
#iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_1 --dport 53 -m state
--state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_2 --dport 53 -m state
--state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_3 --dport 53 -m state
--state NEW,ESTABLISHED -j ACCEPT
echo "done"
bash# ./test.firewall
Start Rules
Allow DNS servers incoming traffic...iptables: No chain/target/match by that
name
done
--
Joe Ellis
http://www.lithodyne.net
NPUT -i $IFACE -p udp -s $NAMESERVER_2 --sport 53 -m state
> --state ESTABLISHED -j ACCEPT
> #iptables -A INPUT -i $IFACE -p udp -s $NAMESERVER_3 --sport 53 -m state
> --state ESTABLISHED -j ACCEPT
> # Allow UDP packets to DNS servers from client.
> #iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_1 --dport 53 -m state
> --state NEW,ESTABLISHED -j ACCEPT
> #iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_2 --dport 53 -m state
> --state NEW,ESTABLISHED -j ACCEPT
> #iptables -A OUTPUT -o $IFACE -p udp -d $NAMESERVER_3 --dport 53 -m state
> --state NEW,ESTABLISHED -j ACCEPT
>
> echo "done"
>
> bash# ./test.firewall
> Start Rules
> Allow DNS servers incoming traffic...iptables: No chain/target/match by that
> name
> done
>
>
>
>
>
--
Joe Ellis
http://www.lithodyne.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Notice that security holes fall into classes? One category of hole
should be easy to eliminate from Debian by instituting a code auditing
requirement. I'm referring to insecure creation of temporary files,
allowing for symlink attacks. Now that we all know what this hole looks
like, it should be
Notice that security holes fall into classes? One category of hole
should be easy to eliminate from Debian by instituting a code auditing
requirement. I'm referring to insecure creation of temporary files,
allowing for symlink attacks. Now that we all know what this hole looks
like, it should b
Port 13223 is the PowWow program. More info can be found here:
http://www.robertgraham.com/pubs/firewall-seen.html
Regards,
Joe
Port 13223 is the PowWow program. More info can be found here:
http://www.robertgraham.com/pubs/firewall-seen.html
Regards,
Joe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sn't been added to dpkg's code? I don't
think that it would require a change in the format of .deb
packages. Does anyone have any thoughts on this matter?
-
Joe Dollard
[EMAIL PROTECTED]
50 matches
Mail list logo
