How to PREVENT a user from logging in through SSH - SSH

This is a discussion on How to PREVENT a user from logging in through SSH - SSH ; Ignoramus10392 wrote: > On 2008-04-07, David Brown wrote: >> Chris Mattern wrote: >>> On 2008-04-07, Ignoramus10392 wrote: >>>> On 2008-04-07, Keith Keller wrote: >>>>> On 2008-04-07, Ignoramus10392 wrote: >>>>>> I do need from time to time to perform root tasks ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 40 of 40

Thread: How to PREVENT a user from logging in through SSH

  1. Re: How to PREVENT a user from logging in through SSH

    Ignoramus10392 wrote:
    > On 2008-04-07, David Brown wrote:
    >> Chris Mattern wrote:
    >>> On 2008-04-07, Ignoramus10392 wrote:
    >>>> On 2008-04-07, Keith Keller wrote:
    >>>>> On 2008-04-07, Ignoramus10392 wrote:
    >>>>>> I do need from time to time to perform root tasks from scripts, for
    >>>>>> example restarting named after DNS zone files update.
    >>>>> That is what su and sudo are for.
    >>>>>
    >>>>>
    >>>> I thought that both su and sudo require the user to enter a password?
    >>>>
    >>> su does requires the password of the user you are switching to (unless
    >>> you're root already). sudo *normally* requires the password of the
    >>> user who invokes it as a additional security measure but can be
    >>> configured to not require it. I would regard setting up a utility
    >>> account with NOPASSWORD sudo privileges as more secure than letting
    >>> root log directly in via SSH, as you can limit the utility account
    >>> to be able to do as root only the things you list in sudo.
    >>>

    >> The other advantage of doing it this way is that any attacker using
    >> brute-force attacks needs to guess the name of the utility account as
    >> well as the password.
    >>
    >> Other useful tricks for ssh security are to rate-limit the port
    >> (especially on any internet-facing ports) - setting a limit of 3 per
    >> minute with a burst of 3 lets you easily log in, but will ruin brute
    >> force password crackers or denial of service attacks on the port. It
    >> can also be worth putting ssh on a non-standard port - use a high port
    >> number, and maybe have some automatic blacklisting for neighbouring
    >> ports, so that port scans will not catch the open ssh port.

    >
    > I am greatly interested in this ratelimit, what is the setting?
    >
    > I am getting probed, and fingered, a lot, and whatever I can do to
    > limit the chances, I would do.
    >
    > i


    If you are writing your iptables by hand (rather than using some sort of
    firewall/iptables front-end), you might have:

    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 3 -j LOG --log-prefix "SSH ACCEPT "
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 3 -j ACCEPT
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    --limit-burst 10 -j LOG --log-prefix "SSH DROP "
    iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/minute
    --limit-burst 1 -j LOG --log-prefix "SSH FLOODED "
    iptables -A INPUT -p tcp --dport 22 -j DROP

    This setup will log accepted and dropped ssh attempts, but if there are
    too many drops, it will give a "flooded" log message rather than filling
    your log.

    You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
    as having a bucket with space for 5 tokens. A packet will only match
    the rule if it can get a token from the bucket, and the bucket refills
    at the rate of 3 per minute (1 per 20 seconds).


    If you are getting a lot of attempts on port 22, you might want to
    consider using a different port - it's just a matter of specifying "-p
    XXX" on the ssh command line when accessing the server. It's an easy
    trick that will spoil a very large percentage of automated attacks.

    You can also add rules to drop all ssh traffic that does not come from
    specific network addresses if you know what addresses might legitimately
    need access. If users need access from home using dynamic ip addresses,
    it is still possible to restrict access to an ISP's range of dynamic
    addresses.



  2. Re: How to PREVENT a user from logging in through SSH

    On 2008-04-08, David Brown wrote:
    > Ignoramus10392 wrote:
    >> On 2008-04-07, David Brown wrote:
    >>> Chris Mattern wrote:
    >>>> On 2008-04-07, Ignoramus10392 wrote:
    >>>>> On 2008-04-07, Keith Keller wrote:
    >>>>>> On 2008-04-07, Ignoramus10392 wrote:
    >>>>>>> I do need from time to time to perform root tasks from scripts, for
    >>>>>>> example restarting named after DNS zone files update.
    >>>>>> That is what su and sudo are for.
    >>>>>>
    >>>>>>
    >>>>> I thought that both su and sudo require the user to enter a password?
    >>>>>
    >>>> su does requires the password of the user you are switching to (unless
    >>>> you're root already). sudo *normally* requires the password of the
    >>>> user who invokes it as a additional security measure but can be
    >>>> configured to not require it. I would regard setting up a utility
    >>>> account with NOPASSWORD sudo privileges as more secure than letting
    >>>> root log directly in via SSH, as you can limit the utility account
    >>>> to be able to do as root only the things you list in sudo.
    >>>>
    >>> The other advantage of doing it this way is that any attacker using
    >>> brute-force attacks needs to guess the name of the utility account as
    >>> well as the password.
    >>>
    >>> Other useful tricks for ssh security are to rate-limit the port
    >>> (especially on any internet-facing ports) - setting a limit of 3 per
    >>> minute with a burst of 3 lets you easily log in, but will ruin brute
    >>> force password crackers or denial of service attacks on the port. It
    >>> can also be worth putting ssh on a non-standard port - use a high port
    >>> number, and maybe have some automatic blacklisting for neighbouring
    >>> ports, so that port scans will not catch the open ssh port.

    >>
    >> I am greatly interested in this ratelimit, what is the setting?
    >>
    >> I am getting probed, and fingered, a lot, and whatever I can do to
    >> limit the chances, I would do.
    >>
    >> i

    >
    > If you are writing your iptables by hand (rather than using some sort of
    > firewall/iptables front-end), you might have:
    >
    > iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    > iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    > iptables -A INPUT -p tcp --dport 22 -m limit --limit 3/minute
    > iptables -A INPUT -p tcp --dport 22 -m limit --limit 1/minute
    > iptables -A INPUT -p tcp --dport 22 -j DROP
    >
    > This setup will log accepted and dropped ssh attempts, but if there are
    > too many drops, it will give a "flooded" log message rather than filling
    > your log.
    >
    > You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
    > as having a bucket with space for 5 tokens. A packet will only match
    > the rule if it can get a token from the bucket, and the bucket refills
    > at the rate of 3 per minute (1 per 20 seconds).
    >
    >
    > If you are getting a lot of attempts on port 22, you might want to
    > consider using a different port - it's just a matter of specifying "-p
    > XXX" on the ssh command line when accessing the server. It's an easy
    > trick that will spoil a very large percentage of automated attacks.
    >
    > You can also add rules to drop all ssh traffic that does not come from
    > specific network addresses if you know what addresses might legitimately
    > need access. If users need access from home using dynamic ip addresses,
    > it is still possible to restrict access to an ISP's range of dynamic
    > addresses.
    >
    >


    I think that after limiting logon rights to a set of accounts, I am in
    a good shape. These rate limiting rules can easily get me DOSed and
    locked out. (unless the limits are per IP)

    i

  3. Re: How to PREVENT a user from logging in through SSH

    On Tue, 08 Apr 2008 18:10:54 +0200, David Brown wrote:

    > You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
    > as having a bucket with space for 5 tokens. A packet will only match
    > the rule if it can get a token from the bucket, and the bucket refills
    > at the rate of 3 per minute (1 per 20 seconds).


    I've never been clear on the exact meaning of "limit-burst", but I think
    your explanation might have finally crossed my confusion threshold.

    *If* I understand correctly, the idea is that 3/minute is the steady
    state limit. But if the system is sufficiently quiet (ie. no requests
    for the past 40 seconds), up to 5 connections can be permitted within a
    single "instant"? Is that right?

    Thanks...
    Andrew

  4. Re: How to PREVENT a user from logging in through SSH

    In comp.os.linux.misc Unruh wrote:
    > Ignoramus10392 writes:
    >>On 2008-04-07, Peter Ludikovsky wrote:
    >>> Ignoramus10392 wrote:
    >>>> On 2008-04-07, Peter Ludikovsky wrote:
    >>>>> Ignoramus10392 wrote:
    >>>>>> Given prevalence of SSH dictionary attacks, I want to fortify my
    >>>>>> systems a little.


    >>>>>> I have several local (inside the house) users who I do NOT want to be
    >>>>>> able to log on from outside via ssh.


    >>>>>> I would like to disable any remote SSH logins for these users.


    >>>>>> How can I do that?


    >>>>>> thanks
    >>>>> man 5 sshd_config
    >>>>> Look at the AllowUsers / DenyUsers entries


    >>>> Looks great to me. Thanks. I assume that if I say AllowUsers
    >>>> ...,root,... then, on conjunctions with PermitRootLogin
    >>>> without-password the passworded root login will not be allowed.


    >>>> I will try to verify everything.


    >>>> i


    >>> Security-wise it would be better to say "PermitRootLogin no" and
    >>> "su"||"sudo" when needed. Also, setting "PasswordAuthentication no" and
    >>> using Public Key Authentication is a good idea.


    >>> hth
    >>> /peter


    >>Thanks. It worked fine. I have permitrootlogin without-password.


    >>I do need from time to time to perform root tasks from scripts, for
    >>example restarting named after DNS zone files update. I cannot fully
    >>disable root login, though not letting passworded root logins is a
    >>good idea which I already follow.


    > You did not understand him. Disallow root logins. Then you can get in as
    > yourself and then su or sudo to root.


    Also he didn't understand how to configure bind to allow zone
    transfers to happen securely, I fear...

    [..]

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 103: operators on strike due to broken coffee
    machine

  5. Re: How to PREVENT a user from logging in through SSH

    Ignoramus10392 wrote:
    > Given prevalence of SSH dictionary attacks, I want to fortify my
    > systems a little.
    >
    > I have several local (inside the house) users who I do NOT want to be
    > able to log on from outside via ssh.
    >
    > I would like to disable any remote SSH logins for these users.
    >
    > How can I do that?
    >
    > thanks


    Give them a non-usable shell.
    /bin/false or /bin/nologin

  6. Re: How to PREVENT a user from logging in through SSH

    On 2008-04-09, Jurgen Haan wrote:
    > Ignoramus10392 wrote:
    >> Given prevalence of SSH dictionary attacks, I want to fortify my
    >> systems a little.
    >>
    >> I have several local (inside the house) users who I do NOT want to be
    >> able to log on from outside via ssh.
    >>
    >> I would like to disable any remote SSH logins for these users.
    >>
    >> How can I do that?
    >>
    >> thanks

    >
    > Give them a non-usable shell.
    > /bin/false or /bin/nologin


    Um, these users NEED to log in, just not from SSH. They need to log in
    from GDM.

    i

  7. Re: How to PREVENT a user from logging in through SSH

    On 2008-04-09, Ignoramus22864 wrote:
    > On 2008-04-09, Jurgen Haan wrote:
    >> Ignoramus10392 wrote:

    [...]
    >>> I would like to disable any remote SSH logins for these users.

    [...]
    >> Give them a non-usable shell.
    >> /bin/false or /bin/nologin

    >
    > Um, these users NEED to log in, just not from SSH. They need to log in
    > from GDM.


    If you're using OpenSSH, list them in DenyUsers in sshd_config.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

  8. Re: How to PREVENT a user from logging in through SSH

    Andrew Gideon wrote:
    > On Tue, 08 Apr 2008 18:10:54 +0200, David Brown wrote:
    >
    >> You can think of a rule with "-m limit --limit 3/minute --limit-burst 5"
    >> as having a bucket with space for 5 tokens. A packet will only match
    >> the rule if it can get a token from the bucket, and the bucket refills
    >> at the rate of 3 per minute (1 per 20 seconds).

    >
    > I've never been clear on the exact meaning of "limit-burst", but I think
    > your explanation might have finally crossed my confusion threshold.
    >
    > *If* I understand correctly, the idea is that 3/minute is the steady
    > state limit. But if the system is sufficiently quiet (ie. no requests
    > for the past 40 seconds), up to 5 connections can be permitted within a
    > single "instant"? Is that right?
    >


    Yes, that's it. I think a lot of people find it difficult to figure out
    until they can imagine a suitable analogy, and then it "clicks".

  9. Re: How to PREVENT a user from logging in through SSH

    Ignoramus15795 wrote:

    > I think that after limiting logon rights to a set of accounts, I am in
    > a good shape. These rate limiting rules can easily get me DOSed and
    > locked out. (unless the limits are per IP)
    >


    No, the limits are not per IP (it's probably possible to do that using
    iptables - there's modules for all sorts of things). And certainly
    limiting your ssh accounts and their login rights are the most important
    step for securing your ssh. But I don't think the rate limit rules here
    are going to make it more likely to get you locked out by a DOS attack.

    First off, when you are looking at defending against DOS attacks, it's
    important to analyse the risks. Are you actually a likely target for
    such an attack? If you can imagine that someone will have motivation
    for attacking your particular machine (financial motives, revenge, or
    whatever), then you are perhaps at high risk and must plan accordingly.
    For the huge majority of sites, however, there is little risk - a
    cracker will pick *your* site more or less at random, and when his ssh
    cracking effort is failing due to rate limiting, he will simply move on
    to an easier target.

    Secondly, if you *don't* have rate limiting enabled, then a DOS on your
    ssh port will be far worse, since it will consume more resources on your
    system and network - perhaps causing other services to fail as well.

    It is also perfectly possible to avoid the possible problem in at least
    two different ways. If you have a fixed IP address from your remote
    location (such as your home office), then you can simply insert a rule
    ACCEPTing all ssh packets from that address (and if you don't have a
    fixed IP address, and consider your site a high-risk target, then it's
    high time you got such a fixed address. Filtering on IP addresses is
    not full-proof, but it's an easy and cheap way of greatly improving your
    security).

    An alternative method is to have a second server on an independent IP
    address (and perhaps even an independent connection to the Internet)
    which will act as a backdoor server. Obviously this needs to be equally
    secure, but since it is not hosting your website (or other services), it
    is a very unlikely target. This machine should then have privileged
    access to the main server via an independent Ethernet port (which is
    much harder to fake than a privileged source IP address). Then if you
    need to, you can tunnel your ssh to the main server via the backdoor
    server. You could even drop the Internet-facing ssh access to the main
    server altogether - any breakins then need to compromise two machines.

  10. Re: How to PREVENT a user from logging in through SSH

    On 2008-04-10, David Brown wrote:
    > Ignoramus15795 wrote:
    >
    >> I think that after limiting logon rights to a set of accounts, I am in
    >> a good shape. These rate limiting rules can easily get me DOSed and
    >> locked out. (unless the limits are per IP)
    >>

    >
    > No, the limits are not per IP (it's probably possible to do that using
    > iptables - there's modules for all sorts of things). And certainly
    > limiting your ssh accounts and their login rights are the most important
    > step for securing your ssh. But I don't think the rate limit rules here
    > are going to make it more likely to get you locked out by a DOS attack.
    >
    > First off, when you are looking at defending against DOS attacks, it's
    > important to analyse the risks. Are you actually a likely target for
    > such an attack? If you can imagine that someone will have motivation
    > for attacking your particular machine (financial motives, revenge, or
    > whatever), then you are perhaps at high risk and must plan accordingly.
    > For the huge majority of sites, however, there is little risk - a
    > cracker will pick *your* site more or less at random, and when his ssh
    > cracking effort is failing due to rate limiting, he will simply move on
    > to an easier target.


    I can see being a target of a specific person (not that I know of
    anyone, but USENET and all, it is possible). I have a strong server on
    a good network, and it is not easy to bog it down with ssh requests.

    > Secondly, if you *don't* have rate limiting enabled, then a DOS on your
    > ssh port will be far worse, since it will consume more resources on your
    > system and network - perhaps causing other services to fail as well.


    disagree

    > It is also perfectly possible to avoid the possible problem in at least
    > two different ways. If you have a fixed IP address from your remote
    > location (such as your home office), then you can simply insert a rule
    > ACCEPTing all ssh packets from that address (and if you don't have a
    > fixed IP address, and consider your site a high-risk target, then it's
    > high time you got such a fixed address. Filtering on IP addresses is
    > not full-proof, but it's an easy and cheap way of greatly improving your
    > security).
    >
    > An alternative method is to have a second server on an independent IP
    > address (and perhaps even an independent connection to the Internet)
    > which will act as a backdoor server. Obviously this needs to be equally
    > secure, but since it is not hosting your website (or other services), it
    > is a very unlikely target. This machine should then have privileged
    > access to the main server via an independent Ethernet port (which is
    > much harder to fake than a privileged source IP address). Then if you
    > need to, you can tunnel your ssh to the main server via the backdoor
    > server. You could even drop the Internet-facing ssh access to the main
    > server altogether - any breakins then need to compromise two machines.


    I use backdoors a lot in form of SSH tunnels, and this could be a very
    good idea.

    i

  11. Re: How to PREVENT a user from logging in through SSH

    On Thu, 10 Apr 2008 23:34:04 +0200, David Brown wrote:

    > No, the limits are not per IP (it's probably possible to do that using
    > iptables - there's modules for all sorts of things).


    See hashlimit module:

    The idea is to have something like
    ’limit’, but either per destination-ip
    or per (destip,destport) tuple.

    It's pretty flexible.

    - Andrew

  12. Re: How to PREVENT a user from logging in through SSH

    Ignoramus22864 wrote:

    >
    > Um, these users NEED to log in, just not from SSH. They need to log in
    > from GDM.
    >
    > i


    Ah.
    Ok.. not going to bother about the usefulness of that stuff.

    Use groups.
    use DenyGroups in your sshd conf to deny them access.

  13. Re: How to PREVENT a user from logging in through SSH

    Jurgen Haan wrote:
    >
    > Use groups.
    > use DenyGroups in your sshd conf to deny them access.


    rectification:
    Use AllowGroups.
    It's much cleaner.

  14. Re: How to PREVENT a user from logging in through SSH


    On 2008-04-11, Jurgen Haan wrote:
    > Jurgen Haan wrote:
    >>
    >> Use groups.
    >> use DenyGroups in your sshd conf to deny them access.

    >
    > rectification:
    > Use AllowGroups.
    > It's much cleaner.


    I simply use AllowUsers. Does exactly what I want. I am happy. Yes, I
    verified it.

    i

  15. Re: How to PREVENT a user from logging in through SSH

    Ignoramus6985 wrote:
    > On 2008-04-11, Jurgen Haan wrote:
    >> Jurgen Haan wrote:
    >>> Use groups.
    >>> use DenyGroups in your sshd conf to deny them access.

    >> rectification:
    >> Use AllowGroups.
    >> It's much cleaner.

    >
    > I simply use AllowUsers. Does exactly what I want. I am happy. Yes, I
    > verified it.
    >
    > i


    Same principle, with the difference that for every new user, you need to
    change your sshd_config if you want them able to log in through ssh.
    With groups you can just assign the user to the appropriate group.

    But indeed. AllowUsers will do aswell.

    -R-

  16. Re: How to PREVENT a user from logging in through SSH

    On 2008-04-11, Jurgen Haan wrote:
    > Ignoramus6985 wrote:
    >> On 2008-04-11, Jurgen Haan wrote:
    >>> Jurgen Haan wrote:
    >>>> Use groups.
    >>>> use DenyGroups in your sshd conf to deny them access.
    >>> rectification:
    >>> Use AllowGroups.
    >>> It's much cleaner.

    >>
    >> I simply use AllowUsers. Does exactly what I want. I am happy. Yes, I
    >> verified it.
    >>
    >> i

    >
    > Same principle, with the difference that for every new user, you need to
    > change your sshd_config if you want them able to log in through ssh.
    > With groups you can just assign the user to the appropriate group.
    >
    > But indeed. AllowUsers will do aswell.
    >


    Yes, but, I do not get new users often. I have a list of users in a
    "system-night" shell script that sets sshd_config to that list. So
    things are easy to change. I just change the night script and it takes
    care of everything on all my machines.

    i

  17. Re: How to PREVENT a user from logging in through SSH

    David Brown wrote:


    > It is also perfectly possible to avoid the possible problem in at least
    > two different ways. If you have a fixed IP address from your remote
    > location (such as your home office), then you can simply insert a rule
    > ACCEPTing all ssh packets from that address (and if you don't have a
    > fixed IP address, and consider your site a high-risk target, then it's
    > high time you got such a fixed address. Filtering on IP addresses is
    > not full-proof, but it's an easy and cheap way of greatly improving your
    > security).
    >
    > An alternative method is to have a second server on an independent IP
    > address (and perhaps even an independent connection to the Internet)
    > which will act as a backdoor server. Obviously this needs to be equally
    > secure, but since it is not hosting your website (or other services), it
    > is a very unlikely target. This machine should then have privileged
    > access to the main server via an independent Ethernet port (which is
    > much harder to fake than a privileged source IP address).


    are you saying a source mac address is harder to spoof than a source ip?
    if so ... wtf dude they can both be set easily with ifconfig.

  18. Re: How to PREVENT a user from logging in through SSH

    > David Brown wrote:
    >> is a very unlikely target. This machine should then have privileged
    >> access to the main server via an independent Ethernet port (which is
    >> much harder to fake than a privileged source IP address).


    goarilla@work <"kevin DOT paulus AT mtm DOT kuleuven DOT be"> wrote:
    > are you saying a source mac address is harder to spoof than a source ip?


    No, he's saying that if the target machine has two separate
    _physical Ethernet connections_ and is only granting privileged
    access to packets coming in through (say) connection A, it's pretty
    hard for an attacker to arrange for their packets to come in through
    A if their only direct access to the machine is through B and
    there's no other connection between the two networks.

    MAC addresses should be irrelevant to that.
    --
    Simon Tatham "The voices in my head are trying to ignore me.
    But if I keep talking, I can drive them insane."

  19. Re: How to PREVENT a user from logging in through SSH

    Simon Tatham wrote:
    >> David Brown wrote:
    >>> is a very unlikely target. This machine should then have privileged
    >>> access to the main server via an independent Ethernet port (which is
    >>> much harder to fake than a privileged source IP address).

    >
    > goarilla@work <"kevin DOT paulus AT mtm DOT kuleuven DOT be"> wrote:
    >> are you saying a source mac address is harder to spoof than a source ip?

    >
    > No, he's saying that if the target machine has two separate
    > _physical Ethernet connections_ and is only granting privileged
    > access to packets coming in through (say) connection A, it's pretty
    > hard for an attacker to arrange for their packets to come in through
    > A if their only direct access to the machine is through B and
    > there's no other connection between the two networks.
    >
    > MAC addresses should be irrelevant to that.


    Yes, that's what I meant. I don't know for sure that it's impossible to
    fool the target into thinking a packet is coming in on a different
    interface, but it's a lot harder than doing an ifconfig on the source
    machine!

  20. Re: How to PREVENT a user from logging in through SSH

    David Brown wrote:
    > Simon Tatham wrote:
    >>> David Brown wrote:
    >>>> is a very unlikely target. This machine should then have privileged
    >>>> access to the main server via an independent Ethernet port (which is
    >>>> much harder to fake than a privileged source IP address).

    >>
    >> goarilla@work <"kevin DOT paulus AT mtm DOT kuleuven DOT be"> wrote:
    >>> are you saying a source mac address is harder to spoof than a source ip?

    >>
    >> No, he's saying that if the target machine has two separate
    >> _physical Ethernet connections_ and is only granting privileged
    >> access to packets coming in through (say) connection A, it's pretty
    >> hard for an attacker to arrange for their packets to come in through
    >> A if their only direct access to the machine is through B and
    >> there's no other connection between the two networks.
    >>
    >> MAC addresses should be irrelevant to that.

    >
    > Yes, that's what I meant. I don't know for sure that it's impossible to
    > fool the target into thinking a packet is coming in on a different
    > interface, but it's a lot harder than doing an ifconfig on the source
    > machine!


    ok sorry misunderstood
    indeed that would be pretty impossible imho

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2