Not TCP protocol prerouting: in:lte1 out

frank333 · Fri Apr 28, 2023 7:57 pm

i have an rbm11g with ROS 7.8 stable and an LTE module . in the log file i get about 10 messages a day with this wording:

Not TCP protocol prerouting: in:lte1 out:(unknown 0), connection-state:invalid src-mac c6:e0:42:92:21:52, proto 132, 39.98.186.94->151.15.109.102, len 52

I checked the firewall settings and they all seem to be correct.What do you think it could be ?

log.png

mkx · Fri Apr 28, 2023 9:44 pm

IP protocol 132 is SCTP...

Larsa · Fri Apr 28, 2023 9:45 pm

Sorry, but not a clue without an config export!

rextended · Sat Apr 29, 2023 12:02 am

SCTP is used on mobile transport technology to help transport data streams between antennas of different frequencies.

It's like a leak from the LTE infrastructure, if the reported IPs are not yours.

Larsa · Sat Apr 29, 2023 12:43 am

@frank333, you have to check your firewall. If you want help from the forum on how, please post your config using /export.

If you were just interested in what, Rextended has already given you an answer or just google protocol 132 for more details.

frank333 · Sat Apr 29, 2023 10:45 am

@Larsa here is the firewall configuration,

firewall.rsc

@rextended the IPs starting with 47 139 39 202 are not mine; 151.... is my IP on windtre. is this a problem with my modem?
(Quindi è un problema del mio modem ?)

rextended · Sat Apr 29, 2023 2:49 pm

No, del ponte LTE...

frank333 · Sat Apr 29, 2023 3:01 pm

No, del ponte LTE...

as you can see from my export I used your configuration against flags attack and changed the TTL with the rule in prerouting (would it be better to move it to postrouting?) The problem is that now, after that 'error the router reboots.

frank333 · Thu May 04, 2023 9:15 am

the strange logs continue with the next reboot of the router, I switched to 7.9 stable.

Not TCP protocol prerouting: in:lte1 out:(unknown 0), connection-state:invalid src-mac c6:e0:42:92:21:52, proto 41, 192.88.99.1->151.58.128.200, len 76

Larsa · Thu May 04, 2023 1:03 pm

I glanced through your rules and there is plenty of room for optimization such as fast-track, the mangle chain etc. Have a look at these and feel free to come back with any questions:

frank333 · Thu May 04, 2023 1:11 pm

@larsa
I essentially used the default RoS rules and added rextended raw rules. I thought the firewall was sufficiently configured

Larsa · Thu May 04, 2023 1:26 pm

好吧,如果你认为这是足够的,你可以drop the "log=yes" statements in prerouting to get rid of the annoying logging but you probably want to add action=drop (if that was the intention). I mean the rules seems to do its job and catch it, right?

EDIT
Btw, there are also two "protocol=!tcp" in sequence.

frank333 · Thu May 04, 2023 1:35 pm

@larsa,
Yes the rules seem to be working , but the problem is that after the log message the modem and sometimes the router restarts.Before there were scpt protocol messages now there are those on ipv6 . In firewall the service port I have three services that I can not disable scpt,dccp,udplite but I think they are enabled by default because they are needed to establish the connection.I am calmly reading all the links you sent me to find something strange.

frank333 · Thu May 04, 2023 1:42 pm

EDIT
Btw, there are also two "protocol=!tcp" in sequence.

the second rule is disabled

add action=drop chain=prerouting comment="Unused protocol protection" \ disabled=yes protocol=!tcp

Larsa · Thu May 04, 2023 1:43 pm

In general, one may have different ways of thinking, like remove all possible combinations and accept the rest, or the other way around. Have you ever checked the activity on your prerouting rules? How about fast-track? It might be good to consider the number of rules and how these are structured in terms of performance if the CPU is heavily loaded.

frank333 · Thu May 04, 2023 1:48 pm

@Larsa,
I noticed activity from the flagsattack rules counter in the RAW section.
fasttrack rules are disabled.

Larsa · Thu May 04, 2023 1:49 pm

the second rule is disabled

Btw, you might want to add drop to the first rule if that was the intention, otherwise you are letting it through. Question, was fasttrack removed on purpose?

rextended · Thu May 04, 2023 2:04 pm

/ip firewall raw add action=accept chain=prerouting protocol=icmp add action=accept chain=prerouting protocol=igmp add action=accept chain=prerouting protocol=tcp add action=accept chain=prerouting protocol=udp add action=accept chain=prerouting protocol=gre add action=log chain=prerouting log=yes log-prefix="Not TCP protocol" protocol=!tcp add action=drop chain=prerouting comment="Unused protocol protection" disabled=yes protocol=!tcp

L'ultima regola è disattivata in maniera predefinita per evitare che uno si chiuda fuori.
Va attivata quando si è finito di configurare il resto.
La regola "Not TCP protocol" serve proprio per vedere cosa arriva che non sia già stato accettato prima.

aggiungi questo prima di "Not TCP protocol" per smettere di vedere i messaggi riguardo a questo protocollo:

/ip firewall raw add action=drop chain=prerouting protocol=sctp

**************

The last rule is off by default to prevent one from locking out.
It must be activated when you have finished configuring the rest.
The "Not TCP protocol" rule is used precisely to see what arrives that has not already been accepted before.

add this before "Not TCP protocol" to stop seeing messages about this protocol:

/ip firewall raw add action=drop chain=prerouting protocol=sctp

frank333 · Thu May 04, 2023 2:16 pm

ok
I did as you said,

raw.png

So it's just a firewall indication and not an external attack? I also have an alert with prot. 41.

rextended · Thu May 04, 2023 2:23 pm

the correct order is drop stp / log unallowed / and you must enabled "drop all at the end"
invert 30 and 31 and enable the disabled rule.

Il protocollo 41 è per fare un tunnel, tipo teredo, 6to4 / 6in4 per passare IPv6 su IPv4. Lo usa windows ad insaputa della gente per collegarsi conumque via IPv6.
Non c'entra niente con l'IPv6, se non lo usi, lo puoi bloccare.

/ip firewall raw add action=drop chain=prerouting protocol=ipv6-encap

Anche questa regola va sopra il log

frank333 · Thu May 04, 2023 2:34 pm

Schermata del 2023-05-04 15.04.17.jpeg

in this way all protocols other than tcp are filtered out.
and thus any service port activity is disabled ?

port.png

tnx
I will check for a few days and write here

Larsa · Thu May 04, 2023 2:34 pm

@frank333,只是一个建议:在我们的总公司we use a simple design philosophy "keep it as simple as possible" with only a few well-chosen and commonly used patterns for sabotage, intrusions and port scanners that end up permanently in a BAN list. The first rule in the raw chain checks against that list. This avoids repeated and unnecessary checks in the rest of the chains.

We also use fasttrack with the filter "Connection Mark: no-mark" to enable routing marks etc and jump-chain optimization in prerouting whenever possible like for example this:viewtopic.php?t=134048#p659676

frank333 · Thu May 04, 2023 2:53 pm

@frank333,只是一个建议:在我们的总公司we use a simple design philosophy "keep it as simple as possible" with only a few well-chosen and commonly used patterns for sabotage, intrusions and port scanners that end up permanently in a BAN list. The first rule in the raw chain checks against that list. This avoids repeated and unnecessary checks in the rest of the chains.

We also use fasttrack with the filter "Connection Mark: no-mark" to enable routing marks etc and jump-chain optimization in prerouting whenever possible like for example this:viewtopic.php?t=134048#p659676

The rules I have in the firewall should do that , what is wrong in your opinion?

I don't use fasttrack because I always have problems so it is the first thing I eliminate , even if the performance of the router decreases. I will read the reported topic
.tnx

Larsa · Thu May 04, 2023 3:28 pm

It was meant in relation to what I said earlier which completely depends on what you are using your router for. If you're happy and everything works as expected, there shouldn't be any problems but as a general rule of thumb and in order to make your firewall as safe as possible you might use "drop all" at the end of both the input and forward chains.

If you start having performance problems due to a high load where for example your router is used in front of some type of service with large amounts of calls, it might be time to look for possible optimizations using fasttrack, preroting and so on.

frank333 · Thu May 04, 2023 3:33 pm

@Larsa,
So far I haven't noticed any slowdowns or massive cpu commitments(I have at max 7-8 %) .
Thank you for the information

Larsa · Thu May 04, 2023 3:36 pm

rextended · Thu May 04, 2023 4:18 pm

in this way all protocols other than tcp are filtered out.

Spero che hai messo prima le regole per accettare l'ICMP e l'UDP, oltre al TCP come avevo indicato nel post originale.....

/ip firewall raw
add action=accept chain=prerouting protocol=icmp
add action=accept chain=prerouting protocol=igmp
add action=accept chain=prerouting protocol=tcp
add action=accept chain=prerouting protocol=udp
add action=accept chain=prerouting protocol=gre
add action=drop chain=prerouting protocol=sctp
add action=drop chain=prerouting protocol=ipv6-encap
add action=log chain=prerouting log=yes log-prefix="Not TCP protocol" protocol=!tcp
add action=drop chain=prerouting comment="Unused protocol protection" protocol=!tcp

protocol=!tcpis a security feature if accidentally accept TCP is disabled and you can not longer manage the RouterBOARD....
Is not here at random....

pe1chl · Thu May 04, 2023 4:30 pm

In general it can be said that people who do not have a detailed understanding of firewalls should NOT mess with the "raw" table!
Especially they should not copy other people's "advice for firewall rules".
Rules in the "raw" table can have unintended consequences and usually serve no purpose. Don't think you can mitigate DDoS locally on your router. You can't.

rextended · Thu May 04, 2023 4:40 pm

Don't think you can mitigate DDoS locally on your router. You can't.

Exactly.

Larsa · Thu May 04, 2023 5:03 pm

I might be wrong but judging by the rules and previous discussions these are not meant as ddos filters but rather various brute-force intrusion filters. But as mentioned, ddos resistance using RoS is futile. This is the way.

Amm0 · Thu May 04, 2023 5:33 pm

I'm just curious where the SCTP is coming from here. It's also connection oriented like TCP, so this could be a replay from a client initiating it. I think an internal device WebRTC stack is initiating the SCTP as a DataChannel...but it ended up untracked (thus invalid) on Mikrotik. So my bet it's not an DoS/etc attack or leak from LTE itself. And as @pe1chi notes, raw rules are complex & exactly how things could be untracked.

pe1chl · Thu May 04, 2023 6:49 pm

I'm just curious where the SCTP is coming from here. It's also connection oriented like TCP, so this could be a replay from a client initiating it.

The above is why I stated that people should not mess with the "raw" table when they do not know exactly what they are doing.
When there was an SCTP block in the filter table it would work OK and like you expect. In the "raw" table there is no matching with outgoing connections.

Amm0 · Thu May 04, 2023 6:56 pm

Agree @pe1chi...

When there was an SCTP block in the filter table it would work OK and like you expect.

I'd imagine most LTE connections are limited to TCP and UDP, so you'd want to block SCTP outbound. Which a prerouting filter rule would do, no need for RAW rules IMO.

Larsa · Thu May 04, 2023 7:04 pm

No, normal L3/IP for consumer subscriptions but how things are filtered is another matter. There are CPEs for companies that can do other stuff.

frank333 · Thu May 04, 2023 10:27 pm

@rextended
yes I put rules to accept ICMP and UDP, TCP in the right sequence. (I thought that following your directions would refine the 'action of the firewall; but if they are of no use why you who have more experience than me wrote them ?)

@pe1chl
So I would do well to delete them ? I have been using them for a few years and they have always worked well , only lately they give me that problem.

@adm0
所以你认为这是一个点对点连接在一个client inside my lan, I could monitor the traffic with wireshark and a filter on scpt , but the problem is occasional.

pe1chl · Thu May 04, 2023 10:53 pm

@pe1chl
So I would do well to delete them ? I have been using them for a few years and they have always worked well , only lately they give me that problem.

Those rules bring you absolutely nothing. They never "worked well", they were just no-ops. Until, apparently, some of your devices started using SCTP.
It is best to remove all "raw" rules and do any filtering you want only in the "filter" table. The reasons for having raw rules are academic, especially on an LTE connection.

frank333 · Thu May 04, 2023 11:04 pm

@pe1chi
so I'd better go back to the simple default rules and block the sctp protocol from there.
As far as activating a scpt client is concerned, I really don't know, I've always had the same devices and services, only recently have I got that report

pe1chl · Fri May 05, 2023 1:14 am

There is no reason to block SCTP.
Just use the default firewall rules.

rextended · Fri May 05, 2023 1:23 am

There is no reason to block SCTP.
Just use the default firewall rules.

You contradict yourself, in the default firewall the SCTP directed to an IP that does not exist is deleted anyway...
(or at most his machine is used to perhaps amplify an attack, if the response goes out again on the WAN because it can't find the IP inside...)

That traffic is going to his LTE CPE, but he doesn't have that IP anywhere... So there's a problem somewhere for sure...

Given that DDoS cannot be blocked, however blocking SCTP traffic on /firewall raw, which if not blocked blocks the helper integrated in the kernel,
which cannot be disabled on RouterOS v7, which causes the machine to reboot, for me it's better...

frank333 · Fri May 05, 2023 9:12 am

Schermata del 2023-05-05 08.05.24.jpeg

so far nothing has disconnected. and the logs are clean.

@rextended ,you were being ironic when you said in the post above that it's a bts problem.

This was a full blown DDos attack then!

Schermata del 2023-05-05 08.15.07.jpeg

Schermata del 2023-05-05 08.42.01.jpeg

the attack is still there, but can no longer restart the router

pe1chl · Fri May 05, 2023 10:49 am

There is no reason to block SCTP.
Just use the default firewall rules.

You contradict yourself, in the default firewall the SCTP directed to an IP that does not exist is deleted anyway...
(or at most his machine is used to perhaps amplify an attack, if the response goes out again on the WAN because it can't find the IP inside...)

That traffic is going to his LTE CPE, but he doesn't have that IP anywhere... So there's a problem somewhere for sure...

It isn't. The "incoming traffic" is a reply to traffic he sent outside. When filtering in the "raw" table, that is not considered.
When his locally connected systems attempt an outgoing SCTP connection, the reply that comes back is dropped and logged by those "raw" rules.
Makes no sense. Don't do that "raw" filtering, use only "filter" where the first rule will normally accept "established/related" and these packets would be passed through back to the system that sent them.

frank333 · Fri May 05, 2023 11:15 am

/ip firewall filter add action=drop chain=input comment="Winbox on WAN" dst-port=8291 \ in-interface=lte1 protocol=tcp add action=accept chain=input comment=\ "defconf: accept established,related,untracked" connection-state=\ established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=\ invalid add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment=\ "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=add-src-to-address-list address-list=BAN address-list-timeout=\ none-dynamic chain=input comment="list address banned" in-interface-list=\ !LAN add action=drop chain=input comment="defconf: drop all not coming from LAN *" \ in-interface-list=!LAN log-prefix="[DROP input]" add action=accept chain=forward comment=\ "defconf: accept established,related, untracked" connection-state=\ established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" \ connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \ connection-state=new disabled=yes in-interface-list=WAN add action=drop chain=input comment="TCP non SYN scan attack input" \ connection-state=new protocol=tcp tcp-flags=!syn add action=drop chain=forward comment="TCP non SYN scan attack forward" \ connection-state=new protocol=tcp tcp-flags=!syn

@pe1chi
so essentially, I would just delete the raw rules, delete the two SYN rules above, and enable the default rule ' drop all from WAN not DSTNATed' and I would no longer have problems with sctp ?

Larsa · Fri May 05, 2023 11:29 am

It isn't. The "incoming traffic" is a reply to traffic he sent outside. When filtering in the "raw" table, that is not considered.
When his locally connected systems attempt an outgoing SCTP connection, the reply that comes back is dropped and logged by those "raw" rules.
Makes no sense. Don't do that "raw" filtering, use only "filter" where the first rule will normally accept "established/related" and these packets would be passed through back to the system that sent them.

Yeah, WebRTC/SCTP is a well known use case and is also common in modern applications that doesn't want to bother about multi-plath and multi-homed communication issues. Also commonly used internaly by telcos to replace SS7 but if that kind of traffic would leak outside, it would be a MAJOR security vulnerability.

https://stackoverflow.com/questions/117 ... used-known

Larsa · Fri May 05, 2023 12:00 pm

so essentially, I would just delete the raw rules, delete the two SYN rules above, and enable the default rule ' drop all from WAN not DSTNATed' and I would no longer have problems with sctp ?

@frank333, If your browser is responsible for the SCTP traffic using WebRTC, you probably don't want to filter out the response as @Pe1chl pointed out. And btw, I think you'd do yourself a big favor if you start from scratch using the links I provied in the earlier post. Then you can start expanding it from there if you have any specific requirments using input from the forum.

pe1chl · Fri May 05, 2023 12:07 pm

删除“添加action =删除链输入评论= " =Winbox on WAN" dst-port=8291 in-interface=lte1 protocol=tcp" as well. You don't want that!
The remainder seems to be about the default firewall, but I did not check that to every bit.
I think MikroTik should add a "reset firewall to default" button to reset the firewall after people have messed it up, without having to reset the entire configuration.
But it is not there, yet.

frank333 · Fri May 05, 2023 12:40 pm

ok,
我会做一个出口configuratio(文本)n, scripts and modem settings.
Then I'll do a total reset so at least I have the firewall with the default rules; then I'll add what's missing by hand.
I don't see any other solution.
A nice button to reset the firewall back to basics would not be bad .
I've been monitoring sctp traffic for a few hours with wireshark but haven't found anything yet .

rextended · Fri May 05, 2023 12:52 pm

Il log è chiaro, l'SCTP viene da fuori, non da dentro, con wireshark non vedi nulla.....

frank333 · Fri May 05, 2023 1:02 pm

re:The log is clear, the SCTP comes from outside, not inside, with wireguard you see nothing.....

I thought that if there was a webrtc communication between lan and external you could see it by listening on the router's ethernet interface (but you're right, I started an online webrtc test and it didn't detect anything)

rextended · Fri May 05, 2023 1:08 pm

Le regole di default sono queste:
viewtopic.php?f=13&t=175129&p=856824#p856824

Ovvio che le liste WAN e LAN devono essere già corrette ed esistenti.

Remember that any automatic system that puts the IPs in a blocklist on the routerboard will automatically contribute to blocking the routerboard itself,
because in the event of a DDoS, the list will fill up quickly and will finish the memory of the device and during the attack it will always consume more and more CPUs,
also for logging...

My advice is to put the default ones, on the link, and add on the raw the ones I wrote on previous post on this topic
viewtopic.php?p=1000169#p999971
and forget about the firewall.

Any other "protection" is useless, must be done by your ISP...
At least check that your LAN do not generate any spoofing attack:
drop any packet from LAN that do not have one LAN address, 0.0.0.0, 224.0.0.0/4 or 255.255.255.255 for source.

frank333 · Fri May 05, 2023 1:30 pm

well;
i will also remove the BAN lists,
i was thinking of doing a script with /ip firewall filter remove and rewriting the default rules written in your post but i don't want to lose access and connection .
I will rewrite everything by hand tonight.

pe1chl · Fri May 05, 2023 5:17 pm

ok,
我会做一个出口configuratio(文本)n, scripts and modem settings.
Then I'll do a total reset so at least I have the firewall with the default rules; then I'll add what's missing by hand.
I don't see any other solution.

You can also use this command in commandline mode: /system/default-configuration/print
That will print a couple of scripts (you can use file=xxxxx to redirect it to a file) and under the label "script:" there is the default firewall.
You can then compare that to an export of your current configuration and adjust what has changed.

Amm0 · Fri May 05, 2023 5:27 pm

re:The log is clear, the SCTP comes from outside, not inside, with wireguard you see nothing.....

I thought that if there was a webrtc communication between lan and external you could see it by listening on the router's ethernet interface (but you're right, I started an online webrtc test and it didn't detect anything)

It might just the response is getting flagged as invalid, so first SCTP makes it out but part of the handshake get lost. Totally right you see it in a sniffer however, but also possible WebRTC DataChannel is transitory (e.g. a game or video call might try SCTP with WebRTC). It's just SCTP isn't typical, it leaking from LTE or attack also seem weird too.

I'd listen to @rexetended he sames to have a handle on this. Rebuilding from default is a good idea.

frank333 · Sat May 06, 2023 1:27 pm

firewall.rsc

filter.jpeg

raw.jpeg

No attacks or problems so far, but it has been a few hours.
I hope I have restored the firewall to the default configuration.
If anyone has ROS7.9 can you compare it with the images above ? (I tried reading the default script internal to RoS7.9 but couldn't find any rules, I wonder where they are stored).

Who is online