Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #265064 > unrolled thread

Help: network abuse

Started byAlain D D Williams <addw@phcomp.co.uk>
First post2023-12-21 13:20 +0100
Last post2023-12-24 09:20 +0100
Articles 9 on this page of 29 — 15 participants

Back to article view | Back to linux.debian.user

Contents

  Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 13:20 +0100
    Re: Help: network abuse Tim Woodall <debianuser@woodall.me.uk> - 2023-12-21 13:50 +0100
      Re: Help: network abuse <tomas@tuxteam.de> - 2023-12-21 16:00 +0100
      Re: Help: network abuse gene heskett <gheskett@shentel.net> - 2023-12-21 21:10 +0100
    Re: Help: network abuse Dan Purgert <dan@djph.net> - 2023-12-21 13:50 +0100
    Re: Help: network abuse Greg Wooledge <greg@wooledge.org> - 2023-12-21 14:00 +0100
      Re: Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 14:20 +0100
        Re: Help: network abuse Andy Smith <andy@strugglers.net> - 2023-12-21 14:50 +0100
          Re: Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 16:00 +0100
            Re: Help: network abuse Pocket <pocket@columbus.rr.com> - 2023-12-21 16:20 +0100
              Re: Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 16:30 +0100
                Re: Help: network abuse Pocket <pocket@columbus.rr.com> - 2023-12-21 16:40 +0100
                  Re: Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 17:00 +0100
                    Re: Help: network abuse Jeffrey Walton <noloader@gmail.com> - 2023-12-21 17:10 +0100
                    Re: Help: network abuse Pocket <pocket@columbus.rr.com> - 2023-12-21 17:50 +0100
                      Re: Help: network abuse Alain D D Williams <addw@phcomp.co.uk> - 2023-12-21 19:10 +0100
                        Re: Help: network abuse Pocket <pocket@columbus.rr.com> - 2023-12-21 19:10 +0100
                Re: Help: network abuse debian-user@howorth.org.uk - 2023-12-21 19:20 +0100
              Re: Help: network abuse Peter Hillier-Brook <phb@hbsys.plus.com> - 2023-12-21 19:20 +0100
        Re: Help: network abuse Michel Verdier <mv524@free.fr> - 2023-12-21 15:50 +0100
    Re: Help: network abuse David Christensen <dpchrist@holgerdanske.com> - 2023-12-21 23:30 +0100
      Re: Help: network abuse Tim Woodall <debianuser@woodall.me.uk> - 2023-12-23 10:30 +0100
        Re: Help: network abuse David Christensen <dpchrist@holgerdanske.com> - 2023-12-23 20:00 +0100
          Re: Help: network abuse Tim Woodall <debianuser@woodall.me.uk> - 2023-12-23 23:00 +0100
            Re: Help: network abuse Pocket <pocket@columbus.rr.com> - 2023-12-23 23:30 +0100
          Re: Help: network abuse Dan Ritter <dsr@randomstring.org> - 2023-12-24 01:40 +0100
            Re: Help: network abuse David Christensen <dpchrist@holgerdanske.com> - 2023-12-24 04:00 +0100
          Re: Help: network abuse Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2023-12-24 07:20 +0100
            Re: Help: network abuse David Christensen <dpchrist@holgerdanske.com> - 2023-12-24 09:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#265123

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2023-12-21 23:30 +0100
Message-ID<HNzId-fb2a-5@gated-at.bofh.it>
In reply to#265064
On 12/21/23 04:00, Alain D D Williams wrote:
> My home PC is receiving, for hours at a time, 12-30 kB/s input traffic. This is
> unsolicited. I do not know what it is trying to achieve but suspect no good. It
> is also eating my broadband allowance.
> 
> This does not show up in the Apache log files - the TCP connection does not succeed.
> 
> Sometimes my machine does send a packet in reply, there are 2 examples at the
> foot of this email.
> 
> Questions:
> 
> • What is going on ?
> 
> • What can I do about it ?
>    I do manually add some of the IPs to the f2b chain which will stop replies
>    but that is about it.
> 
> My ISP refuses to do anything about it - I admit that I cannot see what they
> could do, maybe filter packets with a source port of 80 or 443.
> 
> I also get attempts to break into ssh (port 22) - I am not worried about that.
> 
> I append a few lines of output of "tcpdump -n -i enp3s0" done today.
> 192.168.108.2 is the address of my desktop PC.
> 
> The connecting IPs below all belong to Amazon but this changes with time, China
> is another common source of similar packets.
> 
> 11:08:56.354303 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 19070976, win 51894, options [mss 1401,sackOK,TS val 1182532729 ecr 0,nop,wscale 7], length 0
> 11:08:56.354700 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 3665362944, win 51894, options [mss 1402,sackOK,TS val 4179952761 ecr 0,nop,wscale 7], length 0
> 11:08:56.360527 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 479395840, win 51894, options [mss 1412,sackOK,TS val 3391683448 ecr 0,nop,wscale 7], length 0
> 11:08:56.360696 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 1622147072, win 51894, options [mss 1410,sackOK,TS val 2887711608 ecr 0,nop,wscale 7], length 0
> 11:08:56.360950 IP 54.184.78.87.80 > 192.168.108.2.80: Flags [S], seq 3168796672, win 51894, options [mss 1404,sackOK,TS val 535364985 ecr 0,nop,wscale 7], length 0
> 11:08:56.364565 IP 52.195.179.12.80 > 192.168.108.2.80: Flags [S], seq 132317184, win 51894, options [mss 1407,sackOK,TS val 2350122105 ecr 0,nop,wscale 7], length 0
> 11:08:56.364708 IP 34.217.144.104.80 > 192.168.108.2.80: Flags [S], seq 1098776576, win 51894, options [mss 1405,sackOK,TS val 3426157689 ecr 0,nop,wscale 7], length 0
> 11:08:56.367975 IP 13.231.232.88.80 > 192.168.108.2.80: Flags [S], seq 3272540160, win 51894, options [mss 1413,sackOK,TS val 979961209 ecr 0,nop,wscale 7], length 0
> 
> 2 days ago a similar capture. Note that the source port is 443 not 80:
> 
> 09:47:31.416452 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 2724200448, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 7], length 0
> 09:47:31.417861 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 925237248, win 51894, options [mss 1407,sackOK,TS val 756418658 ecr 0,nop,wscale 7], length 0
> 09:47:31.440892 IP 27.124.10.197.443 > 192.168.108.2.80: Flags [S], seq 3474063360, win 51894, options [mss 1404,sackOK,TS val 3970828642 ecr 0,nop,wscale 7], length 0
> 09:47:31.449393 IP 27.124.10.200.443 > 192.168.108.2.80: Flags [S], seq 2844721152, win 51894, options [mss 1407,sackOK,TS val 1831471202 ecr 0,nop,wscale 7], length 0
> 09:47:31.451430 IP 154.39.104.67.443 > 192.168.108.2.80: Flags [S], seq 2336358400, win 51894, options [mss 1415,sackOK,TS val 395513698 ecr 0,nop,wscale 7], length 0
> 09:47:31.451610 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 808976384, win 51894, options [mss 1414,sackOK,TS val 1960250978 ecr 0,nop,wscale 7], length 0
> 09:47:31.453372 IP 143.92.60.30.443 > 192.168.108.2.80: Flags [S], seq 3177512960, win 51894, options [mss 1408,sackOK,TS val 4033677410 ecr 0,nop,wscale 7], length 0
> 09:47:31.456937 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 1042087936, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 7], length 0
> 09:47:31.461961 IP 27.124.10.226.443 > 192.168.108.2.80: Flags [S], seq 3200516096, win 51894, options [mss 1403,sackOK,TS val 2314013026 ecr 0,nop,wscale 7], length 0
> 
> Examples where my machine sends a reply:
> 
> 09:47:31.658790 IP 27.124.10.225.443 > 192.168.108.2.80: Flags [S], seq 612564992, win 51894, options [mss 1415,sackOK,TS val 2011106914 ecr 0,nop,wscale 7], length 0
> 09:47:31.659442 IP 192.168.108.2.80 > 154.39.104.67.443: Flags [S.], seq 3770299450, ack 1858732033, win 65160, options [mss 1460,sackOK,TS val 164888251 ecr 395513698,nop,wscale 7], length 0
> 
> 09:47:31.756220 IP 5.45.73.147.443 > 192.168.108.2.80: Flags [S], seq 2992898048, win 51894, options [mss 1401,sackOK,TS val 862439534 ecr 0,nop,wscale 7], length 0
> 09:47:31.756272 IP 192.168.108.2.80 > 5.45.73.147.443: Flags [.], ack 1226309633, win 509, options [nop,nop,TS val 2085784149 ecr 994101358], length 0


On 12/21/23 05:10, Alain D D Williams wrote:
 > ... I do run a web server at home, but there is only a little/personal
 > stuff, it does not receive much real traffic, I do not want it to.
 > Most of my web presence is hosted elsewhere.


On 12/21/23 06:58, Alain D D Williams wrote:
 > I have been with my ISP for 14 years (moved to get IPv6), for various
 > reasons I cannot change to a tariff that will give me [more bandwidth]
 > (their support has also fallen through the floor) - I need to change
 > (& the landline) and then I prolly would not care [about probe
 > bandwidth consumption].


On 12/21/23 06:58, Alain D D Williams wrote:
 > They might be trying to hijack an existing TCP connection or, even
 > simpler, cause my machine problems by having many, many 1/2 set up TCP
 > connections (which uses memory until they expire).


On 12/21/23 07:24, Alain D D Williams wrote:
 > ... I have [a firewall].
 >
 > The issue is broadband usage - ie before it hits the firewall.


On 12/21/23 07:50, Alain D D Williams wrote:
 > I am looking at incoming packets with tcpdump. This sees packets
 > *before* they are filtered by iptables.

 > [My firewall is] hand rolled. Reasonably complicated (over 300 rules)
 > as it deals with: internet, VPN, DMZ, internal network for virtual
 > machines.
 >
 > It is NOT a firewall issue.

 > My firewall *cannot* deal with packets before they hit my machine.
 > They only hit my machine after they have arrived over broadband.
 >
 > The only thing that I might be able to do is to somehow prevent
 > discovery that my machine is listening on port 80 -- that would mean
 > somehow distinguishing between a genuine visitor and one that is
 > mapping the Internet to later pass that map somewhere else which
 > generates the unwanted traffic that I see.

 > How do I distinguish between wanted & unwanted connections. The only
 > thing that I can think of is to DROP incoming packets if the source
 > port is 80 or 443 - which would disrupt the mapping process.
 >
 > However: if the mapping process uses normal TCP (ie high/random port
 > number) this would do little.


On 12/21/23 10:04, Alain D D Williams wrote:
 > The words "web server" is ambiguous. It can mean my machine, ie can me
 > the Apache process. The packets are hitting the machine (evidence
 > tcpdump) but not the process (as the TCP startup does not complete).


Some of the lines of tcpdump(8) output may indicate a SYN flood attack:

https://en.wikipedia.org/wiki/Syn_flood


It sounds like your Internet connection is VDSL over POTS?  Do you have 
a residential gateway device with the modem, a few (4?) Ethernet LAN 
ports, Wi-Fi access point, a switch, DHCP server, NAT, router, firewall, 
etc..?  If not, please describe the device that connects your home to 
the Internet and how it is connected to your Debian home PC.


Perhaps you could set up a DMZ, move services into the DMZ,  and provide 
a VPN connection to the DMZ for your Internet users.  Then you could 
close all of the incoming WAN ports except VPN.


It might be possible to put the VPN endpoint into a VPS, create an SSH 
tunnel out from the httpd server to the VPS, and close all of the WAN 
incoming ports.


David

[toc] | [prev] | [next] | [standalone]

#265185

FromTim Woodall <debianuser@woodall.me.uk>
Date2023-12-23 10:30 +0100
Message-ID<HO6ut-fySn-9@gated-at.bofh.it>
In reply to#265123
On Thu, 21 Dec 2023, David Christensen wrote:

>
> Perhaps you could set up a DMZ, move services into the DMZ,  and provide a 
> VPN connection to the DMZ for your Internet users.  Then you could close all 
> of the incoming WAN ports except VPN.
>
>
> It might be possible to put the VPN endpoint into a VPS, create an SSH tunnel 
> out from the httpd server to the VPS, and close all of the WAN incoming 
> ports.
>

If the OP is worried about the bandwidth usage then none of that will
help. The fact that the OP is not sending a SYN+ACK (according to the
tcpdumps that I saw) means that this is already blackholed.[2]

There are three options at this point:
1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my iptables
rules and drops without logging before anything else.

2. Talk to their ISP and get it blocked there - that's the only surefire
way to stop it eating their quota if that's the problem.

3. Try and make them give up - that's why I suggested sending a RST.


[1] I have a set of rules that blacklist IPs that send too many SYN
packets that are not responded to with SYN+ACK.

[2] This did look weird. I'm not sure how only some connections get a
SYN+ACK back - I wonder if their webserver is rate-limited and these are
"genuine" connection attempts that are failing - although the SPT=80
DPT=80 looks suspiciously like something crafted to get through naive
stateless firewall rules that rely on outgoing (allowed) connections to
have DPT=80 to the internet and SPT=80 from the internet.

[toc] | [prev] | [next] | [standalone]

#265211

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2023-12-23 20:00 +0100
Message-ID<HOfo5-fE1x-5@gated-at.bofh.it>
In reply to#265185
On 12/23/23 01:29, Tim Woodall wrote:
> The fact that the OP is not sending a SYN+ACK (according to the
> tcpdumps that I saw) means that this is already blackholed.[2]
> 
> There are three options at this point:
> 1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my iptables
> rules and drops without logging before anything else.
> 
> 2. Talk to their ISP and get it blocked there - that's the only surefire
> way to stop it eating their quota if that's the problem.
> 
> 3. Try and make them give up - that's why I suggested sending a RST.
> 
> 
> [1] I have a set of rules that blacklist IPs that send too many SYN
> packets that are not responded to with SYN+ACK.
> 
> [2] This did look weird. I'm not sure how only some connections get a
> SYN+ACK back - I wonder if their webserver is rate-limited and these are
> "genuine" connection attempts that are failing - although the SPT=80
> DPT=80 looks suspiciously like something crafted to get through naive
> stateless firewall rules that rely on outgoing (allowed) connections to
> have DPT=80 to the internet and SPT=80 from the internet.


Thank you for your comments and explanations.


Your [1] and [2] make me think of fail2ban(1).  Any similarities?


STFW I found some informative articles:

https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/14760-4.html

https://heimdalsecurity.com/blog/syn-flood/


Sending a RST to a falsified IP address would make the sending host into 
an attacker by proxy.  Why do you suggest it?


Does Debian and/or Linux support SYN cookies?


I believe Debian includes packages for various intrusion detection 
systems.  Does anyone have any comments or recommendations?


Analyzing and correlating iptables and httpd logs should provide a 
better understanding of legitimate traffic versus attacker traffic.  We 
would need matching excerpts from the OP to try it.


David

[toc] | [prev] | [next] | [standalone]

#265214

FromTim Woodall <debianuser@woodall.me.uk>
Date2023-12-23 23:00 +0100
Message-ID<HOich-fFFz-1@gated-at.bofh.it>
In reply to#265211
On Sat, 23 Dec 2023, David Christensen wrote:
> Sending a RST to a falsified IP address would make the sending host into an 
> attacker by proxy.  Why do you suggest it?
>
Because the OP wants it to stop. And the OP is running a server on this
port that is clearly not responding properly or we'd at least see the
syn+ack. Perhaps it cannot keep up with the connections.

So the op needs to tell the problem clients to stop retrying.

If it's malicious traffic then there's nothing the op can do to stop it
except get a new ip or get their ISP to drop it before it gets to them.

The op can try icmp port unreachable too. But that tells the client
there's no server, rather than there's a tcp problem.

If it's not a bandwidth problem then the op should just ignore it.

Nobody, but nobody is going to send traffic to some random host with a
fake source ip in the hopes someone will notice and start sending RST
some tine later to that address instead of continuing to drop it.

[toc] | [prev] | [next] | [standalone]

#265216

FromPocket <pocket@columbus.rr.com>
Date2023-12-23 23:30 +0100
Message-ID<HOiFk-fG4x-15@gated-at.bofh.it>
In reply to#265214

Sent from my iPhone

> On Dec 23, 2023, at 4:53 PM, Tim Woodall <debianuser@woodall.me.uk> wrote:
> 
> On Sat, 23 Dec 2023, David Christensen wrote:
>> Sending a RST to a falsified IP address would make the sending host into an attacker by proxy.  Why do you suggest it?
>> 
> Because the OP wants it to stop. And the OP is running a server on this
> port that is clearly not responding properly or we'd at least see the
> syn+ack. Perhaps it cannot keep up with the connections.
> 
> So the op needs to tell the problem clients to stop retrying.
> 
> If it's malicious traffic then there's nothing the op can do to stop it
> except get a new ip or get their ISP to drop it before it gets to them.
> 
> The op can try icmp port unreachable too. But that tells the client
> there's no server, rather than there's a tcp problem.
> 
> If it's not a bandwidth problem then the op should just ignore it.
> 
> Nobody, but nobody is going to send traffic to some random host with a
> fake source ip in the hopes someone will notice and start sending RST
> some tine later to that address instead of continuing to drop it.
> 

I have a web server on my network. 
I have a firewall on it that only accepts traffic from my internal network.  Therefore no knows it exists from the outside.  That may not work for the op,  but his complaint was port 80 traffic to his personal pc.  Which should not have a web server running on it.  
You can not do much about scans etc but you can restrict traffic to servers only to your internal traffic.   That was my one of my points in stating his firewall wasn’t setup properly,  the other is  the firewall blocking icmp and conpany.  I use to do that many years ago and it resulting in 1/2 connections.

[toc] | [prev] | [next] | [standalone]

#265220

FromDan Ritter <dsr@randomstring.org>
Date2023-12-24 01:40 +0100
Message-ID<HOkH7-fHdo-3@gated-at.bofh.it>
In reply to#265211
David Christensen wrote: 
> Does Debian and/or Linux support SYN cookies?

Yes.

Put

net.ipv4.tcp_syncookies=1

in an appropriate sysctl.d/ file.

To check on current settings:

sysctl -n net.ipv4.tcp_syncookies

[toc] | [prev] | [next] | [standalone]

#265226

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2023-12-24 04:00 +0100
Message-ID<HOmSB-fIos-1@gated-at.bofh.it>
In reply to#265220
On 12/23/23 16:15, Dan Ritter wrote:
> David Christensen wrote:
>> Does Debian and/or Linux support SYN cookies?
> 
> Yes.
> 
> Put
> 
> net.ipv4.tcp_syncookies=1
> 
> in an appropriate sysctl.d/ file.
> 
> To check on current settings:
> 
> sysctl -n net.ipv4.tcp_syncookies


It looks like SYN cookies are enabled by default since 
debian-11.6.0-amd64-netinst (what I installed and have since tried to 
keep up to date):

2023-12-23 18:51:24 root@taz ~
# cat /etc/debian_version ; uname -a
11.8
Linux taz 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 
GNU/Linux

2023-12-23 18:51:57 root@taz ~
# sysctl -n net.ipv4.tcp_syncookies
1


Thank you for the incantations.  :-)


David

[toc] | [prev] | [next] | [standalone]

#265227

FromTimothy M Butterworth <timothy.m.butterworth@gmail.com>
Date2023-12-24 07:20 +0100
Message-ID<HOq09-fKF9-1@gated-at.bofh.it>
In reply to#265211

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 23, 2023 at 8:58 PM David Christensen <dpchrist@holgerdanske.com>
wrote:

> On 12/23/23 01:29, Tim Woodall wrote:
> > The fact that the OP is not sending a SYN+ACK (according to the
> > tcpdumps that I saw) means that this is already blackholed.[2]
> >
> > There are three options at this point:
> > 1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my
> iptables
> > rules and drops without logging before anything else.
> >
> > 2. Talk to their ISP and get it blocked there - that's the only surefire
> > way to stop it eating their quota if that's the problem.
> >
> > 3. Try and make them give up - that's why I suggested sending a RST.
> >
> >
> > [1] I have a set of rules that blacklist IPs that send too many SYN
> > packets that are not responded to with SYN+ACK.
> >
> > [2] This did look weird. I'm not sure how only some connections get a
> > SYN+ACK back - I wonder if their webserver is rate-limited and these are
> > "genuine" connection attempts that are failing - although the SPT=80
> > DPT=80 looks suspiciously like something crafted to get through naive
> > stateless firewall rules that rely on outgoing (allowed) connections to
> > have DPT=80 to the internet and SPT=80 from the internet.
>
>
> Thank you for your comments and explanations.
>
>
> Your [1] and [2] make me think of fail2ban(1).  Any similarities?
>
>
> STFW I found some informative articles:
>
> https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/14760-4.html
>
> https://heimdalsecurity.com/blog/syn-flood/
>
>
> Sending a RST to a falsified IP address would make the sending host into
> an attacker by proxy.  Why do you suggest it?
>
>
> Does Debian and/or Linux support SYN cookies?
>
>
> I believe Debian includes packages for various intrusion detection
> systems.  Does anyone have any comments or recommendations?
>

Debian has SNORT and Suricata. I use Suricata. It works well and does not
require paying the subscription for the SNORT oink account.

sudo apt install suricata suricata-update

You can configure Suricata via /etc/suricata/suricata.yaml. All that really
needs configured for a basic IDS/IPS is to change the interfaces from Eth0
to the actual interface. After that you can enable and start Suricata via
SystemD.



> Analyzing and correlating iptables and httpd logs should provide a
> better understanding of legitimate traffic versus attacker traffic.  We
> would need matching excerpts from the OP to try it.
>
>
> David
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[toc] | [prev] | [next] | [standalone]

#265232

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2023-12-24 09:20 +0100
Message-ID<HOrSi-fLWK-5@gated-at.bofh.it>
In reply to#265227
On 12/23/23 22:16, Timothy M Butterworth wrote:
> On Sat, Dec 23, 2023 at 8:58 PM David Christensen wrote:
>> I believe Debian includes packages for various intrusion detection
>> systems.  Does anyone have any comments or recommendations?
> 
> Debian has SNORT and Suricata. I use Suricata. It works well and does not
> require paying the subscription for the SNORT oink account.
> 
> sudo apt install suricata suricata-update
> 
> You can configure Suricata via /etc/suricata/suricata.yaml. All that really
> needs configured for a basic IDS/IPS is to change the interfaces from Eth0
> to the actual interface. After that you can enable and start Suricata via
> SystemD.


Thank you.  :-)


David

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web