[8.1.44] Flood of org.eclipse.jetty.http.BadMessageException: 400: No Host

Ignition
1

Following a server update (not an Ignition update) over the weekend our logs have been sporadically filled with large groups of some/file/path org.eclipse.jetty.http.BadMessageException: 400: No Host

The specific logger is org.eclipse.jetty.server.HttpChannel
Some quick wrapper.log snippets:

INFO   | jvm 1    | 2025/03/24 11:13:36 | W [o.e.j.s.HttpChannel           ] [11:13:36.373]: handleException /PCI2/recipe_release/wwwroot/assets/php/_core/calendar.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:13:36 | W [o.e.j.s.HttpChannel           ] [11:13:36.416]: handleException /PCI2/recipe_release/wwwroot/recipe/recipe_search.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:13:36 | W [o.e.j.s.HttpChannel           ] [11:13:36.454]: handleException /PCI2/recipe_release/wwwroot/recipe/recipe_view.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:13:36 | W [o.e.j.s.HttpChannel           ] [11:13:36.495]: handleException /PCI2/recipe_release/wwwroot/recipe/login.php org.eclipse.jetty.http.BadMessageException: 400: No Host 

INFO   | jvm 1    | 2025/03/24 11:14:46 | W [o.e.j.s.HttpChannel           ] [11:14:46.778]: handleException /assets/php/_core/calendar.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:46 | W [o.e.j.s.HttpChannel           ] [11:14:46.818]: handleException /recipe/assets/php/_core/calendar.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:46 | W [o.e.j.s.HttpChannel           ] [11:14:46.860]: handleException /recipe/recipe_view.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:46 | W [o.e.j.s.HttpChannel           ] [11:14:46.902]: handleException /recipe/recipe/recipe_view.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:47 | W [o.e.j.s.HttpChannel           ] [11:14:46.946]: handleException /recipe/login.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:47 | W [o.e.j.s.HttpChannel           ] [11:14:46.987]: handleException /recipe/recipe/login.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:47 | W [o.e.j.s.HttpChannel           ] [11:14:47.026]: handleException /recipe/recipe_search.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 11:14:47 | W [o.e.j.s.HttpChannel           ] [11:14:47.066]: handleException /recipe/recipe/recipe_search.php org.eclipse.jetty.http.BadMessageException: 400: No Host 

INFO   | jvm 1    | 2025/03/24 12:04:41 | W [o.e.j.s.HttpChannel           ] [12:04:41.313]: handleException /index.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 12:04:41 | W [o.e.j.s.HttpChannel           ] [12:04:41.352]: handleException /html/index.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 12:04:41 | W [o.e.j.s.HttpChannel           ] [12:04:41.393]: handleException /mambo/index.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 12:04:41 | W [o.e.j.s.HttpChannel           ] [12:04:41.438]: handleException /Mambo/index.php org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 12:04:42 | W [o.e.j.s.HttpChannel           ] [12:04:42.777]: handleException / org.eclipse.jetty.http.BadMessageException: 400: No Host 
INFO   | jvm 1    | 2025/03/24 12:04:42 | W [o.e.j.s.HttpChannel           ] [12:04:42.816]: handleException /bugzilla/ org.eclipse.jetty.http.BadMessageException: 400: No Host

I'm highly suspicious that this is the result of some security service interfering with Ignition but wanted to confirm it wasn't something failing on its own in Ignition.

2

Something on your network is doing a scan, finding Ignition, and making some bogus HTTP requests.

2 Likes
3

Guess they haven't found the dev server yet, prod server is the one only doing this right now. Edit: nope, cursed that into existence.

1 Like
4

Mwah, hah, hah! Indeed! :rofl:

1 Like
5

Submitted a ticket to my IT department to track this down and they are wondering if there is any way for Ignition to report back where the source of these scans is coming from.

Is there a logger I can set to a different level to get it to spit out the IP that made the request?

6

I am facing same issue, any idea how this happen .

image
image1194×744 70.8 KB

7

It'll be a mess, but if you set all of the org.eclipse.jetty loggers to DEBUG level some of the log messages will have the remote host/IP in them.

image
image1472×410 20.8 KB

e.g.

HttpConnection	26Mar2025 06:32:42	HttpConnection@3394d470::SocketChannelEndPoint@7ff2fe0e[{l=/127.0.0.1:8088,r=/127.0.0.1:57412,ISHUT,fill=-,flush=-,to=0/30000}{io=0/0,kio=0,kro=1}]->[HttpConnection@3394d470[p=HttpParser{s=START,0 of -1},g=HttpGenerator@3e58426{s=START}]=>HttpChannelOverHttp@72155ac9{s=HttpChannelState@4fea5341{s=IDLE rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0},r=1,c=false/false,a=IDLE,uri=null,age=0}] filled -1 RetainableByteBuffer@249c1293{DirectByteBuffer@27daddac[p=0,l=0,c=8192,r=0]={<<<>>>GET /Stat...\x00\x00\x00\x00\x00\x00\x00},r=1}

which has:

l=/127.0.0.1:8088,r=/127.0.0.1:57412
1 Like
8

This is why on Linux, I like throwing an HAProxy reverse proxy in front of Ignition especially if Internet facing. This information will all show up in logs and if necessary, can implement fail2ban to even ban the source IP. I kinda wish Ignition's wrapper log would show failed logins so that I can use fail2ban to also ban IPs that have an extra amount of failed logins. (Yes, I know Ignition can also block failed logins, but I much prefer the "block the source IP" route)

2 Likes
9

Thankfully whatever was spamming appears to have stopped for now. I'll hold this in my back pocket to turn on if the problem reappears.

I'm unfortunately stuck (see cursed) with a winblows environment.

Our Ignition/manufacturing servers run in an isolated vlan so that narrows the source down to something™ in our corporate network., which is still a lot of stuff.

10

Doing a little more digging, the /QUALYS730### appears to be related to a vulnerability scan used to detect a known Apache Tomcat vulnerability.

Vulnerability scanning will apparently do a GET /QUALYS####### HTTP/1.0 to get the Tomcat version back in the header.

See reply #2 in this cisco thread: